Mitigating Password Re-Use From the Other End 211
An anonymous reader writes "Jen Andre, software engineer and co-founder of Threat Stack, writes about the problem of password breaches in the wake of the LivingSocial hack. She notes that the problem here is longstanding — it's easy for LivingSocial to force password resets, but impossible to get users to create different passwords for each site they visit. We've tried education, and it's failed. Andre suggests a different approach: building out better auditing infrastructure. 'We, as an industry, need a standard for auditing that allows us to reliably track and record authentication events. Since authentication events are relatively similar across any application, I think this could be accomplished easily with a simple JSON-based common protocol and webhooks. ... [It] could even be a hosted service that learns based on my login behaviors and only alerts me when it thinks a login entry is suspicious— kind of how Gmail will alert if I am logging in from a strange location. Because these audit entries are stored on a third-party box, if a certain web application is compromised, it won't have access to alter its audit log history since it lives somewhere else.'"
how about store your passwords properly? (Score:5, Insightful)
It also ought to be easy for LivingSocial to store passwords hashed with a secure hash designed for passwords, like scrypt [wikipedia.org] (or the related bcrypt). That way even if the password db is compromised, the plaintext passwords aren't, and the attacker cannot use the result to get into other services, even if users shared passwords across services.
It's easy to blame users, but there has been no excuse for storing plaintext passwords for years now. Password reuse is a much smaller problem if websites are designed properly. So rather than "as an industry" attempting to change user behavior, how about "as an industry" implement your damn sites properly, and audit that.
Re:Forcing strong passwords in the first place. (Score:5, Insightful)
LastPass used to scream at me when I was doing that, so I disabled that functionality.
Re:Forcing strong passwords in the first place. (Score:5, Insightful)
It doesn't. I believe it may even encourage re-use.
Re:Forcing strong passwords in the first place. (Score:4, Insightful)
Or, alternatively... (Score:4, Insightful)
If you're security conscious enough to put this fancy bit of JSON on your site, then most likely you're smart enough to not store your user's passwords in plaintext. In fact, I'd like to think you're clever enough to salt the hash of the passwords that you're storing as well.
Why am I pointing this out? Because password re-use is an issue when a password gets compromised. Passwords get compromised when they're not encrypted or hashed. So to "fix" the problem like this is all well and dandy, but it only works if every site does it and if every site hashed the bloody passwords in the first place, they wouldn't get compromised as often.
Re:Forcing strong passwords in the first place. (Score:4, Insightful)
Or, the other solution is assign the password, and don't let the user change his own. When it expires, a new one is generated. No reuse can happen when the user can't set any of their own passwords.
It would be hellish if every website started doing that. I'd have to recover my password every time I try to log in somewhere, or keep a big document of passwords (which is worse). At the moment I have 6 different passwords (8-10 char) in total, but they're mostly variations of the same base. Anything more complex than that and I would lose track.
Don't brush your problem off on the user (Score:5, Insightful)
I see it very often in audits, company security is facing the same problem: How to secure the network? The easy way out: The user has to do it. He has to come up with a password that fulfills the most inane requirements AND must remember it AND must not note it down.
That's the easy way out. All the burden is shifted to the user.
I consider it extremely patronizing if they then go, after a breach, that they tried to "educate" the user but failed. Well, DUH. Guess what. It's not the user's job to keep your database secure. It is his job to make sure his credentials don't get handed over to a third party, yes. But it is YOUR job to make it possible to him. And it is NOT possible for the average human being to remember passwords in the style of k$aUZ_nR2o.
Don't try to shift a problem that YOU have to solve onto your users!
Forget passwords, worry about "Secret Questions" (Score:5, Insightful)
All this concern over passwords is ignoring the much greater problem of so-called "Secret Questions". This is a mechanisms that positively encourages people to use the same security information on every site they visit and to give answers that can easily be guessed by other people.
How many sites hash the answers to these questions so that they can't be re-used by a hacked who breaches the site (or a corrupt employee)?
How many users take care to give a different wrong answer to these "Secret Questions" every time?
The complexity and variablility of the password reset process can make this mechanism less susceptible to automated attack, but if you want to attack a specific account of a known person this is a much better route that trying to crack the password.
Re:Forcing strong passwords in the first place. (Score:5, Insightful)
1) I use five different operating systems. (Osx , ios, linux, windows, android ) name one keychain program that can be used across them all and keep that program easily sync'd?
2) You push the point of failure onto the keychain program. if you want to get someone all you have to do is crack their keychain and they are screwed.
3)what happens when your keychain program gets corrupted? a simple hard disk failure now prevents you from ever logging in again.
Re:Forcing strong passwords in the first place. (Score:5, Insightful)
If you have so many passwords that you have to either write them down or store them in a password management system, then that criterion fails, because it's no longer something you know at all.
Whereas if you use good passwords to start with, and keep layers of trust between different systems (i.e. don't use the same password for your bank as you do for Twatter), then you will not be 100% secure, but at least you have a hope of keeping some control to yourself.
Re:Forcing strong passwords in the first place. (Score:4, Insightful)
It's impossible to clear this mess up without using the same password and log in for everything. Right now I have over 400 log ins in my database. I'm not sure how many of those are ones that I need to log into again, but that's a large enough number that even changing them on a regular basis is unlikely.
Trying to unify that under the same log in that the sites get, is not something that's technically desirable. I'm not really sure how one can solve this problem form the server side, because you'd need 3rd party to access all of the passwords without the users' permission in order to know.
Re:Forcing strong passwords in the first place. (Score:2, Insightful)
It would be hellish if every website started doing that. I'd have to recover my password every time I try to log in somewhere, or keep a big document of passwords (which is worse).
I have one website that I do exactly that with. They have such stupidly complex password for absolutely no reason (to get software updates for a product that requires a license server to run) that I refuse to participate. Their password requirements are even more complex than the Intel developer passwords - something I didn't think was even possible. So when I need to go login, I just reset my password and bypass their password system altogether. Just for fun, I even sent them email and told them that is what I do - but got no response.
Hell, why am I even hiding their name? It is Synopsys.
At the moment I have 6 different passwords (8-10 char) in total, but they're mostly variations of the same base. Anything more complex than that and I would lose track.
I have a few variations on a few bases. I have an ultra-low security password (for forums like slashdot and others), a mid-security base and a high security base. Then I have a few unique passwords that I use for one and only one purpose (one of them being my PGP key).
Marc
Re:Forcing strong passwords in the first place. (Score:4, Insightful)
Furthermore, policies that require constant password changes encourage people to use the same password with an incrementally changing number.
I use strong and varied passwords for important services (email, banking etc) and shitty repeated passwords for every stupid forum that wants me to sign up to participate.