8 ms·
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
by nly 13y ago
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:
https://en.wikipedia.org/wiki/Secure_Remote_Password_protocol 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?
- facorreia 13y agoI agree, trusting remote services (and the communication infrastructure in between) is naïve. Meanwhile, I use KeePass and generate a different key for each service.
- nly 13y agoI also use Keepass....but why the smeg do I need to do this? My browser should be deriving per-site passwords for me at a minimum
- Zombieball 13y agoLastPass has browser plugins that do this. Edit: Additionally LastPass supports login to your LastPass account via password + OTP combination such as Google Authenticator and Yubikeys.
- NateDad 13y agoLastPass is awesome.
- nly 13y agoInstalling 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.
- jve 13y agoYou 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.
- nly 13y agoRight, 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).
- nitrogen 13y ago...(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).
- modoc 13y agoSafari on 10.9 does this.
- Pxtl 13y agoDeriving has a problem if you have a site with a login system across multiple domains. You can't salt with the domain if the domain is inconsistent.
- maxtaco 13y agoAnother alternative is https://OneShallPass.com https://OneShallPass.com. Free, auditable and open-source.
- richardwhiuk 13y agoRealistically we need HTTP digest authentication [0] to use a better hash function then md5, and we need it to be deployed by websites. [0] http://en.wikipedia.org/wiki/Digest_access_authentication http://en.wikipedia.org/wiki/Digest_access_authentication
- andrewaylett 13y agoThe 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.
- colanderman 13y agoYour 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. See <http://en.wikipedia.org/wiki/Digest_access_authentication#Advantages> http://en.wikipedia.org/wiki/Digest_access_authentication#Ad....
- andrewaylett 13y agoThat's what I meant by 'a usable representation thereof' -- sufficient data for a client to be able to use it to authenticate.
- colanderman 13y agoYa that wasn't very clear. Thanks for the downvote.
- andrewaylett 13y agoAs far as I can tell, it's not possible for someone to down-vote a response to a comment they've made -- certainly I'm not able to.
- tschellenbach 13y agoWhat about Facebook login (or other oauth based systems)? Seems to me this solves most of the problem.
- chalst 13y agoIt solves the problem with offline password cracking, but it introduces the need to trust a third party. 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 http://srp.stanford.edu/download.html [2]: https://github.com/symeapp/srp-client https://github.com/symeapp/srp-client [3]: https://github.com/clipperz/javascript-crypto-library https://github.com/clipperz/javascript-crypto-library
- nly 13y agoOne 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.
- chalst 13y agoThis 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.
- nly 13y agoYes, I love trusting the keys to all my accounts to one corporation. Less tongue-in-cheek, would you trust Facebook login for banking?
- fauigerzigerk 13y ago"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.
- jiggy2011 13y agoThe problem is that "publicly shamed" means "shamed amongst security geeks". Most websites main demographic is not security geeks.
- fauigerzigerk 13y agoIt 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.
- jiggy2011 13y agoWe 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.
- Cthulhu_ 13y agoI 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.
- ZoFreX 13y agoThe 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.
- 13y ago
- jacques_chester 13y agoThis 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.
- nly 13y agoAnd 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.
- jacques_chester 13y agoThe 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.
- nly 13y agoThe 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?
- bjourne 13y agoI 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?
- MarkMc 13y agoI 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.
- nly 13y agoThe 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.
- vidarh 13y ago> This step has concerns of its own though... for one thing the request itself reveals that the username/id is valid Does it have to? Can you not have an implementation that always responds with a fake salt if the username is not valid?
- nly 13y agoYes, or you can just use a deterministic salt like H ( service id || user id )
- tptacek 13y agoThis 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.
- tedunangst 13y agoFor reference, iirc last time I ran the numbers, SRP brute forcing has a work factor of 1000 compared to a single round of md5. Aka, not enough.
- tptacek 13y agoOh, neat. I'm happy to have a number to file away. Thanks!
- nitrogen 13y agoIs there a variant of SRP that would provide the same level of protection against a server hack as bcrypt? 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?
- tptacek 13y agoYes, 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.
- ye 13y agoWhat's the point of the key stretching on the client side, if your stretched key gets sent to the server and is stored in plaintext. It adds no security. Server-side salting and hashing is the answer.
- hobs 13y agoI 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.
- nly 13y agoIt'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)
- maxtaco 13y agoHow 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!"
- nly 13y ago> The server stores v = g^x, x = H(s, p) 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
- sillysaurus2 13y agoIt'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.
- Jtsummers 13y agoYes 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.
- benjamincburns 13y ago"Up next on VH1's Where Are They Now?, Alice and Bob!" 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. Edit: Hmm, downvoted. I guess humor isn't welcome here?
- greyboy 13y agoUnfortunately, no.
- benjamincburns 13y agoA 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.