Hacker News Reader

Comment by cannedbass | Hacker News Reader

Seemed like a good idea until it dawned on me that this means the passwords are stored as plaintext.

There are several ways this can be done without that.

Easiest is if they store the date of the last password change or otherwise know you haven't changed it. If it's old enough, double the plaintext before handing it to the hashing function.

>> Seemed like a good idea until it dawned on me that this means the passwords are stored as plaintext.

>There are several ways this can be done without that.

>Easiest is if they store the date of the last password change or otherwise know you haven't changed it. If it's old enough, double the plaintext before handing it to the hashing function.

Not quite. What you'd need to do is halve the user's entered password if it's older than the cutoff date. If the user enters "foobarfoobar" then you'd halve it to "foobar" before hashing and comparing it to what's stored.

If you only have the old hashed password stored then you don't have the hash of the doubled password, nor can you can infer it.

This whole approach is silly of course. They should just force everybody to reset their passwords.

The reason to inconvenience rather than force is users in a rush will pick the worst passwords, even as paid employees where their password is the thing between the outside world and highly confidential stuff.

This is interesting. If I was a McGill employee, I'd be getting ready to try "foobarAAAAAA" and "AAAAAAfoobar"....

Deleted comment

If the database record says the user hasn't changed their password, split the given password in half, check that both halves are equal to each other, and check that one half matches the hash of the password.

check that it's a string of the right form (e.g. it repeats something exactly twice) and then derive the original password from that, before feeding it to your hashing function.

Reply on news.ycombinator.com