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.'"
Forcing strong passwords in the first place. (Score:5, Interesting)
This seems like a good way to enforce strong password policies. if they are strong enough; they should help prevent password re-use. The only problem with this is the problem of people writing these down. We need a better online authentication system for 2013.
Passwords are unfixable (Score:2, Interesting)
You can tack on more mitigation, but in the end it's the concept that's flawed, not the implementation.
Re:Forcing strong passwords in the first place. (Score:5, Interesting)
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.
Or, forget caring. If they lose control of a password, then it's their fault.
one key to rule... (Score:2, Interesting)
Or we could just use GPG authentication, where a user simply uploads his public key to the site. User's happy, because s/he can use the same passphrase everywhere and the site is also secure because even a hack won't divulge any passwords. Separate (key-less) password could still be optional.
Too many damn passwords (Score:4, Interesting)
If you have too many different username/passwords you will not be able to keep them straight. This is what OpenID was supposed to solve. One can flip the argument around very easily: if there were fewer sites maintaining their own password databases, then there would be fewer breaches.
And that does NOT mean using OpenID for everything including financial accounts.
Still a issue that Devs won't acknowledge (Score:5, Interesting)
The thought process of a developer is that it is usually a user problem, and therefore it is the user that needs fixing, not the user.
The cold reality is that using passwords at all is the problem.
Passwords are an antiquated solution to a simple problem from the very start of multi-user computing. It is simple but exponentially ineffective as it scales.
The human mind is not set up to remember multiple, complex passwords. There are very few humans who are gifted with this ability to remember literally hundreds of different passwords without writing it down, I would put someone who can in the realm of an academic genius who can remember entire textbooks or recite Pi for hours before they eventually have to take a break for physical reasons.
Normal people write it down or keep it to a narrow set of passwords depending on which level of complexity the system will allow. Both bad security practice.
And passwords that expire every 45 days with annoying complexity requirments? You're going to drive users nuts trying to think of new ones each time that eventually they will come up with the simplist password the system will allow and increment by 1 each time they have to change eg: Password1, Password2, Password3, etc.
There are hacks out there, eg: KeePass and LastPass, but this is a workaround to the underlying problem. The websites that Force you to use Facebook are even worse (as they force you to handover all your personal details while you are at it, which just as easily can be used for identity fraud. Many Banks, Telcos etc. only authenticate with your DOB). OpenID is better but the implementation makes it common to sign in from the website your are trying to access, making it susceptible to being spoofed.
Realistically, we need to kill the password. Two factor authentication all the way. It needs ONE trust relationship between the user and the authenticator. This could be a user ID and a token. The authenticator can have then multiple trust relationships with participating websites.
The authenticator should only provide two data points: (1) The user ID of that website (different ID to other websites so that the user can be tracked with the same ID across websites) and (2) That the user has authenticated themselves. Thats it. Most websites don't need to know your name, DOB, Vanity username, email address or anything else about you. If they need this, ask - but only if actually required - and give the user a clear option to decline or provide only partial data.
The only thing that most websites or other computer systems need is a way to tell which user profile to load up, and that the user requesting it is really the same user. A password does not prove that,
Re:Forcing strong passwords in the first place. (Score:5, Interesting)
+5? The only way to keep a website from getting hacked is by not connecting it to the internet in the first place. Effort should certainly be put into making it difficult to hack but also making it difficult to gain anything valuable when you are hacked.
Re:nightmare (Score:4, Interesting)
If I were to create an account on LivingSocial, it would get my "disposable" password, the password for accounts I just don't care about at all. Only gradually do accounts and services migrate into the category where I bother remembering a specific and hard password for them.
That's rational.
Frankly, most password security "thinking" seems to me demented. There is no way I or most anyone else could possibly keep track of hundreds of different strong passwords with arbitrary characters, random case, etc without writing them down. And maybe not then.
And there is no practical way that I could secure that password list.
Neither is it likely that information providers can secure password information -- strong, weak or non-existent -- on their end. That's why massive password breaches are a daily event.
Bluntly, the industry's attempts at security can't and don't provide much security and are more a massive usability problem than anything else. How is "user education" supposed to overcome faulty engineering?
Look folks, the method you want to use to secure stuff simply doesn't work very well. Never has. Never will. Forget about "educating" users, and start thinking seriously about how to secure stuff, and whether most of what you are trying to "secure" actually needs securing. Maybe in decade or three you'll come up with something that works.
In the meantime. Get real.
Re:Forcing strong passwords in the first place. (Score:5, Interesting)
Wrong approach in use. Secrets should be local (Score:5, Interesting)
The sites that are calling for better password choice need to step back a bit and consider whether their design concept of storing user passwords centrally is a good one. It's not, so they should get rid of it instead of applying band aids to a bad scheme.
It doesn't matter what encryption scheme is used, if authentication secrets are stored centrally on a website then they are at risk. Good sites make it hard to crack, and poor sites make it easy, but they are all at risk, from internal employee corruption if nothing else. Those secrets will leak because when stored at a single point then they are all accessible to the attacker at a single point. Leakage is just a matter of time.
A vastly more secure approach that's been well known for decades is for the user to store their secret locally as a private key, one half of a {private,public} key pair. The server only gets to know the public key (PK), and it's pointless for an attacker to crack that because the PK is public information that can be distributed freely through keyservers. (The PGP/GnuPG keyserver network has been doing this for decades.)
When a user creates an account on some website, she provides the identifier of her chosen PK (she may have lots of them). When logging in to the account subsequently, the server looks up her PK identifier in the info for this account, fetches her PK from the keyservers, then it sends her a random string encrypted with her PK. She decrypts it with her private key (which is only held locally by the user, nowhere else) and sends the decrypted string back. The server accepts the login if the returned string matches the random string that it picked, which is not stored and varies on every login, and rejects the fraudulent login attempt if the match failed.
That's strong distributed security, and it's resistant to MITM attacks and does not store any authentication secrets on the central service so those secrets cannot leak when the service is compromised.
It's not rocket science. Why this old but secure scheme isn't used by websites is quite a mystery.
Completely missing the point (Score:5, Interesting)
The problem isn't that users use the same password on every site. The problem is that users have to create login credentials for every site they use.
That multiplication of logins is extremely inconvenient for users, and it's simply not practical for people to create good, unique credentials for every site and memorize them all. So people who care a lot about security are are willing to put in the effort (read: anal geeks) use encrypted password stores and such. Everyone else (read: 99+%) uses the same password or small set of passwords on all sites.
What's really stupid is that we have already solved this problem, and in a much better way then Jen Andre proposes. The solution is single-sign-on. Delegate account management and authentication to a trusted third party (TTP). Even better, allow many organizations to act in this role. Best of all, allow users to choose which TTP they want to use, or even to act as their own.
We've already built this. It's called OAUTH. Moreover, there are already a bunch of high-profile OAUTH implementors acting as TTPs -- and nearly all Internet users already have an account with at least one of them (e.g. Google, Facebook, Yahoo, Microsoft). For that matter, there are a number of sites already taking advantage of it to provide nearly zero-effort login (for example, stackoverflow is one that many slashdotters may use).
The common security objection to this approach -- that centralizing your authentication in a single account creates a single point of failure for your security -- ignores the fact that your web security already has a single point of failure, even if you use unique, strong passwords for every site you visit. That SPOF is your e-mail account, because essentially all web sites use the ability to receive e-mail as the golden key that bypasses all of their other security mechanisms.
But, with OAUTH you still have the ability to use different providers, and even to set up your own on a server you control if you like. You can choose the tradeoff between centralization and decentralization you like. No relying site will ever see any of your credentials. You can also pick a provider based on the level and type of authentication security they provide. Personally, I'm very happy with Google's two-factor authentication -- but OAUTH imposes no restrictions. Want certificate plus one-time-password plus fingerprint plus retina scan plus 100-word passepic? Fine. Find (or build) a provider that does that. Want nothing at all? You can have that, too.
And whatever you choose, none of the relying sites will ever have any of your credentials. Which means creators of those sites can't screw up storing your credentials.
The only thing that's required to make all of this work, for real, everywhere, is for sites to offer OAUTH authentication. It's easy, it's super convenient for users, it's as secure as the provider.
Some sites might choose to limit the providers they'll accept, on the theory that users can't be trusted to choose a good one. That's annoying and obnoxious, but whatever. Some sites (like banks) might decide that they simply have to do their security themselves because they can't trust anyone else, and They Are A Bank. Okay, fine, though such sites should be a tiny minority (and, frankly, as someone who worked as a banking security consultant for over a decade, and now works for Google doing security, Google -- and, I would expect, the other major Internet properties -- do a far, far better job at online security than virtually any bank).
The solution is to make OAUTH the default, expected login mechanism all over the web. It provides dead-simple, reasonably high security authorization for the masses and allows the paranoid to build/buy whatever they want.
The thing is ... (Score:4, Interesting)
I have numerous accounts for everything from forums to banking. Some are clearly important, while others are not important. The important accounts get the strong passwords, passwords that aren't reused (even in terms of a significant modification). The unimportant accounts have reused passwords, with the only real rule being that the password is different from accounts that may somehow be correlated (e.g. through their authentication mechanism or username).
The problem with preventing reuse is (a) every service thinks that they are the most important thing since the creation of the universe and (b) strong, non-repeated passwords have their own inherent insecurities.
By inherent insecurities I mean things like people recording their passwords. Written records and unencrypted electronic records can be read by anyone. These digital key managers secure all passwords with a single password, may they be locally hosted or remotely hosted. Records of any form run the risk of tying all accounts together rather than keeping them separate. Even those who memorize their passwords run the risk of entering the password for service A into service B.
Of course the people who think about security usually think about the things that they can control, which is the combination of bits. They rarely seem to address the psychology of the people using their mechanisms (outside of complaining or making unrealistic demands). If they want to create secure systems they need to apply human psychology, and recognize that security is often being applied where it is unimportant.