5 ms·

I expected daily-WTF like idiocy, but Dave's code isn't insane. It's a pretty standard combination of a (sufficiently random) salt and a SHA1 based hash. SHA1 w

by gizmo 14y ago

I expected daily-WTF like idiocy, but Dave's code isn't insane. It's a pretty standard combination of a (sufficiently random) salt and a SHA1 based hash. SHA1 was until recently regarded "strong enough". Dave's code is unnecessarily obfuscated, but whatever. I don't see how this can be considered "homebrew password security" given that all the heavy lifting is done by SHA1. Anyway, Dave's solution is as good as a SHA1 based solution gets. That's already better than 95% of the websites out there (citation needed), but of course worse than the bcrypt approach suggested by the OP. The OP pretends to innocently ask "Is my developer's home-brew password security right or wrong, and why?". I'm going to call BS on this. To me it's pretty clear the OP is trying to passive-aggressively bully/ridicule/shame Dave in order to get his way. And sure enough, the top ranked StackOverflow has somebody going through the code line-by-line going WTF at every opportunity. The OP isn't trying to figure out whether he or Dave is right, he's clearly already convinced he's right and wants the StackOverflow community to collectively pat him on the back. Kind of childish.

Lagged2Death 14y ago
To me it's pretty clear the OP is trying to passive-aggressively bully/ridicule/shame Dave... I had a different interpretation; OP is "Dave." It's sort of a time-honored tradition, on-line and off, to seek advice "for my friend."
- gizmo 14y ago
  Nearly impossible. Every single sentence in the post provides evidence against that theory. (Dave "Insists on using a home-brew script" / use of "Homebrew" vs "Standard solution" / Dave's "primary hang-up" became clear after he "immediately balked" / Ridicule of Dave's code is "sincerely appreciated", etc). It's so over the top that the entire post may just be an elaborate troll.
  - Lagged2Death 14y ago
    Nearly impossible. Every single sentence in the post provides evidence against that theory. On the internet, nobody knows you're a Dave.
Xylakant 14y ago
sha1 has the same features that make md5 a bad password hash: It's very memory and computation-efficient. It's relatively easy to implement in hardware. That makes it susceptible to brute-force attacks since you can test far more passwords than with any other algorithm. That doesn't mean that sha1 is a bad hash, it's just for a different use-case. You can stretch sha1 and make it more cpu-intensive by hashing multiple rounds - then you've invented pbkdf2.
xer0x 14y ago
Totally agree. The tone of this question and its answers really bothered me.
thaumaturgy 14y ago
That's not a salt, it's just broken. A salt can (and should) change from user to user, but not from minute to minute for the same user. That's why salted hashes have the salt stored as a substring of the hashed result: so that you can recalculate the hash using the same salt that was used the first time. The mistake in the code here is that the "salt" is being hashed along with the password. Oops. Just to be sure, I ran the code twice, a few seconds apart, using "rob" and "password" for the parameters. Here's the results: Hc3fba318ec5f25ef74e0067e27bfa187f1385d3b He66effce74bb1ae41e3a2344b91d5fe1c6205ee0 It doesn't work.
- gizmo 14y ago
  Presumably the salt is stored separately in the database.
  - thaumaturgy 14y ago
    That would be fair, but I didn't assume so since that wasn't mentioned in the original post.
    - RyanZAG 14y ago
      He does seem to imply that Dave's solution works, and if you read the last line: $hash = hash_it($password, $crypt); So it is fairly clear that $hash and $crypt would be stored in the DB. $crypt is a reasonable (but not great) salt: crypt($user.$time.$rand); $user is obviously known, $time is the time when the password was created - or maximum ~2000 possible values for most systems. The main part of the hash is $rand, which is 31 bits of pseudo-random entropy. So about 40 bits of entropy if I'm not mistaken? That should be enough to make it infeasible to create rainbow tables in advance. EDIT: I'm wrong on $time - it is "mdYHis", so much more than 2000 possible values and is actually pretty decent in the salt, as it's unlikely an attacker would know which user registered when. Unless you publish the registration date as some forums do... EDIT2: While user is known for each user, it does add extra required input for a rainbow table - if there are 1000 users and you know all of their usernames, you would still need to generate 1000x more rainbow tables (1 per known username) if you wanted to crack all 1000 passwords. Also slows down brute forcing, as you can't use the result of one 'trial' on all users at once. (Correct?) The real main issue is the speed of brute forcing MD5/SHA1 - it's probably possible to brute force these passwords very quickly if the database is stolen. Use of bcrypt is therefore obviously preferred to slow it down - but it is also very likely that FPGAs can brute force bcrypt just as fast, so I'm not sure how much I agree with the common mantra of 'sha1 is useless, use bcrypt'. bcrypt does, after all, have a speed impact on your login requests and puts more load on your servers if you are handling thousands of logins per second... I guess large scale FPGAs are probably only in use by NSA and some syndicates, while far more hackers have access to mass GPUs?
