I was reading about a login using ajax that they claim is secure and I can’t see the weakness in it versus submitting a form to an https page. There might be one, but can someone point it out?
* 1. User visits website.
* 2. Server handles initial page.
o 2a. Server generates one-time seed (S) and stores it.
o 2b. Server outputs page, including login form, and with one-time seed embedded somewhere on the page (e.g. in a Javascript variable).
* 3. User enters username (U) and password (P).
* 4. Browser handles submission.
o 4a. Browser hashes password (P) using permanent hash function, to arrive at the attempted hash value (Ha) that should be held in the database.
o 4b. Browser combines attempted hash (Ha) with one-time seed (S) to create one-time, double-hashed, value (Da).
o 4c. Browser uploads username (U), double-hashed value (Da), and (for convenience) one-time seed (S).
* 5. Server authenticates.
o 5a. Server verifies one-time seed (S) is valid.
o 5b. Server extracts stored hash for this user (H) and combines it with the seed (S) to get one-time, double-hashed, value (D).
o 5c. Server compares the double-hashed values (D and Da). If successful, it logs the user in (e.g. creates a new session and outputs a successful response code) and clears the one-time seed (S). If not, it either re-generates a new seed, or decrements a usage counter on the existing seed.
This is an old question, but I came upon it while trying to solve the same problem so I thought I’d contribute in case anyone else did as well. This is no more secure than delivering the hashed password (Ha) right to the attacker. Here’s the problem. Let’s say the attacker sits between Client and Server. Since the conversation happens over HTTP, they can see everything involved.
[ul]
[li]Client gets the page with (S) on it over HTTP.[/li][LIST]
[li]Attacker now knows (S).[/li][/ul]
[li]Client enters weak password “password123”, which is hashed into (Ha), which is hashed with (S) to provide (Da).[/li][li]Client sends username and (Da) to Server.[/li][li]Server responds successfully.[/li][ul]
[li]Attacker now knows username, (Da), and that they represent the correct password.[/li][li]Attacker now employs the same dictionary attack as they would if they had broken into your database and stolen your hashed passwords (Ha). The only difference is they now have a negligible additional step that adds some CPU time, but doesn’t add any security.[/li][LIST]
[li]Attacker guesses “password123” and hashes it into a guessed (Ha).[/li][li]Attacker uses the known (S) to hash (Ha) into (Da). If the guessed (Da) matches the known (Da), the attacker knows the password is “password123”.[/li][/ul]
[/LIST]
[/LIST]
As long as the user doesn’t change their password between when the attacker snooped and when the attacker successfully cracks the password, their credentials are now compromised.
So you can see that this method adds a tiny amount of effort to the attacker’s task: they have to hash their guess a second time, but since (S) is known, this isn’t adding any complexity to the security. It’s only going to mean it takes them twice as long to test each guessed password compared against cracking a singly hashed password.