S/KEY alternative




I was recently thinking about authentication systems and came across S/KEY, described on p. 53 in "Applied Cryptography" and also online at http://en.wikipedia.org/wiki/S/KEY. It starts by hashing a secret key and then hashes the hash multiple times (possibly hundreds of times). The last hash is kept on the server with the user's name. So if 100 hashes were calculated, the user recalculates the first 99 and submits that for the login. The server hashes it and compares to the stored value. If good, the user is let in and the 100th hash is replaced with the 99th and the user will send the 98th on the next login. The downside to this scheme is that you eventually run out of hashes and it's computationally expensive if you make a long chain.

So my question is, why not do something like this instead: On account creation, user generates a random salt and appends it to a password. Then hash that only twice. Send the last hash (H) and the salt (S) to the server. On each login request, the server returns the last salt (so it doesn't have to be remembered). The user appends that to the password and hashes it once (H1). The user also generates a new random salt (S2) and calculates a new double hash (H2) to be used in the next login. User sends H1, H2, S2 to server. Server hashes H1 and compares to the stored hash. If good, user is let in and the old hash and salt are replaced by H2 and S2 for the next login. Is this any less secure than S/KEY in regards to password sniffing? Of course both are susceptible to man-in-the-middle attacks but that's not my concern at the moment.

One privacy issue I thought of is that an attacker could make login requests in someone else's name just to see if their salt had changed. Then they would know that person had logged in since they last checked.

--
Kent Briggs, kbriggs@xxxxxxxxxxxxx
Briggs Softworks, http://www.briggsoft.com
.



Relevant Pages

  • Re: Best way to encrypt password in database.
    ... Yep, that's the traditional way to do it, hash the password every logon ... If you password hashes ... Oh and BTW, never use MD5 for anything security related, it is broken ... Any of these one way hashes still needs a salt combined with it. ...
    (comp.lang.php)
  • Re: Best way to encrypt password in database.
    ... Yep, that's the traditional way to do it, hash the password every logon ... If you password hashes ... The fix is to add a salt to thwart the rainbow tables and a have the ... Oh and BTW, never use MD5 for anything security related, it is broken ...
    (comp.lang.php)
  • Re: Best way to encrypt password in database.
    ... Yep, that's the traditional way to do it, hash the password every logon ... If you password hashes ... Oh and BTW, never use MD5 for anything security related, it is broken ... Any of these one way hashes still needs a salt combined with it. ...
    (comp.lang.php)
  • Re: Best way to encrypt password in database.
    ... Yep, that's the traditional way to do it, hash the password every logon ... If you password hashes ... MD5 is not broken. ... Any of these one way hashes still needs a salt combined with it. ...
    (comp.lang.php)
  • Re: Best way to encrypt password in database.
    ... Yep, that's the traditional way to do it, hash the password every logon ... If you password hashes ... MD5 is not broken. ... Any of these one way hashes still needs a salt combined with it. ...
    (comp.lang.php)