Talk:Direct Login

From Ajax Patterns

Sorry to say that I do not think your analysis of the security of the direct login pattern is correct.

1. Knowledge by an attacker of the seed used in conjunction with the password to create a client side hash does not make the password any more vulnerable to a brute force hash than not using the seed. You correctly state that it prevents a replay attack, but the success rate of a brute force attack is theoretically 2^hash_size/2. For sha-1 this is 2^80.

2. If you do client-side hashing with a seed it creates a new vulnerability in that the server must store the user password in plaintext, hence any attack on the server could reveal all client passwords.

One possible solution is double hashing: Store a hash of the password on the server; client prompts user for password, this is hashed; client contacts server and requests a challenge (seed); this is hashed with the password hash and result sent to server; server combines seed and hash corresponding to username from database and hashes this; this final hash should be the same as that sent by client.

I would also recommend hashing the username and password to create the password hash to be stored in the database.

Regards

Peter Curran, CISSP

My example at jamesdam.com/ajax_login/login.html does use double hashing, so the password is not stored in plaintext in the database.

--James Dam, 00:03, 7 October 2006 (EDT)

The writeup in the book (partly reflected in the Archived Version here) takes Peter's comment into account. --Mahemoff 17:34, 7 October 2006 (EDT):--Mahemoff

Contents 1 Server attack still a vulnerability 2 RSA

Ajax/Javascript Programming and Usability in "Ajax Design Patterns" Book

Server attack still a vulnerability

Also, while an attack on the server won't reveal the user's passwords, I believe it will still allow logins to the system in question and all systems using the same exact techniques because the hash has essentially become a password based on the real password. Knowing the hash stored on the server allows a successful login to the system. This is still more secure than simply sending a password over plain text but is not as secure as using HTTPS and the traditional system of protecting at both the server and link level.

 -- James Andariese

Not so in my example at jamesdam.com/ajax_login/login.html. The hash does not essentially become a password, because each hash is only valid for one use. The hash is seeded with a random value from the database, and once this seed is successfully used to log in, the value is deleted from the database, so it can't be used again. Looking back now, it's a bit unclear in my code exactly how it works, but as I recall this is what happens. You'll forgive me, I wrote it over a year and a half ago now and my memory is a bit hazy.

--James Dam, jdam, 00:03, 7 October 2006 (EDT)

RSA

Would RSA with PKCS#1 be a little more secure?

1. Ajax request to server to get a public key.
2. Javascript encrypts username/password using RSA
3. Ajax request to server with encrypted username/password
4. Public key discarded on the server to avoid reuse.

== Issues with salte d passwords == I was going to use this pattern for a site I'm working on. The main page is served over HTTP and makes heavy use of AJAX. I had a nice AJAX login effect going until I started testing with HTTPS - I obviously don't want to send a plaintext login and password over the Internet, and XMLHttpRequest isn't allowed to make HTTPS connections back to the server when it's loaded on an HTTP page.

The user data is managed with ActiveRBAC for Rails. The problem is that ActiveRBAC salts the passwords to deter brute force dictionary analysis of the password database. A random salt is generated for each user and stored in plaintext in the database in a seperate column alongside the login and encrypted password. The encrypted password is generated as the SHA-1 hash of the plaintext password plus the salt.

The problem is that the browser has to know the user's salt in order to perform the password hash clientside. Revealing the salt to an anonymous client weakens security by making it more feasible (though still difficult) for an attacker to do a brute force dictionary search of that user's password.

Beyond that, if revealing the salt to the public is accepted, there is the question of how to get the salt to the browser, since the server doesn't know at page load time which user will be trying to log in. The best solution I came up with here is to have the browser send two XMLHttpRequests at login form completion; the first queries for that user's salt (or an error if that user doesn't exist, or better yet, a random value so as to prevent atttackers from learning that a user exists or doesn't exist), and the second submits the result of hashing the plaintext password, the salt, and the challenge text back to the server for login.

Or I can just leave my beautiful AJAX behind and use a regular HTTPS POST and page refresh to log in.... I'm leaning towards this solution, since a number of page elements have to refresh anyway at login.

Any opinions on the danger of revealing the salt to the public?

Another option is to implement my own public key encryption scheme in Javascript, encrypt the password with that in the browser, then send that over HTTP back to the server.. maybe something with [1], [2], [3], etc.. but would the extra code download and engineering time to program it be worth the smallish gain in user experience from not having to do a POST/refresh cycle? I can see how it might be for a heavily interactive site like the video mashup editor mentioned, but my site is not THAT interactive, so I'm leaning towards the thraditional POST. (Actually, the JS RSA password submission method is an interesting pattern in its own right.. we should make a page for that. I'm sure someone will find it useful somewhere.

Cheers. PaulLegato 17:38, 1 October 2007 (EDT)