Slashdot Mirror
Mitigating Password Re-Use From the Other End
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.'"
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.
liberare massarum ex ignorantia, clausa descendit molestie.
Since the audit entries are being created by the box running the application, it obviously has write access to the 3rd party box. So whoever has access to the application box has access to write (and hence alter) the 3rd party box.
You can tack on more mitigation, but in the end it's the concept that's flawed, not the implementation.
It also ought to be easy for LivingSocial to store passwords hashed with a secure hash designed for passwords, like scrypt (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.
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
So, what happens when that central framework/infrastructure is cracked? Now, all cracking attempts will redirect to that single point, and when (not if) it's breached, they'll now have access to ALL websites that are signed up to use that. How is that better?
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.
+1 IDisagreeSoHeMustBeATrollOrAnAstroturferOrAShill
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.
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.
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,
That sounds like a security and privacy nightmare.
Perhaps users just don't give a f*ck whether their account on some third rate e-commerce marketing site gets compromised?
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.
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!
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
Putting your password in an e-mail during the registration process doesn't mean they store it in plain text in their database.
But it does mean that they send the password in clear text rather than hashing it on the client.
Clear text passwords should never be sent over the Internet, even over secure channels.
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.
2. We should ask the more important accounts like brokerage, mutual fund, bank accounts to use a two factor authentication system. But I don't want to juggle too many RSA key fobs. I like google sending a six digit code to the designated cell phone. Google also lets you set up 10 one time pad numbers ahead of time to handle the case when the cell phone cant get texts. As a first step if they would just send me text or an email for each login event and each transaction that would reduce fraud.
3. What really bugs me is, in this day and age of social network where people are posting details of their breakfast lunch and dinner for the whole world to see, even banks use "maiden name of mother" "name of your pet" or "where you went for honeymoon" to reset passwords. That is insane. So I used to give non intuitive answers like "nissan sentra" as the mothers maiden name. But it is so difficult to remember what stupid answer I gave to which site. That is my biggest beef with these security questions.
4. No I did not switch my username and password edit boxes when I signed up for slashdot. Friends recognize the dorm addresses, rest of alumna recognize the dorm names.
sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
(Result: I can not guarantee that I wrote this message. So what.)
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.
"The question of whether machines can think is no more interesting than [] whether submarines can swim" - Dijkstra
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.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
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.
great, so now we have to remember both a username AND password? That'll make this whole thing even worse! Even worse, if my login is taken on one website then every website has a different log in (and password likely). So now I'm remembering 2xN pieces of information instead of just N.
Welcome to Joe Schmoe's website. Please create your account.
Username: halcyon1234@example.com
Password:12345
Checking...
Server-side...
IF EmailLoginChecker.TryLogInToMailSystem("example.com", "halcyon1234", "12345") THEN
Error = "You're using the same password as your email address. We're mitigating that risk. Idiot."
ELSE RegisterUser();
END IF
UTF-8: There and Back Again