Password shtuff

Rough notes on a chatterbox discussion.

How about md5 crypts instead of password in the cookie? That would allow passwords > 8 chars (with a user table change).

md5 may be too CPU expensive; needs to be tested.

An md5 crypt certainly takes more time than a des crypt: one some machine the md5 crypt seems to take 5e-4 second, the des takes 1.3e-5 seconds.

(comments about $3$/NT-hash)

Instead of comparing hashed password in cookie to hash of clear password in database, store the hashed password in the database and the non-salt part of it in the cookie; authenticate cookies via string compare.

Later, unhashed password will be eliminated.

update user edit page to require the previous password in order to change the password

have a real "password reset e-mail" feature

--
A math joke: r = | |csc(θ)|+|sec(θ)|-||csc(θ)|-|sec(θ)|| |
Online Fortune Cookie Search

Comment on Password shtuff

Replies are listed 'Best First'.
Re: Password shtuff by tye (Sage) on Dec 31, 2010 at 00:12 UTC
Testing on one of our web servers showed current crypt takes about 8us while MD5 crypt takes about 1ms, which is over 100x as much CPU (and we'd need better enforcement on the cap on password length but with a limit much higher than 7; a 200-char password takes about 3ms). But my proposal was to not even include the full non-salt encrypted password in the cookie, just the last $n characters, say 20 16 of the 22. Then we aren't even calling crypt on every page hit (just when somebody changes their password). And somebody sniffing your cookie doesn't mean they can dictionary attack and find your password. Corion and I have each worked on new "password reset e-mail" implementations. - tye	[reply]

Replies are listed 'Best First'.

Re: Password shtuff
by tye (Sage) on Dec 31, 2010 at 00:12 UTC

Testing on one of our web servers showed current crypt takes about 8us while MD5 crypt takes about 1ms, which is over 100x as much CPU (and we'd need better enforcement on the cap on password length but with a limit much higher than 7; a 200-char password takes about 3ms). But my proposal was to not even include the full non-salt encrypted password in the cookie, just the last $n characters, say 20 16 of the 22. Then we aren't even calling crypt on every page hit (just when somebody changes their password). And somebody sniffing your cookie doesn't mean they can dictionary attack and find your password.

Corion and I have each worked on new "password reset e-mail" implementations.

- tye

[reply]