6 ms·

Please notice that there is _no_ advantage in everybody in the world using the exact same algorithm, quite the contrary in fact. If your password database is l

Please notice that there is _no_ advantage in everybody in the world using the exact same algorithm, quite the contrary in fact. If your password database is leaked, there are 2 categories of attacks that you need to be concerned with: 1. Brute force 2. A weakness in your implementation He's right that brute force attacks will require potentially more work if you have a custom scheme as the attacker will have to work out the details of the scheme before using brute force (category 1). However, many cryptographic compromises are actually due to bugs or weaknesses in the implementation (category 2); i.e. on paper your custom combination of schemes is fine, but you made a bug in implementing it or forgot to handle some case correctly. How can you have confidence that your scheme is safe from category 2 attacks? Use a scheme that has already been widely reviewed and attacked. If no one has been able to find a vulnerability in it thus far, there's a good chance that your attacker won't either. So there _is_ an advantage to using the same scheme that many others use. Use something hard, like scrypt, bcrypt, or PBKDF2, but also find an implementation of it that is likely to have been well used, reviewed, and hopefully attacked.

ovi256 14y ago
I think what he's suggesting is composing secure hash functions with some simple customisable steps, like xor, negation, so that the final result is as secure as scrypt, bcrypt, what have you, but also customized, so that standard tools won't work, and the attacker would have to do some custom legwork to attack your application. This, done correctly, would increase the cost of attacking to the point of making drive-by, mass-trolling attacks uneconomical, as they're based on pointing an exploit tool at a list of adresses. It will not deter targeted attacks (spearfishing) by competent attackers, but again, not much would.
- IsTom 14y ago
  Such combinations could end up worse sometimes, just like 2DES has the same strength as DES.
- chc 14y ago
  The idea that my customizations would make it appreciably more secure (especially vs. just slightly increasing the work factor) seems questionable to me. On the other hand, it's very plausible that my customizations could accidentally make it less secure. Way smarter folks than me have messed up algorithms they actually put a lot of thought into — I'm not going to go blithely turning knobs in good algorithms and hope their positions weren't important. Incidentally, what kind of drive-by attack are you thinking? Like, you have your password database sitting out in the open and there are bots crawling the web trying mechanically to crack it? Because that doesn't sound like a common case, but I'm not sure what else you could mean.
  - deleted 14y ago
    [deleted]
  - aethr 14y ago
    [deleted] This comment was factually incorrect and only served to cloud the issue. The link given in one of the responses provides more than enough information for a developer to understand the options available for password storage. Apologies for the noise.
    - dchest 14y ago
      You don't know what you're talking about.
      - shard 14y ago
        Please elaborate for those of us who are not experts on cryptography.
        jlgreco 14y ago
        For one, salts prevent using rainbow tables. A random combination of hashes with tweakable knobs, or whatever his suggestion is, is just a complicated way of salting except you have the possibility of weakening your function if you don't know what you are doing (as another has already mentioned, the unexpected behaviour of combining DES should be remembered).
mackcam 14y ago
You must take the next paragraph into consideration: All major internet sites, anybody with more than 50.000 passwords, should design or configure a unique algorithm (consisting of course of standard one-way hash functions like SHA2 etc) So he is in fact telling you to use a standard one-way hash function along with whatever custom implementation.
- dchest 14y ago
  By combining two or more standard functions you're creating a different cryptographic primitive, which must be evaluated accordingly. For example (while collision resistance is not that important for password hashing), by chaining MD5(SHA1(x)) you've created a better chance of collision than if you just used SHA1(x). If you use 10 hash functions in any possible combination, you must evaluate the security of every possible combination, or prove that your resulting function is secure with any combination of these 10 functions. And for what? For only a slightly larger, constant, cost of attack, which you can easily get by adjusting a parameter in scrypt.
  - EthanHeilman 14y ago
    Not if you use a permutation like a block cipher with a fixed key, rather than an arbitrary function.
    - dchest 14y ago
      Not what? That you've suggested a completely different scheme (single algorithm with a key) to the one described in the comment I replied to (combining multiple algorithms)? :) (Note that even using a standard block cipher requires a separate evaluation for different purposes -- you can't claim that your hash function/MAC/mode of operation is as secure as AES only because it's based on AES.) If you read my replies in this thread, I emphasize the point that if you really need a custom function with secret parameters, use a single algorithm with a secret key (I even gave a link to one such scheme with HMAC.)
      - 14y ago
