Almost correct password encryption
-
@morbiuswilters said:
@tgape said:
(Note: I've argued with Morbs on this subject, but I think my position is much closer to Morbs' than yours. SHA512 is standard and easy. It's very distinct from SHA1, so even if your code doesn't already support using multiple algorithms, it can still easily see whether the stored password is SHA1 or SHA512. One still needs to code for it, but it's trivial code. Even if SHA1 is secure now, it's old enough it's past time to move on. In fact, I felt the need to move previously, to SHA256. However, since you didn't do that before, doing it now would be silly. And if your vendor doesn't support anything newer than SHA160 (aka SHA1), you should probably look at getting a new vendor, because it's been a really long time since that was best practice.)
I still think SHA512 is too fast to be a good password hashing algo, but at least it's a step in the right direction. Of course, a lot of crypt libraries support bcrypt (in addition to MD5, SHA-1, SHA256, SHA512) and the type identifier is stored at the beginning of the hash. Also note that if you use crypt's MD5 ($1) you are almost certainly using the FreeBSD MD5 which does key stretching (although it doesn't do enough iterations to be good against modern hardware).
I think the real test is numbers: a modern GPU can do 1 billion SHA-1 hashes per second. That means a randomly-generated, 8-character alphanumeric password (which most people would consider reasonably secure and is certainly better than 90% of passwords people use) will take 218340s (2.52d) to brute force. By comparison, the same computer could probably do 10 bcrypt hashes per-second, which means the same 8-character password would take 692351.9 years to crack.
I think that's basically the response I implied you'd give. It is, at least, the response I intended to imply you'd give. My issue big issue with bcrypt is I need to process more than 10 logins per second per CPU core or GPU. I was in a meeting today where this particular point came up, although not with bcrypt. Instead, someone was trying to get us to secretly replace our normal service with Folger's Crystals™. Well, not actually, just something that would work about as well. We, of course, told them no.
(Note: I have nothing against Folger's Crystals™, when used properly. However, I feel that they're much better suited to making coffee rather than performing any kind of computer functions.)
-
@tgape said:
My issue big issue with bcrypt is I need to process more than 10 logins per second per CPU core or GPU.
Yes, but bcrypt has a configurable cost, so if you do need to tone it down some it's quite possible. The expense really doesn't seem so bad, either: a good server will have 32 cores and can conceivably do 27m logins per-day. And if you are doing 27m logins per day, I think you can afford a dedicated server for logins. Hell, it's not even going to be a noticeable cost compared to the rest of your hardware expenditures.
-
@tgape said:
Instead, someone was trying to get us to secretly replace our normal service with Folger's Crystals™.
-
@blakeyrat said:
@tgape said:
Instead, someone was trying to get us to secretly replace our normal service with Folger's Crystals™.
Thank you. I had not known that existed. Yes, that's really more like what I'd have preferred to use as my link. Although, if he could have had a reaction sort of like that - or, better still, had an allergic reaction - without being told about the switch, it would've been exactly what I was wanting.
-
@blakeyrat said:
@tgape said:
Instead, someone was trying to get us to secretly replace our normal service with Folger's Crystals™.
Caffeine is a drug. If a drug dealer stiffs someone on a deal, they end up with a hole in the head. How come the same thing doesn't apply to someone replacing my regular coffee with decaf?
-
@morbiuswilters said:
I would still strongly advocate SSL. SRP doesn't stop someone from modifying the request in-transit (or snagging the session key and sending another request from their own location with the same session key) nor does it protect the confidentiality of the data transmitted nor does it guarantee the authenticity of the server you are connecting to.
I agree that SSL is preferable where possible: apart from anything else, implementing security protocols yourself is a bad idea. But I'm at a loss to understand your objections to the SRP protocol design, because a) most of the statements you make are either false or equally applicable to any other protocol; b) SRP is one of the options available in SSL.
-
@morbiuswilters said:
How come the same thing doesn't apply to someone replacing my regular coffee with decaf?
They do.
Clearly you soft on ur bitchez, yo.
-
@morbiuswilters said:
This is the response I was trying to prod you in to. Bla bla bla security hashing passwords blah
I intended both of you to have this conversation all along! Bwa ha ha!
-
@pjt33 said:
@morbiuswilters said:
I would still strongly advocate SSL. SRP doesn't stop someone from modifying the request in-transit (or snagging the session key and sending another request from their own location with the same session key) nor does it protect the confidentiality of the data transmitted nor does it guarantee the authenticity of the server you are connecting to.
I agree that SSL is preferable where possible: apart from anything else, implementing security protocols yourself is a bad idea. But I'm at a loss to understand your objections to the SRP protocol design, because a) most of the statements you make are either false or equally applicable to any other protocol; b) SRP is one of the options available in SSL.You misunderstand; I'm not opposed to SRP over SSL. I'm just trying to make sure people realize that SRP is in no way an alternative to SSL. Using SRP doesn't make your network access secure because there are so many other things that have to be accounted for. If someone actually cares about the security of their data (and how often do they not?) they should use SSL.
-
@morbiuswilters said:
@pjt33 said:
@morbiuswilters said:
I would still strongly advocate SSL. SRP doesn't stop someone from modifying the request in-transit (or snagging the session key and sending another request from their own location with the same session key) nor does it protect the confidentiality of the data transmitted nor does it guarantee the authenticity of the server you are connecting to.
I agree that SSL is preferable where possible: apart from anything else, implementing security protocols yourself is a bad idea. But I'm at a loss to understand your objections to the SRP protocol design, because a) most of the statements you make are either false or equally applicable to any other protocol; b) SRP is one of the options available in SSL.You misunderstand; I'm not opposed to SRP over SSL. I'm just trying to make sure people realize that SRP is in no way an alternative to SSL. Using SRP doesn't make your network access secure because there are so many other things that have to be accounted for. If someone actually cares about the security of their data (and how often do they not?) they should use SSL.
The answer to your parenthetical question is "Most of the time", sadly, but that aside...The two big benefits to using SSL are that the code has been reviewed by many people, so it's less likely to have gamebreaking bugs than home-rolled code; and that you can use the existing CA infrastructure. (Well, a case can at least be made that the second of those is a benefit). As far as the rest goes, they're both vulnerable to traffic analysis, they're both vulnerable to breaks in the symmetric cipher used after the handshake, they're both compromised if an attacker roots the client or the server (although SRP does better than some SSL protocols in protecting data that was transferred before the attacker got in)... You seem to be presenting SRP as being broken in some specific way in which SSL isn't, but the only specifics you've supplied suggest that you're misinformed about what exactly SRP is and does.
-
@pjt33 said:
The two big benefits to using SSL are that the code has been reviewed by many people, so it's less likely to have gamebreaking bugs than home-rolled code; and that you can use the existing CA infrastructure. (Well, a case can at least be made that the second of those is a benefit).
I don't think either is that big of a benefit. SSL has a history of tragic security problems (although as many might have been found in SRP if it was as widely used); SSL is so fucked that most of the ciphers are no longer considered particularly secure (I can't tell you how often I still see CBC ciphers with TLS 1.0). I mean, the best current cipher is RC4 which itself has a checkered past.
As for CAs: even more fucked. There are almost 1500 valid certs that can sign other certs out there, including ones held by CNNIC and the Department of Homeland Security. And since signing certs aren't bound to a particular domain, a break in any of the signing certs exposes every domain. Add in the bullshit cartel pricing and the bullshit EV racket (having an EV for your domain doesn't stop somebody else from getting a DV for the same domain) and the CA system is almost worthless.
@pjt33 said:
You seem to be presenting SRP as being broken in some specific way in which SSL isn't, but the only specifics you've supplied suggest that you're misinformed about what exactly SRP is and does.
Apparently I knew a lot less about SRP than I thought. I thought it was a better password-validation system, I didn't realize it did symmetric crypto and MAC. A couple of things:
- How does it validate the server? What prevents MITM attacks?
- I still prefer certificates to passwords; unless very strong password-generation requirements are followed the cert will be more secure.
-
@morbiuswilters said:
How does it validate the server? What prevents MITM attacks?
Public key crypto. Essentially the same issue as SSL of requiring either distributing the public key out-of-band or using a CA-style structure.@morbiuswilters said:
I still prefer certificates to passwords; unless very strong password-generation requirements are followed the cert will be more secure.
The "password" in SRP is a number in a large field. It could be obtained from a user-entered alphanumeric string by whitening, but it could equally be generated as a secure random number.
-
@pjt33 said:
@morbiuswilters said:
How does it validate the server? What prevents MITM attacks?
Public key crypto. Essentially the same issue as SSL of requiring either distributing the public key out-of-band or using a CA-style structure.Ah, that's good, then.
@pjt33 said:
@morbiuswilters said:
I still prefer certificates to passwords; unless very strong password-generation requirements are followed the cert will be more secure.
The "password" in SRP is a number in a large field. It could be obtained from a user-entered alphanumeric string by whitening, but it could equally be generated as a secure random number.But my point is, a password can be far less secure than a cert. How do you stop someone from using an insecure password? Of course, a cert can be mishandled, but I think the chances of user error are far less.
-
@morbiuswilters said:
@pjt33 said:
@morbiuswilters said:
I still prefer certificates to passwords; unless very strong password-generation requirements are followed the cert will be more secure.
The "password" in SRP is a number in a large field. It could be obtained from a user-entered alphanumeric string by whitening, but it could equally be generated as a secure random number.
But my point is, a password can be far less secure than a cert. How do you stop someone from using an insecure password? Of course, a cert can be mishandled, but I think the chances of user error are far less.Depends a bit - if the intention is to allow access by the same user from many different client machines, the continual copying of the private key is almost as bad a problem, and certainly creates opportunities for user error.
The most secure approach is to combine the two to use something you have (private key) and something you know (password).
-
@pjt33 said:
The most secure approach is to combine the two to use something you have (private key) and something you know (password).
Agreed.
