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.
This third party box with json interface already exists!
When u login using facebook, twitter, linkedin, google its exactly that!
Protocol also exists: oauth/oath 2.0!
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.
Don't make users log in with their email address. Give them a randomly generated username and password combination.
This whole practice of forcing you to use an EASILY identifiable piece of information (your email) as one of the autentication factors is just retarded.
I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
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.
Lots of sites support using Facebook for authentication
So that's what I use instead of making up a fiftieth username password combo
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
I use a 2nd password as the "answer" to any secret question. Answering it correctly is a security risk since it can be guessed.
need a password allow the user to select their own, usually insecure password. If each web site generated a secure password/phrase for you this problem would go away. The problem is that people would complain about having to store/remember complex passwords. What is needed is ubiquitous and automatic password management software/hardware that works on any computer, phone, or tablet.
Programs/services like LastPass can make storing/using passwords easy, though their mobile phone app isn't very good compared to the browser app. 2nd credential devices like Yubikey and Google Authenticator are OK too, but there's still too much messing around to do to use them, though I suppose there is some minimal amount of messing around that will always be necessary to prove that you are who you claim to be.
The old spam solution form at http://craphound.com/spamsolutions.txt covers most of the solutions being proposed here.
http://craphound.com/spamsolutions.txt
Common spam problems such as "Ease of searching tiny alphanumeric address space" and "Jurisdictional problems" translate easily to the common password problems of "sending passwords via email is inherently insecure" and "requiring unique passwords for each trivial new website creates enormous keychains that are not safely portable to new computers or software clients"..
Firefox already has password tools - it can optionally store the password from different sites. It should be simple to extend this to warn the user if any two passwords are the same.
Firefox uses *local* storage for this, on the user's computer, so it will be more secure than any remotely-hosted solution.
(Result: I can not guarantee that I wrote this message. So what.)
Why does every dammed web site needs it's on password in the first place?
No human is able to remember them and (together with weird complexity rules and change intervals).
I have not seen a working cross platform (all major OS(Windows + Mac + Linux in different versions), all desktop browsers, smartphone, tablets) roaming keychain solution I trust.
So Open ID Connect (easier ti implement than the clumsy OpenID spec) could be one solution. It reduces the number of passwords to remember, the number of registrations (and confirmation emails). Maybe the only missing piece here is a mechanism to link more than 1 account together (so that the impact of a disabled account (for whatever reason) could be solved easily.
If you have a central service doing this, you might as well just have it be a single sign-on service, in which case password reuse isn't a problem because you only have one anyway.
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
I don't know why more people don't use solutions like Lastpass. I have one very long and difficult to guess password (but easy for me to remember), and every site I visit has a unique psudo-random gibberish password. If a site does something really stupid like store passwords of their users in plaintext, a breach will only allow access to that site since that password is used nowhere else. This method is impervious to dictionary attacks, hash-table lookups, etc. It's a tiny bit of an inconvenience, but it's very secure and I don't have to worry about breaches like this at all.
-S
--- What parts of "shall make no law", "shall not be infringed", and "shall not be violated" don't you understand?
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.
People make secure systems insecure because insecure systems do what people want and secure systems don't.
I wish I'd said something that pithy, but it was James Grimmelmann who did.
kind of how Gmail will alert if I am logging in from a strange location
Unlike PayPal which just fails with no remedy if you try to pay for something from outside your usual country.
Why don't sites support two-way SSL? If everyone had a cert signed by trusted Certificate Authority then we could eliminate manual login. The trick would be making it easy/cheap for everyone to generate keys and csr's, and install the cert. Current tools for that are probably beyond the ability for 99% of Internet users.
The sites can only send new log entries to the third party server, not modify existing entries. Any bogus records would have the effect of locking down the accounts that the hacker is sending bogs data for. Adult sites have been doing this for many years using systems like Strongbox, and it works.
To clarify something other people brought up, the remote audit system doesn't store passwords. It stores information about log-in events - who logged in from where, using what type of hardware, which browser, which version, etc. It then audits that information. Suppose for the life of your account you've always logged in from Kansas, US, on either a Mac using Safari or an iPad. Today, someone claiming to be you is trying to log in using a Windows XP machine in Russia, and also someone claims to be you logging in from a web server in China. The system would flag that, knowing the web server is probably a zombie.
That's a very basic overview of a fairly complex system, but if you've ever visited a site like members.GirlsGoneWild.com you've already had this type of auditing system protecting your account.
The audit system doesn't store passwords. It stores information about log-in events - who logged in from where, using what type of hardware, which browser, which version, etc. It then audits that information. Suppose for the life of your account you've always logged in from Kansas, US, on either a Mac using Safari or an iPad. Today, someone claiming to be you is trying to log in using a Windows XP machine in Russia, and also someone claims to be you logging in from a web server in China. The system would flag that, knowing the web server is probably a zombie. Adult sites have been doing this very successfully for years, using systems like Strongbox.
That's a very basic overview of a fairly complex system, but if you've ever visited a site like members.GirlsGoneWild.com you've already had this type of auditing system protecting your account.
No more need to store passwords on the site (unless your are an idendity provider), no more need to try mitigating the reuse of the password...
https://login.persona.org/about
https://developer.mozilla.org/docs/persona
Hmm. Now who might be offering just such services?
I thought I checked "Ads Disabled".
Have gnu, will travel.
1. Let users create accounts with passwords
2. Set up a bot that tries the name/password combination at every other site.
3. When login succeeds at another site, use the opportunity to delete/terminate the other account.
4. Profit?
So... they want to reinvent RADIUS... again.
Since browsers cache passwords for me, and I don't remember them anyway because I never type them after the browser remembers them for me, why not have a browser plug-in that generates GUUID passwords? Each site would have a unique browser-generated password, so if one was compromised, that would be it. Good luck cracking my password with John the Ripper. Human-understandable passwords seem unnecessary.
Why are we even bothering with this concept? People need to be responsible for their own security. If each site clearly posts instructions on why a strong unique password or a token is a good choice then that should be enough. If the user decides that they want to make all of their passwords for multiple sites the same simple password then let them. They make a clear choice and they can live with the results (good, bad or indifferent).
I think that this situation is similar to a lot of other non-online life situations. Quit coddling and hand holding me through a limited number of choices just because someone else is not willing/able to make what others consider to be "good decisions".
If your site doesn't believe that a strong password is enough and wants to offer another type of verification or your customers are requesting it then fine make those available. But don't force me to use a "better" system because of that.
First off, static passwords will never be secure as a keylogger can intercept them. A perfect solution would allow for challenge-response on the meat-space side.
I was starting to get some obnoxious password requirements and actually needed secure passwords that would not be stored in "keychain" on the mac or on a post-it note. My solution was to make a simple script that concatenated a built-in token with one of my common passwords and the website name, made a MD5 hash and packed it into a 12-character quasi-uuencoded form (some characters were forbidden). It is a kludge, but it avoids password re-use, and I can change the website name to something I associate the website with if I am feeling especially paranoid.
The adult industry does not do this to protect your account.
They do this to stop credential sharing. It was (is?) common to find websites listing logins for adult sites. By auditing the login process they can detect these leaked/hacked/shared/given-away credentials.
If you are going to do this, then why even let the user choose their password? Use an algorithm to create user's passwords (for example, randomly select a length, then randomly generate a password). Guaranteed strong passwords.
Yes, users will write it down. Is this worse or better than what is happening now?
(For the most part, I prefer OAUTH. I let Google handle the two factor authentication.)
What, me worry?
So they can "compare them"?
Perhaps they'll see all my logins are different, but I use the same scheme... ie MyDumbAssPW1...MyDumbAssPW2...MyDumbAssPW3...etc
It wouldn't be so bad if they let you choose your own question. Very few do this. Apart from the kid who shat himself doing the long-jump who remembers (or could find out) the kid who shat himself doing the long-jump?
As you say, lying consistently is very difficult. Even if you adopt a persona, you have to remember for each site whether you answered as the guy who played left tackle in HS, Donald Sinden, or Baruch Spinoza.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
JSON has officially overtaken XML.
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
Well, if you did that. You'll love this scheme in the above post. You'll have a central site telling you that that login and email is useful somewhere. It's like printing theft gold. You won't even need to try it blind, it'll just flag it and tell you if they gave you a useful username and password.
*chaching!*
It is no longer uncommon to be uncommon.
The problem there is that if they get a plain text password it might be determinable, also there's too much secondary issues.
A better password algorithm is something like preface the passwords with something like #1 (for the alpha numeric requirements) and then invent a word alphabet for the letters like various animals. So say you take the last three digits of the site name. Here DOT, you'd have a password #1DogOstrichTurkey -- It would be unhackable, hard to figure out how you made it, and you'd be able to dodge those alphanumeric and capital lowercase letter issues. Site unique and with enough bits to make take a few hundred years to brute force, and you'd never forget it.
* For those curious, no I don't use a password anything like that don't fucking bother.
It is no longer uncommon to be uncommon.
Why don't we just accept modified song lyrics that produce zero google matches as pass phrases?
If your Lastpass DB is corrupted, goodbye passwords.
The Lastpass DB is stored in the cloud and is synced over several devices. Pretty unlikely.
And before you say it: The Lastpass DB is Client site encrypted using the master password. So the master password is something I know and all the other “passwords” are indeed now token.
for example, randomly select a length, then randomly generate a password
Because then users will write them down. As they say in mechanics: After very tight comes very loose. (as in: the screw breaks off).