jnorthrop 14y ago
That reminds me of the sage advice Bruce Schneier wrote in Secret and Lies, "Anyone who creates his or her own cryptographic primitive is either a genius or a fool. Given the genius/fool ratio for our species, the odds aren't very good."
- marshray 14y ago
  He's saying to build a custom function out of well established cryptographic primitives. I don't think that's a good idea either. There's still a ton that can go wrong that won't be apparent at all to someone who knows how to analyze entropy flows through the internals of hash functions. There's a reason why we have a PBKDF2 that's favored over the original PBKDF.
drzaiusapelord 14y ago
Excellent points. From a practical perspective not every website is going to get into the game of cryptography but its trivial to get into the game of salting. The fact that places like linkedin don't salt doesn't mean our algorithms are bad, it means the kinds of people who built the system there are bad.

ovi256 14y ago

I think what he's suggesting is composing secure hash functions with some simple customisable steps, like xor, negation, so that the final result is as secure as scrypt, bcrypt, what have you, but also customized, so that standard tools won't work, and the attacker would have to do some custom legwork to attack your application. This, done correctly, would increase the cost of attacking to the point of making drive-by, mass-trolling attacks uneconomical, as they're based on pointing an exploit tool at a list of adresses. It will not deter targeted attacks (spearfishing) by competent attackers, but again, not much would.

IsTom 14y ago
Such combinations could end up worse sometimes, just like 2DES has the same strength as DES.
chc 14y ago
The idea that my customizations would make it appreciably more secure (especially vs. just slightly increasing the work factor) seems questionable to me. On the other hand, it's very plausible that my customizations could accidentally make it less secure. Way smarter folks than me have messed up algorithms they actually put a lot of thought into — I'm not going to go blithely turning knobs in good algorithms and hope their positions weren't important. Incidentally, what kind of drive-by attack are you thinking? Like, you have your password database sitting out in the open and there are bots crawling the web trying mechanically to crack it? Because that doesn't sound like a common case, but I'm not sure what else you could mean.
- deleted 14y ago
  [deleted]
- aethr 14y ago
  [deleted] This comment was factually incorrect and only served to cloud the issue. The link given in one of the responses provides more than enough information for a developer to understand the options available for password storage. Apologies for the noise.
  - dchest 14y ago
    You don't know what you're talking about.
    - shard 14y ago
      Please elaborate for those of us who are not experts on cryptography.
      - jlgreco 14y ago
        For one, salts prevent using rainbow tables. A random combination of hashes with tweakable knobs, or whatever his suggestion is, is just a complicated way of salting except you have the possibility of weakening your function if you don't know what you are doing (as another has already mentioned, the unexpected behaviour of combining DES should be remembered).

mackcam 14y ago

You must take the next paragraph into consideration: All major internet sites, anybody with more than 50.000 passwords, should design or configure a unique algorithm (consisting of course of standard one-way hash functions like SHA2 etc) So he is in fact telling you to use a standard one-way hash function along with whatever custom implementation.

dchest 14y ago
By combining two or more standard functions you're creating a different cryptographic primitive, which must be evaluated accordingly. For example (while collision resistance is not that important for password hashing), by chaining MD5(SHA1(x)) you've created a better chance of collision than if you just used SHA1(x). If you use 10 hash functions in any possible combination, you must evaluate the security of every possible combination, or prove that your resulting function is secure with any combination of these 10 functions. And for what? For only a slightly larger, constant, cost of attack, which you can easily get by adjusting a parameter in scrypt.
- EthanHeilman 14y ago
  Not if you use a permutation like a block cipher with a fixed key, rather than an arbitrary function.
  - dchest 14y ago
    Not what? That you've suggested a completely different scheme (single algorithm with a key) to the one described in the comment I replied to (combining multiple algorithms)? :) (Note that even using a standard block cipher requires a separate evaluation for different purposes -- you can't claim that your hash function/MAC/mode of operation is as secure as AES only because it's based on AES.) If you read my replies in this thread, I emphasize the point that if you really need a custom function with secret parameters, use a single algorithm with a secret key (I even gave a link to one such scheme with HMAC.)
    - 14y ago

jnorthrop 14y ago

That reminds me of the sage advice Bruce Schneier wrote in Secret and Lies, "Anyone who creates his or her own cryptographic primitive is either a genius or a fool. Given the genius/fool ratio for our species, the odds aren't very good."

marshray 14y ago
He's saying to build a custom function out of well established cryptographic primitives. I don't think that's a good idea either. There's still a ton that can go wrong that won't be apparent at all to someone who knows how to analyze entropy flows through the internals of hash functions. There's a reason why we have a PBKDF2 that's favored over the original PBKDF.

drzaiusapelord 14y ago

Excellent points. From a practical perspective not every website is going to get into the game of cryptography but its trivial to get into the game of salting. The fact that places like linkedin don't salt doesn't mean our algorithms are bad, it means the kinds of people who built the system there are bad.