4 ms·

These days, what is wrong with rolling your own encryption of passwords using key strengthening and salting? Like this: hash = sha1 applied recursively 4071 t

These days, what is wrong with rolling your own encryption of passwords using key strengthening and salting? Like this: hash = sha1 applied recursively 4071 times ( password . salt ) . salt Serious question. Don't just say religiously, "just use bcrypt". Tell me what is really wrong. What attacks will succeed today? Any crypto enthusiasts in the audience?

mkozlows 11y ago
The non-expert answer is: Because crypto math is difficult for randos to analyze, and it's not obviously the case that running an algorithm 4,000 times is 4,000 times harder to break than running it once. And from a purely pragmatic perspective, why even consider it? You have a bcrypt/scrypt library, writing your own code is harder and almost certainly worse, so there is literally no reason to spend even a second thinking about it.
- zkhalique 11y ago
  Yes, there are reasons to think about it. For example if I want to understand the principles that make the usual algorithm strong. There is a reason why Apple makes every app implement its own receipt validation scheme. So a dedicated attacker can't crack all apps at once. Same here.
simcop2387 11y ago
So you essentially then end up with PBKDF2, as long as you're using an HMAC configuration with your hashing function you should be ok. That said, just go ahead and use a PBKDF2 library so that you match what others do and you have an easier time with interoperability if you have to use a different language or environment somewhere else with the same set of users. The reason you want to use HMAC is the same as always, it provides better security against a number of attacks that could recover the secret, https://en.wikipedia.org/wiki/Hash-based_message_authentication_code#Security https://en.wikipedia.org/wiki/Hash-based_message_authenticat...
deleted 11y ago
[deleted]
timmclean 11y ago
Modern password hashes are designed to use a large amount of RAM in addition to CPU time in order to make password cracking using ASICs and GPUs more difficult. The paper on Argon2[1], the winner of the recent password hashing competition, would be a good read if you're interested in learning more about how password hashes are designed. [1] https://www.cryptolux.org/images/0/0d/Argon2.pdf https://www.cryptolux.org/images/0/0d/Argon2.pdf
IgorPartola 11y ago
What others said, but also for very practical reasons. Why roll your own at all since this is an area where lots of FOSS code is already available? I see two broad categories here: your environment already has an scrypt/bcrypt/PBKDF2, so just use that, as you would a regular expressions library or a URL parser; or your environment does not, in which case you should grab the spec for scrypt/bcrypt/PBKDF2 (whichever you think is easiest to implement) and implement it. Inventing your own risks errors, while creating a system that's incompatible with what other systems are doing and does not follow any type of researched security protocol.
peterwwillis 11y ago
Besides getting the scheme right, the biggest problem is the implementation. There are lots of little things to consider; I can't list them because honestly i've only briefly studied the many gotcha's of previous holes in other implementations. Can you build your own suspension bridge? Sure. Would I drive over it? Nope. That being said, if you wanted to build your own _for fun_, do it! You will learn a lot in the process. Just don't expect your project to be over any time soon.
xrstf 11y ago
Just out of principle. You are mis-using crypto primitives, which can lead to bugs so subtle you would never guess they're there. And thanks to the random looking hashes, you will never immediately see that i492tr7gf89que092378gt827 is actually a broken hash and not a strong one.
stordoff 11y ago
In practice, rolling your own strengthened/salted hash is probably fine if you use a decent hash function, but why bother? The code already exists to do it for you, and using a standard function allows for better interop and portability. It will also (likely) have been designed and/or checked by people with domain knowledge, and so is more likely to avoid subtle attacks - just repeating a hash function n times might not offer the security you expect (e.g. 2DES is barely any stronger than a single DES pass - you need 3DES to make much of a difference).

mkozlows 11y ago

The non-expert answer is: Because crypto math is difficult for randos to analyze, and it's not obviously the case that running an algorithm 4,000 times is 4,000 times harder to break than running it once. And from a purely pragmatic perspective, why even consider it? You have a bcrypt/scrypt library, writing your own code is harder and almost certainly worse, so there is literally no reason to spend even a second thinking about it.

zkhalique 11y ago
Yes, there are reasons to think about it. For example if I want to understand the principles that make the usual algorithm strong. There is a reason why Apple makes every app implement its own receipt validation scheme. So a dedicated attacker can't crack all apps at once. Same here.

simcop2387 11y ago

So you essentially then end up with PBKDF2, as long as you're using an HMAC configuration with your hashing function you should be ok. That said, just go ahead and use a PBKDF2 library so that you match what others do and you have an easier time with interoperability if you have to use a different language or environment somewhere else with the same set of users. The reason you want to use HMAC is the same as always, it provides better security against a number of attacks that could recover the secret, https://en.wikipedia.org/wiki/Hash-based_message_authentication_code#Security https://en.wikipedia.org/wiki/Hash-based_message_authenticat...

deleted 11y ago

[deleted]

timmclean 11y ago

Modern password hashes are designed to use a large amount of RAM in addition to CPU time in order to make password cracking using ASICs and GPUs more difficult. The paper on Argon2[1], the winner of the recent password hashing competition, would be a good read if you're interested in learning more about how password hashes are designed. [1] https://www.cryptolux.org/images/0/0d/Argon2.pdf https://www.cryptolux.org/images/0/0d/Argon2.pdf

IgorPartola 11y ago

What others said, but also for very practical reasons. Why roll your own at all since this is an area where lots of FOSS code is already available? I see two broad categories here: your environment already has an scrypt/bcrypt/PBKDF2, so just use that, as you would a regular expressions library or a URL parser; or your environment does not, in which case you should grab the spec for scrypt/bcrypt/PBKDF2 (whichever you think is easiest to implement) and implement it. Inventing your own risks errors, while creating a system that's incompatible with what other systems are doing and does not follow any type of researched security protocol.

peterwwillis 11y ago

Besides getting the scheme right, the biggest problem is the implementation. There are lots of little things to consider; I can't list them because honestly i've only briefly studied the many gotcha's of previous holes in other implementations. Can you build your own suspension bridge? Sure. Would I drive over it? Nope. That being said, if you wanted to build your own _for fun_, do it! You will learn a lot in the process. Just don't expect your project to be over any time soon.

xrstf 11y ago

Just out of principle. You are mis-using crypto primitives, which can lead to bugs so subtle you would never guess they're there. And thanks to the random looking hashes, you will never immediately see that i492tr7gf89que092378gt827 is actually a broken hash and not a strong one.

stordoff 11y ago

In practice, rolling your own strengthened/salted hash is probably fine if you use a decent hash function, but why bother? The code already exists to do it for you, and using a standard function allows for better interop and portability. It will also (likely) have been designed and/or checked by people with domain knowledge, and so is more likely to avoid subtle attacks - just repeating a hash function n times might not offer the security you expect (e.g. 2DES is barely any stronger than a single DES pass - you need 3DES to make much of a difference).