bascule 14y ago
As something of an amateur cryptographer, that is DailyWTF-level idiocy to me. One of the fundamental tenants of cryptography is Kerckhoffs's principle, that we should be able to publish the designs of cryptosystems for public scrutiny and they should hold up to that scrutiny (otherwise known as "security by obscurity is bad") It seems like we have a few problems with Dave as well: NIH combined with a lack of understanding about security. These together are a great way to produce insecure systems. I don't know how you fix people like Dave and would personally find them frustrating, and perhaps that frustration is leaking out in the post. It's clear the OP had something of a clue and thought bcrypt would be a good approach. You can call it public ridicule if you want to, but let's give him the benefit of the doubt: perhaps he simply didn't know enough about cryptography (which is very, very hard) and wanted to get a second opinion. Personally I wouldn't fault anyone for asking advice from a public forum about some homebrew crypto code like this. It's certainly better than a lousy password hash like that going into production in place of bcrypt.
- Dylan16807 14y ago
  Dave's claims and refusal to change are bad, but that has nothing to do with the code itself. The code is obfuscated sha1-with-lousy-salt. That is nowhere near DailyWTF. It's still relatively secure.
  - bascule 14y ago
    Relatively compared to what? MD5 and SHA1 can be computed very very quickly and can easily be brute forced on GPU clusters. Compared to PBKDF2, bcrypt, and scrypt, this system is incredibly insecure and susceptible to brute force attacks. My opinion of this code is it's full of nonsensical voodoo and this guy has no business writing cryptographic code of any kind.
    - Dylan16807 14y ago
      You realize how many places use a fast hash for passwords, right? It is nowhere near DailyWTF levels.

by gizmo 14y ago

Lagged2Death 14y ago

To me it's pretty clear the OP is trying to passive-aggressively bully/ridicule/shame Dave... I had a different interpretation; OP is "Dave." It's sort of a time-honored tradition, on-line and off, to seek advice "for my friend."

gizmo 14y ago
Nearly impossible. Every single sentence in the post provides evidence against that theory. (Dave "Insists on using a home-brew script" / use of "Homebrew" vs "Standard solution" / Dave's "primary hang-up" became clear after he "immediately balked" / Ridicule of Dave's code is "sincerely appreciated", etc). It's so over the top that the entire post may just be an elaborate troll.
- Lagged2Death 14y ago
  Nearly impossible. Every single sentence in the post provides evidence against that theory. On the internet, nobody knows you're a Dave.

Xylakant 14y ago

sha1 has the same features that make md5 a bad password hash: It's very memory and computation-efficient. It's relatively easy to implement in hardware. That makes it susceptible to brute-force attacks since you can test far more passwords than with any other algorithm. That doesn't mean that sha1 is a bad hash, it's just for a different use-case. You can stretch sha1 and make it more cpu-intensive by hashing multiple rounds - then you've invented pbkdf2.

xer0x 14y ago

Totally agree. The tone of this question and its answers really bothered me.

thaumaturgy 14y ago

