Why are web sites still storing passwords? Monster, USAJobs blunder highlights the risks

Sophos informs us that job sites Monster and USAJobs (an official US Job site) have been hacked. Messages on Monster and USAJobs confirm this. I’d like to draw attention to the fact that passwords were stolen:

We recently learned our database was illegally accessed and certain contact and account data were taken, including Monster user IDs and passwords.

says Monster. And USAJobs says:

We recently learned that the Monster database was illegally accessed and certain contact and account data were taken, including user IDs and passwords, email addresses, names, phone numbers, and some basic demographic data.

Same wording – because Monster is the “technology provider” for USAJobs.

Sophos observes:

There is even more potential for danger, however, because passwords have been stolen. We know that too many people use the same password for every website that they access.

Right. But why is Monster even storing passwords? It is not necessary. All you need store is a one-way password hash, so the site can verify a password without recording it. This is easily done in every web platform out there.

There is a disadvantage. It means the site cannot email your lost password. Instead, it must reset your password. Since email passes in plain text, emailing passwords is a bad idea anyway, and I hate to see sites doing this; it’s a useful alert though that the site places a low value on security.

Any site can get hacked, but what isn’t stored can’t be stolen.

Technical blunders like this can be costly; there’s no excuse for it that I can think of.

Technorati tags: , , , ,

4 thoughts on “Why are web sites still storing passwords? Monster, USAJobs blunder highlights the risks”

  1. Hello,

    I do not agree with you that merely storing a hash would be any safer, or marginally at best. Depending on what hash is used it is more or less susceptiable to a rainbow attack. And even if you don’t deploy that a brute force offline attack won’t take that long.

    Are you sure they store their passwords plain text or merely understand that if the password table was stolen in its encrypted form they are still vulnerable?

    If the data backend is hacked you are more or less at the mercy of the hackers it is just a matter of time.

    The only “safe” solution is random onetime passwords managed through a keyring or fingerprint/biometric software.

    That way they need to steal your data not someone else´s copy of it. And even if they steal that someone else’s copy, that’s all you lose.

    In the end the security problem is usually computer users’ habits, but techonology can certainly ease or at least guide users in the proper direction, it for no other reason than to educate people in proper habits.

  2. Naturally there are different hashes and different ways through for instance salting to make it much harder. I was merely mentioning rainbow attacks as one way (even for salted passwords!)

    However the problem normally lies in the fact that people use simple and short passwords.

    And as I said unless this was a simple SQL injection attack, and they actually got hold of the data backend server, then it is not that hard to figure out the salts used. Unless it is a row salt, then it would be slightly more of a headache, but as they have access to the data backend they can grab just about anything from any process’s memory if you want to go the fast route.

    Either way it is a matter of time before it is finally broken. The attacker surely has more computing power than your can afford spending on your servers, and that is likely to be many magnitudes larger as well (botnets are useful =).

    I believe a much better approach is to use a authentication scheme that is federated and thus stores no knowledge of your secret but still verifies you with either a global unique key or a one time password from the IDP.

    Also this way you(RP) need only store what is interesting for your site locally and keep all the other customer personal stuff on the IDP.

    Makes the IDP more interesting to attack however..

    But that can also be solved through certificates/biometric etc. Your data is yours and yours alone and grabbing it won’t do you much good, at least not for a lifetime or two (or unless they actually steal your secret in your own private datastore wherever your keep that).

    You could even have 2 channel challenge setup, where one channel could be your computer and the other your 3G connected phone. Thus 2 devices would have to be compromised etc.

    That would also make phising a whole lot harder.

    I believe there are ways to make things secure, however the usability patterns got off to a wrong start and securiry wasn’t designed from the start.

  3. I believe a much better approach is to use a authentication scheme that is federated and thus stores no knowledge of your secret but still verifies you with either a global unique key or a one time password from the IDP.

    I absolutely agree with this.

    Tim

Comments are closed.