Hack of Cupid Media dating website exposes 42 million plaintext passwords
arstechnica.com
arstechnica.com
Trusting remote services with plaintext passwords is broken to begin with. We shouldn't give them the chance to mess this up. We need client side hashing and key-stretching that only something like SRP can provide:
https://en.wikipedia.org/wiki/Secure_Remote_Password_protoco...
The sooner we stop pretending there are no better answers than sending the contents of a password field raw over the wire, over SSL or not, and the sooner the web browser vendors and W3C start fixing this, the better. TLS-SRP is a ray of hope, but we need lighter, easier to deploy solutions that work at the application level rather than below HTTP.
On what alternate reality are we living where the W3C are working on Javascript cryptography before improving basic, fundamental, built-in authentication?
Meanwhile, I use KeePass and generate a different key for each service.
Edit: Additionally LastPass supports login to your LastPass account via password + OTP combination such as Google Authenticator and Yubikeys.
There are also peripheral issues with password databases, like the fact that they make the mere fact that you're using one transparent to anyone investigating your activities.
But ofcourse, that's matter of trust, even when they say that data is encrypted client side and they store only blob of gibberish. However I feel so relieved by using LastPass - not having to worry about remembering yet another password.
And one solution, whether it's backdoored or not, is still one target for bad actors to focus on (viruses, spoofing, etc).
If you assume a key logger, you should also assume a mouse logger that captures a partial screenshot for every mouse click, as well as the possibility of capturing the contents of password fields (malware in the Windows 9x era would iterate through all OS widgets to find password fields and save their contents).
[0] http://en.wikipedia.org/wiki/Digest_access_authentication
This is better than transmitting passwords in the clear, but worse than transmitting them over an encrypted link.
Digest authentication can indeed store the password in hashed form. The problem is the the client doesn't need the plaintext password; this hashed form suffices.
See <http://en.wikipedia.org/wiki/Digest_access_authentication#Ad....
And digest auth means a DB dump has enough information to authenticate as a client, which is considerably worse for security if a server gets compromised.
It's so unbelievably popular, Chrome copied the behavior despite not existing in 1999. It's all over mobile, too...
Since the client side of SRP can be implemented in Javascript [1,2,3], there's not really much in the way of compelling reasons not to use it.
[1]: There's a client in the SRP bundle at http://srp.stanford.edu/download.html
TLS-SRP could replace ordinary CA based server authentication, but I think there's a middle ground somewhere. Both are complimentary. CAs should be authenticating servers to my browser, and SRP should be authenticating servers to me.
That said, I agree that there are strong benefits to having support for SRP in the browser.
Less tongue-in-cheek, would you trust Facebook login for banking?
Isn't good for the tin foil hats.
I think even the most non-tech people would react to such a news story.
It would have the obvious portability issues, and I'm sure other implementation issues.
echo 'this is my pass' | shasum 3b0c5dc943cd30dcd2ca1ff760145f219d3ba3f3
And use that as the password. Of course, this is a very basic example, you should make it more safer by adding a salt and running more iterations.
May be easier (and safer) than installing "One password" kind of software.
you can pass a "salt" as the first argument as well (it will merely be concatenated with the password)
A few years ago I whipped this up: http://www.thejach.com/public/pw2 (I don't recommend other people use it but it works for me.) I type in something along the lines of "my secret passphrase ycombinator.com". It doesn't do hash iteration and uses the hash as a seed to Python's RNG which I use to get random bytes and then have a password character-space of any printable character -- it also outputs an alpha-numeric version along with different string sizes to handle those dumb sites that put restrictions on your password.
I've been running it for years, which feels quite nice when sites start leaking passwords left and right.
Thank you for sharing, I am going to download this immediately. My current algorithm for passwords is human based so it is an unfortunately simple algo. It provides some additional security over raw reuse but not enough for me to be comfortable.
Available online and as browser plugin for the major browsers.
The already mentioned supergenpass seems nice as well.
Apple/Google/Microsoft can bake in cross-device syncing into the browser/OS and apply this sort of thing on form auto-fill.
It'll break down when:
a) Hashes don't meet site-specific password requirements (too long, missing special characters, etc.)
b) Sites store passwords in plaintext and you forgot your password and ask for them to email it to you (user: What the hell is this garbage of text, I didn't type this in!)
Unfortunately the above problems usually occur on sites where you need this most, and are very hard to solve, and so this problem is therefore unlikely to be solved "neatly" by anybody big.
It's that dismissing actual options because they are not as good as hypothetical options is fallacious reasoning.
It's about taking the actual world seriously, on its own terms, without getting tied up in knots about the parameters of the ideal world.
Right now we don't live in a world with a better browser security model. Regardless of whether any one of us individually argues for such a world, the current world is where our professional duties must be discharged.
> Regardless of whether any one of us individually argues for such a world, the current world is where our professional duties must be discharged.
And there are plenty of people pushing for bcrypt/scrypt and such every time this happens. My duty in this case is to point out that this will never end all the time we allow the possibility of recurrence.
There's a real danger in going too far and making bcrypt/scrypt solutions doctrine. There are still plenty of people out there who continue to tout hashing with SHA-1 and salts of a certain construct, because at some point they understood why it was important, continue to have the security conscience, but are not up to date with the new realities.
This is why solutions at the architectural level, and not in the application or framework are so so important. Why oh why oh why, don't we have a column type in SQL databases specifically for storing passwords?
It's not beyond the realm of possibility that browsers might be updated to support some form of Secure Remote Protocol standard. And to encourage web sites to use it browsers could display a little 'padlock' icon similar to the HTTPS icon.
This step has concerns of its own though... for one thing the request itself reveals that the username/id is valid, and if you cache the userid / salt pair on the client machine it's vulnerable to snooping by other people with physical access. There are some fairly straightforward tweaks that can be made to the protocol to work around these issues though, since the salt isn't sensitive. In fact, I'm pretty confident storing the salt server side can be eliminated.
Does it have to? Can you not have an implementation that always responds with a fake salt if the username is not valid?
It adds no security.
Server-side salting and hashing is the answer.
Edit: and BTW, Cupid.com has nothing to do with OkCupid. They were the cause of much confusion throughout our history. We'd tell people to sign up for OkCupid, and they'd go to Cupid.com. Eventually, Cupid.com had to say, in their radio ads, "Not OKCupid.com, go to Cupid.com!"
Where H() is chosen, and only ever performed by, the client. As you suggested, I'd recommend using Scrypt for H. The poor evolution of SRP is tangential to the concepts and protocol
Of course, you can guard against that particular case. But the point is that SRP has pitfalls, just like every other solution. And those pitfalls aren't well known; the Wikipedia pseudocode makes no mention of that exploit, for example.
1. Carol will abort if she receives B == 0 (mod N) or u == 0.
2. Steve will abort if he receives A (mod N) == 0.
3. Carol must show her proof of K first. If Steve detects that Carol's proof is incorrect, he must abort without showing his own proof of K.
[1] Ok, the python code doesn't seem to, you're correct. However, that's less a demonstration of a protocol implementation, and more a demonstration of the protocol's math. The page does mention it though in the protocol section. It would be appropriate (and maybe later I'll do this) to break that out so it's more obvious.
Alice: At the time I thought Eve was the only one I had to worry about. Little
did I know, Carol would be the one who'd really replace me in the end.
The math for the brute force attack on SRP verifiers is slightly more elaborate than that of a salted hash (it involves a modexp), but is significantly cheaper than bcrypt. Using SRP is, from the perspective of a compromised server, worse than using bcrypt.
You may have become confused about SRP because Thomas Wu goes through some effort to explain how SRP is resistant to dictionary attacks. If so, you've mistaken which specific dictionary attacks he was talking about: previous challenge-response protocols were dictionary attackable off the wire, meaning that a passive attacker could grab the challenge-response sequence and crack that as if it was a password hash.
Edit: it looks like it should be possible to replace H() in SRP with bcrypt or scrypt. Wouldn't that mitigate brute forcing from server hashes?
But, of course, the point isn't that SRP is a weak construction. The point is "client side stretching", whatever that was intended to mean, has nothing to do with the problem of losing a database of password "verifiers", be they plaintext, salted hashes, password hashes, or SRP v-values.
I'm not wrong, you're just missing the point. The derivation process happens on the clients machine, so they get to 'chose', and verify, how it's performed, and can therefore ensure the KDF is extremely strong. The server doesn't need to know how it's strengthened and cannot, in fact, even discern if the verifier it sees is derived from a random value or through some purely deterministic process.
The objective here is to stop trusting the server with our passwords because they're prone to being lax, not prevent every conceivable technical attack from supercomputers from, and algorithms known only to, the NSA.
> Using SRP is, from the perspective of a compromised server, worse than using bcrypt.
First of all, you can use Bcrypt inside SRP, so the password cracking route is a wash. It's the same, by definition. Secondly, I never said SRP6a as currently specified is what we should use. I said a protocol like SRP and even put emphasis on like. Elliptic curves are the way to go for compactness and speed these days.
An attack on the verifier is going to be vastly less feasible than attacking the KDF. The current best algorithms for breaking a good asymmetric verifier would be many orders of magnitude more complex than just bruteforcing any real world password input, even if it's heavily strengthened with Bcrypt or Scrypt.
100ms of PBKDF2/SHA-256 on a modern server CPU gives you maybe ~20 bits of strenghening on top of a weak ass ~30-40 bit password. Scrypt will give you maybe ~16 more bits, with a sigificantly higher hardware (memory) cost. Total, that's still a long way off the ~120 bits achievable trying to solve the DLP on an elliptic curve. In the end, cracking that verifier is more expensive.
I like 2FA. Most people like 2FA. If you had started out by saying "passwords suck, the answer isn't bcrypt, it's 2FA", I'd have agreed with you. Instead, you said "SRP", which simply doesn't solve the problem you're purporting to solve.
† To see why: imagine your SRP-derived client-specified verifier generation protocol was adopted: you'd have three mainstream implementations (NSS, Safari, and Internet Explorer) based on passwords all of which would have the same security as simply doing scrypt on the serverside; the additional "win" of your proposal would be the oddball clients that did something other than scrypt, where SRP would give them a challenge-response framework they could layer their system on. Awesome. That's what 2FA systems do. And they don't rely on passwords at all.
If you're going to reimagine all of HTTP authentication, why on earth would you drag passwords along?
2. There are a lot of specialty dating sites out there.
Looks like coldfusion to me, which has had a host of vulnerabilities pop-up in the past couple years. Wouldn't be surprised if that was an easy entry point.
I few years back I took over development of an old PHP website, which had a horrible code base (no framework or library, not even MVC). This site had around 30,000 users, all with plain text passwords.
It took me all of a couple of hours to get the site using bcrypt.
I'm not saying I'm some kind of super-rock-ninja-star developer, just that this is so easy to fix, even on monstrosity, legacy code bases.
There really is no excuse.
If a site is using plaintext password often the owner asked for it. They wanted their users to be able to recover their passwords. And the dev didn't understand why this was a bad idea. They need to be educated, convinced and then convinced that the time you're about to spend on fixing this is more important than the 101 other things going wrong because the original dev wasn't very good. And isn't actually causing a single problem right now.
That also means that the password recovery function uses this code. Maybe there's an auto-user generator when you sign up for the newsletter. The email system obviously also uses that code. That also sometimes even means the password is stored twice, once in the framework's user mgmt tables and once in a user or person or the tblPRSN_UPDATED_OPTIMIZED_mc table. And just deleting that column might cause all sorts of other problems. Setting it null might cause bugs. Setting it empty string might cause a massive security hole as there's a login mechanism you haven't even found yet. (remember the dropbox breach?)
It's never a 3 hour job to fix unless you're very bad at estimating, are working on something extremely trivial or do a half-ass job, potentially introducing a far worse security hole.
The problem a dating site probably has is people who sign up accounts and then stop using them. They want to send these users reminder emails in the hope that some of them re-engage.
Problem is that some of these users have probably forgotten which password they use for that website, and some % of those will not bother using the password reset mechanism.
So someone in marketing has the bright idea of sending emails that include the username/password combo, the dev explains why this is a terrible idea and then gets overruled.
It can be difficult to argue for security in cases where even small % of short term revenue might be affected.
There are loads of sites built year ago that just work so nobody is looking into the code base ever.
The barrier is not difficulty. The barriers are lack of time to spend on infrastructure/security improvements, lack of motivation, and distraction due to new feature requests.
Of course forgoing these things will bite you in the end, but this is the internet age; people don't tend to plan that far in advance.
Adobe had source code taken, vB gave over pretty much complete server access.
You now have Cupid Media not even hashing passwords. The final defense of user information ignored..
It took me 3 days to implement password security on a legacy system. Implemented password strength requirements. Users trying to sign in with weak passwords were flagged and forced to change their password to meet new requirements. Plain text passwords were hashed with bcrypt. One guy.. 3 days.
The UK has ICO. I would like to see these getting involved in cases like this. Where they can fine websites catering to UK users who show negligence when storing user information. If it is not currently within their powers I would like to see a law change. There should be more accountability for website owners.
Much of the web software that powers the front-end is complex (PHP, Java, .Net, JS, CSS, SQL, includes, 3rd-party libraries from everywhere, etc). That complexity has a broad attack surface that is difficult and time consuming to test. And many devs are late to the security party (unless we're talking OpenBSD developers).
Management wants to push out new features by X date. Devs have very little time to test and are behind on security anyway. Hackers have all the time in the world to poke at the web front-end and test every possible combination of things until they finally get in.
In a nut-shell, that's the problem as I've seen it.
This is why it is often silly when articles condemn users for weak passwords when a password list is stolen. The proper assumption is that any password I use is stored and transmitted in plain text and just now falling into the hands of bad people.
This is the reason that until I started expressing this idea on HN, that my HN password was "hackernews". If HN was breached, I was no less secure. Sans the pursuit of lolz, it wasn't even worth trying to guess.
Of course, I changed it to something harder to prevent mischief since some individuals might have seen my comments as a challenge.
To put it another way, where there is no reasonable chain of trust, I provide useless data for determining my strategy where there is a reasonable chain of trust. Revealing '11111' does not improve the probability of an attacker generating my bank password.
What? The attacker could infer:
* that you consider this account to be valuable and have created your own strong password for it.
* that you are a security conscious individual and keep a list of hand-generated passwords written down in a safe by your desk.
* that you may be running one of any number of password managers.
... in other words, it tells the attacker nothing.
That's not to say that using a junk password for a junk account is bad, just that your logic doesn't follow.
>Revealing '11111' does not improve the probability of an attacker generating my bank password.
Neither would me revealing my password for a throw-away service is "Sfx16tJ{=DK=x4A0v". What can you infer about my bank password from that?
If I only made an account on one of Cupid media's sites because I wanted to see a picture, I wouldn't care whether my password was easily guessable. Additionally, I'm fairly sure that an easy to make account with no access privileges is completely worthless to an attacker as well, and so the likelihood of anyone even attempting to compromise it is next to nothing.
If you are a designer for instance, you'll most likely come to depend on Adobe Photoshop. That means at some point you've created an account. Adobe got breached and your data got leaked, you'll likely whine a little about it online but unless you are willing to:
- shift your work and relearn a new tool than Photoshop
- navigate your way around closing your account (with the assumption that your data is actually deleted after account closure) which is rather hard in most cases, no one likes losing users.
Then you'll likely just suck it up, do what you can and hope for the best.
On the other hand, you got small time (but growing - not web-scale yet-) services/products that can't really afford losing a large number of users. Those would worry most about security. Ironically, they'd stay off the grid for long enough and wont become attack targets until they make it big.
But that's just really the security industry, no system is 100% secure. And you never know if you've tightened your security enough until someone drills a hole. Then you patch it.
Any self respecting corporate will have a security auditing policy. The so called white-hat hackers or pen-testers. Good companies will run security audits every now and then in hope to discover new security holes introduced by software updates, system policy changes...etc.
As for legal pressure, it depends on what we are talking about. If you are a payment processing company then any data breach is a violation of your PCI compliance, which leads to a lot of bad PR and legal consequences.
If Facebook got breached and data was exposed, I doubt there is anything in the law that reacts to such issue. Unless someone sues Facebook for damages, then that's a whole different ball game.
The incentives are there for any business of all sizes. Legally? It depends. It's those schmucks that screw us all, plaintext passwords and shit.
Edit: Fixed formatting.
I mean most people don't really understand about web security or computers right? So if their email gets "hacked" they think "hackers" magically get access to their computer/email/etc. and Adobe, etc. isn't at fault.
Oh wow. So Internet dating users are generally stupid, under-endowed, desperate and overweight?
And yes.
When are we going to see legislation enacted to take these people to task?
Surely there is a case to be made that their negligence causes (or has the potential to cause) real harm to their users.
We need a Saul Goodman to put together a class action.
And how would you enforce this ? mandated paid audits provided by companies that have lobbyists and friends in Washington ? Enough with the laws, laws are not an answer to every problems. If there is harm , let the users sue, but stop with your laws...
Of course, you also need guidelines for implementation.
No, that would be quite silly and wouldn't work.
It could simply be reactive rather than proactive. When an incident occurs where sensitive user data is exposed, simply launch an investigation into whether there were "adequate" protections in place. If it is found that sensitive data was stored unencrypted, for example, put the directors of the company behind bars for negligence.
I'm dreaming of course. Steal a loaf of bread, life in jail without parole. Expose the private data of millions... have a strong whisky, put out a press release, head to the golf course.
If "adequate" protections are missing: Pay every breached user $10.
That way such a breach gets a hefty price-tag and devs/PMs could argue with management, that it is economically feasible to implement these measures.
I know of a PM, that tells devs, that report security-problems inside his product, that they should not care, but instead finish "that news shiny little thing" and that that is their job in his opinion, not detect some strange security-problem.
If a shop wants to insure it's stock, the insurance company tell them what they need. An alarm? Big metal shutters? A night guard. Depends what you are guarding.
In practice, a password is pretty valuable. Not to the company, but the loss to the user can be pretty significant.
In the UK, the Data Protection Act does allow fines against companies that fail to encrypt specific information (inc passwords). They handed out 2.5MM in fines last year, but I think they mostly go after people selling data, rather than just messing up and losing it.
Recent UK fines: http://www.ico.org.uk/enforcement/fines
OH WOW they fined sony after the geohotz hack http://www.ico.org.uk/enforcement/~/media/documents/library/... (only £200'000, but still)
There will always be an endless parade of poor choices. If it's not 'this,' it's 'that' and then the next 'thing.' There is no scenario under which a government entity can enforce, keep up with, or properly control such.
There needs to be a strong deterrent.
Get the government involved and it won't be long before you need to fill out 15 forms and hire a lawyer to put your weekend project online. Is that the kind of internet you want?
Yeah, all those sanitation codes do is put a big layer of ineffective bureaucracy between the people prepare food and getting work done.
Honestly, people are not going to change their password habits, i.e. we can't expect users not to reuse the same password at different sites. Moreover, I would wager that most people trust that websites are inherently secure and that password-related functions are safe.
The party to blame, then, is squarely the website that allows the leak of unhashed, unsalted passwords.
I believe we should seek legislation similar to HIPAA wherein the damages are inversely proportional to the ignorance and mitigation preparedness of the party to blame. (Damages might also be directly proportional to number of accounts breached, but only after the former is considered.)
As an example, imagine that a kid acting alone gets his forum or website broken into. There's probably not much that a teenager would have known about password security. Additionally, they probably weren't servicing millions of users as a part of a commercial service. You can apply this same kind of situational blamelessness to small businesses, clubs, churches, and so forth.
If, however, a multi-million dollar company gets breached, it's a likely different story. Such a company has employed engineers that are familiar with such topics as scaling and cross-browser support. If these types of business concerns are known and handled, then it's almost a certainty that they also know about password hashing. (If not, I would bet that new legislation would result in widespread education on the issue.)
If the cost of changes is estimated to be too high, we could even go as far as to lower or absolve damages if the 3rd party were to inform its users that its passwords were not hashed or not salted; a "use at your own risk" notice, if you will.
I feel strongly that we need to do something drastic about unhashed/unsalted passwords. This is becoming absolutely ridiculous; it makes our profession look like a circus show, and all for something that can be easily avoided.
i've seen people using them, and if i were of a less honourable persuasion i could abuse that quite easily... on the other hand, its impossible for me to steal information from out of their brain (so far at least).
It's easier than you think to steal passwords from people. Just ask for it!
http://www.veracode.com/blog/2013/03/hacking-the-mind-how-wh...
Because now you need to steal two things. My password file and my password.
Now admittedly the one weakness is that once you have both those things you have access to all my passwords, but on balance I believe it is an acceptable compromise.
I use passpack to store different random passwords on all my online services, EXCEPT for my email account. That one is stored only in my brain.