That's not a salt, it's just broken. A salt can (and should) change from user to user, but not from minute to minute for the same user. That's why salted hashes have the salt stored as a substring of the hashed result: so that you can recalculate the hash using the same salt that was used the first time. The mistake in the code here is that the "salt" is being hashed along with the password. Oops. Just to be sure, I ran the code twice, a few seconds apart, using "rob" and "password" for the parameters. Here's the results: Hc3fba318ec5f25ef74e0067e27bfa187f1385d3b He66effce74bb1ae41e3a2344b91d5fe1c6205ee0 It doesn't work.

gizmo 14y ago
Presumably the salt is stored separately in the database.
- thaumaturgy 14y ago
  That would be fair, but I didn't assume so since that wasn't mentioned in the original post.
  - RyanZAG 14y ago
    He does seem to imply that Dave's solution works, and if you read the last line: $hash = hash_it($password, $crypt); So it is fairly clear that $hash and $crypt would be stored in the DB. $crypt is a reasonable (but not great) salt: crypt($user.$time.$rand); $user is obviously known, $time is the time when the password was created - or maximum ~2000 possible values for most systems. The main part of the hash is $rand, which is 31 bits of pseudo-random entropy. So about 40 bits of entropy if I'm not mistaken? That should be enough to make it infeasible to create rainbow tables in advance. EDIT: I'm wrong on $time - it is "mdYHis", so much more than 2000 possible values and is actually pretty decent in the salt, as it's unlikely an attacker would know which user registered when. Unless you publish the registration date as some forums do... EDIT2: While user is known for each user, it does add extra required input for a rainbow table - if there are 1000 users and you know all of their usernames, you would still need to generate 1000x more rainbow tables (1 per known username) if you wanted to crack all 1000 passwords. Also slows down brute forcing, as you can't use the result of one 'trial' on all users at once. (Correct?) The real main issue is the speed of brute forcing MD5/SHA1 - it's probably possible to brute force these passwords very quickly if the database is stolen. Use of bcrypt is therefore obviously preferred to slow it down - but it is also very likely that FPGAs can brute force bcrypt just as fast, so I'm not sure how much I agree with the common mantra of 'sha1 is useless, use bcrypt'. bcrypt does, after all, have a speed impact on your login requests and puts more load on your servers if you are handling thousands of logins per second... I guess large scale FPGAs are probably only in use by NSA and some syndicates, while far more hackers have access to mass GPUs?

bascule 14y ago

As something of an amateur cryptographer, that is DailyWTF-level idiocy to me. One of the fundamental tenants of cryptography is Kerckhoffs's principle, that we should be able to publish the designs of cryptosystems for public scrutiny and they should hold up to that scrutiny (otherwise known as "security by obscurity is bad") It seems like we have a few problems with Dave as well: NIH combined with a lack of understanding about security. These together are a great way to produce insecure systems. I don't know how you fix people like Dave and would personally find them frustrating, and perhaps that frustration is leaking out in the post. It's clear the OP had something of a clue and thought bcrypt would be a good approach. You can call it public ridicule if you want to, but let's give him the benefit of the doubt: perhaps he simply didn't know enough about cryptography (which is very, very hard) and wanted to get a second opinion. Personally I wouldn't fault anyone for asking advice from a public forum about some homebrew crypto code like this. It's certainly better than a lousy password hash like that going into production in place of bcrypt.

Dylan16807 14y ago
Dave's claims and refusal to change are bad, but that has nothing to do with the code itself. The code is obfuscated sha1-with-lousy-salt. That is nowhere near DailyWTF. It's still relatively secure.
- bascule 14y ago
  Relatively compared to what? MD5 and SHA1 can be computed very very quickly and can easily be brute forced on GPU clusters. Compared to PBKDF2, bcrypt, and scrypt, this system is incredibly insecure and susceptible to brute force attacks. My opinion of this code is it's full of nonsensical voodoo and this guy has no business writing cryptographic code of any kind.
  - Dylan16807 14y ago
    You realize how many places use a fast hash for passwords, right? It is nowhere near DailyWTF levels.