Before the bcryot/scrypt advocacy and general shaming starts... I'll just make the same comment I always do when this happens: the answer is not more sever side hashing.
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:
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?
This is flatly wrong. SRP stores serverside verifiers that are derived from plaintext passwords. Stealing an SRP verifier is equivalent to stealing a password hash.
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.
> This is flatly wrong. SRP stores serverside verifiers that are derived from plaintext passwords. Stealing an SRP verifier is equivalent to stealing a password hash.
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.
If the client can choose any mechanism it wants to create a verifier, the system you propose is (a) not SRP, as you concede, and (b) really just a clunkier way of doing 2FA†.
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?
Yes, in the same way that simply using scrypt would.
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.
"The answer" doesn't exist and it never will. Everyone has to do their part. Services that store passwords in plaintext should definitely be publicly shamed, every single time.
I dunno, things like this make their way to more mainstream media too, making "the general public" more conscious of security, and making them wonder whether their passwords will be secure at parties they leave them at.
The spin in mainstream media always puts the blame squarely on the hackers, and in my anecdotal experience typical users have no interest in the argument that the companies that were hacked are to blame.
Because most people have not even thought of the possibility that password can be stored in anything but plaintext, and take it as granted that all websites do. Thus the websites can't possibly be blamed, and the hackers must be the bad guys.
Not necessarily. If a relatively mainstream news site reported the event and quoted a security professional saying:
"Website X didn't even try to keep your love life and dating profile a secret. Every single user's password is now publicly available. If you use the same password on multiple sites, be sure to change it quickly!"
I think even the most non-tech people would react to such a news story.
The adobe breach was fairly widely reported, but how many designers have sworn off adobe products? The same thing could be said about Linkedin or Microsoft products in the 90s.
It means being shamed among tech professionals and that's exactly the community in which those responsible for the disaster have to spend the rest of their professional lives. Peer pressure is very effective.
We don't even know specifically who is responsible for this particular thing, as I've mentioned in other comments it's likely this came from some non tech person anyway.
True, but I think this is one of those instances where you kind of have to take what you can get in terms of negative PR for Cupid Media and other companies that store passwords stupidly.
A browser plugin that pre-hashes anything in a hidden text field (with a user secret key and the password origination domain) could mimic this as a layer on top of existing technology.
It would have the obvious portability issues, and I'm sure other implementation issues.
How have I functioned as an adult for so long without knowing that this plugin exists?
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.
This is (hopefully) a problem that platform owners can solve for us, and if they do I'll love them for it, but they very likely won't take it on.
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.
That doesn't quite work in the unfortunately common case of user password re-use. If your hash is constant and stored in plain text somewhere and that place gets hacked -- then your password at every site is compromised.
If you use an actual bash script instead of a one-liner, and you can do things like 'silently' read in the password with `read -s` in the standard *nix convention, even read it twice to avoid mistyping your master key and temporarily locking yourself out of an account you just created.
You should quote your vars in the if check, otherwise it doesn't handle spaces very well. (And really the master key should be a master passphrase.)
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.
Might be an extreme comparison (beg your pardon if I'm being naive), but it's a similar hinderance to using SSH keys. Carry it around on a USB key, or deal with the security outweighing convenience.
How does SRP help? With SRP, you still have a server-side brute-forceable table of password hashes. The server stores v = g^x, x = H(s, p), for each user, where s is the salt and p is the password. g is known to the server (and hence the attacker), so if the attacker downloads the database, he can go through the dictionary and brute force. If you're rolling out SRP, you ought to use scrypt for H.
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
The trouble with digest auth is it requires the password or a usable representation thereof to be stored in recoverable form. This means that if you can get a dump of a site's database, you can use the stored credential data to authenticate to that site, which isn't possible when you store hashed passwords.
This is better than transmitting passwords in the clear, but worse than transmitting them over an encrypted link.
Your point is correct but AFAIK your facts are incorrect.
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.
Additionally, you'd need new browser APIs (AFAIK) to detect failed logins, render the login UI, etc. Otherwise, it's going to look out of place and confusing. Product managers are unlikely to accept the default browser/OS handling.
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.
Kinda. The important thing to note is that back in 1997, when the digest auth RFC was written, we recognised the hashing before going over the wire... and somehow we lost sight of that
The browser implementers completely punted on making HTTP authentication usable: there's no friendly way for a user to logout, for the server to force a logout, for the user to change a password, etc. All of these were well known and discussed from day one but they weren't seen a priority by any vendor and most web developers went with usability over security.
It's interesting that no one's pointed out that SRP is trivially breakable by having the client send zero as its "A" value.
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.
Yes it does [1]. In the narrative example with Steve and Carol, it states 3 safeguards.
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.
A bit of transparency: Before the edit I received one downvote. After I received 5 upvotes, which is on the higher end of most of my comments. Either I reacted prematurely, or calling it out reversed the perception bias to the positive. I think it's some of both, as the joke really wasn't funny enough to warrant the score.
Installing lastpass on every machine I happen to stroll by and want to use isn't the cleanest of solutions... and I shouldn't have to trust my keys to one closed, proprietary application. With a standard protocol at least I'd have a choice about my client.
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.
You can ofcourse log in to lastpass.com on any other machine you are sure doesn't have a keylogger (well they provide virtual keyboard also if thats the case).
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.
...(well they provide virtual keyboard also if thats the case).
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).
Right, but even if we can check all the boxes and trust LP, there's still the practical matter of getting everyone to use it. Generally it's going to be easier to convince users to use something that's built-in rather than 3rd party, right?
And one solution, whether it's backdoored or not, is still one target for bad actors to focus on (viruses, spoofing, etc).
This is an is/ought fallacy. As professionals we don't get to propose the ideal universe as the solution to the problems of the actual universe. We have to take what we can get right now.
I don't think nly was proposing an ideal universe, just an improvement to the current one.
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.
And that's a false dichotomy. Are you saying we should dismiss dangerous flaws in the trust model, just because we have some workarounds for bad industry practice, and can 'make do'? because I'm not saying we shouldn't advocate strengthening existing databases right now. To me, the two concerns are completely separate.
The is/ought fallacy isn't about saying that the actual world and the ideal world are mutually exclusive; that you can't get to the ideal world from the actual world.
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.
The false dichotomy I was referring to isn't the 'introduce bcrypt' vs 'introduce a new model' thing, those things clearly aren't mutually exclusive, it's that you inferred that me pushing for one means that I'm totally against the other in the present day. In any case I have no desire to join a thread about fallacious reasoning and semantics.
> 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?
One of the key aspects of SRP is it provides mutual authentication. The server is considered untrusted until authenticated. If you run it in Javascript you lose the benefits it has over simple challenge-response client authentication.
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.
This isn't quite right: you still keep the benefit that the server in no sense has a copy of your password, and it is publically visible what the program is that implements the client-side authentication.
That said, I agree that there are strong benefits to having support for SRP in the browser.
Well, I do actually think the fb engineers working on login and password security are more competent than the ones that my bank currently has (8 character MAX length....). The only edge that banks have is that they know to scrutinize suspicious logins more heavily, which is something that fb would certainly do if their login was ever used for bank logins.
No friggin way. I disabled that for a reason. I won't use Facebook login for anything else except Facebook. I don't want my Facebook identity being shared with a third party.
Security is all about pragmatism: is it more likely that Facebook / Google will be hacked and not deal with it quickly or that users will react to incessant password nagging by using weak ones? When someone's account is compromised, is it better if they have to change one password or hundreds?
I agree with you that a technical solution is needed. Forcing developers to store passwords securely, experience shows it doesn't work. But how exactly would your solution work? If I work at a computer I haven't used previously, how am I supposed to authenticate to a site without using a password?
The first step in the SRP protocol is to retrieve the cryptographic salt from the server, so you're essentially free to roam.
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.
I think the idea is that the browser would implement SRP. That means you would still type a password into your browser, but it wouldn't be sent to the server. Instead, the browser and server would authenticate you by means of exchanging specially-designed hash codes.
It's not a vanilla stretched key that gets send to the server. It is, in effect, the equivalent of your public key (that just happens to be kept secret by the server so it can use it to prove its identity, as the bearer, to you)
I think the use of that is really just isolating the cross site hacking at that point. You are absolutely correct that if they have your password, its game over on that particular site.
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?