3
$\begingroup$

I was thinking of a potential new way to increase someone's account security.

The idea was allowing the user to choose one of the hash formulas available in the software (example: "MD5", "SHA512" and "Whirlpool"), decreasing the chances of any intruder to find out the hashing system used in case passwords are — for some reason — leaked increasing a potential required time of brute-force or dictionary attacks.

Would that be a good idea?

Improve this question
$\endgroup$
  • 1
    $\begingroup$ Just choose one secure scheme, such as scrypt with good parameters. $\endgroup$ – CodesInChaos Aug 7 '13 at 13:22
  • 1
    $\begingroup$ If you use a secure slow-hash like bcrypt, scrypt, or PBKDF2, it won't matter if an attacker knows what the scheme is. MD5, SHA512, and Whirlpool are terrible password hashes. Stop trying to be clever and use existing, best-practice password hashing schemes instead of rolling your own. $\endgroup$ – Stephen Touset Aug 7 '13 at 17:03
  • $\begingroup$ TrueCrypt is funny that way. It allows the user to pick from Whirlpool, SHA-2 and RIPEMD160, but uses far too few iterations of PBKDF2. A decent iteration count (or even scrypt) would have gained far more than the choice of hash function. $\endgroup$ – CodesInChaos Aug 7 '13 at 19:25
3
$\begingroup$

This doesn't sound like a good idea. As CodeInChaos already pointed out, choose one good password hashing scheme like scrypt or bcrypt and go with that

The reason why what you proposed isn't so great is that you'll give the user the choice between a few good password hashing options and the work of an attacker is at best multiplied by the number of options you proposed.

By doing that it's also unlikely that a bad password hashing will make its way into the list and the users picking that one will be at the attacker's mercy. Lastly I don't think it's a good design to leave security relevant choices up to the user.

How should an average user know better than the designer of the system what's good for him ?

Improve this answer
$\endgroup$
  • $\begingroup$ Maybe allowing only advanced users to do it? $\endgroup$ – GiamPy Aug 7 '13 at 13:52
  • $\begingroup$ In addition this leaves open the possibility of social engineering where someone goes around saying "hey, use "MD5/nosalt" on [the website]", it's much better than the alternatives, decreasing overall security (because most users are gullible). $\endgroup$ – Thomas Aug 7 '13 at 13:55
  • $\begingroup$ TrueCrypt allows the user to choose between SHA-512, Whirlpool, or RipeMD-160 as the underlying hash for PBKDF2. However, I believe the chosen algorithm is stored in the file header, so it would seem this option is just a user preference, as opposed to an increase of security through obscurity. $\endgroup$ – hunter Aug 7 '13 at 17:38
  • $\begingroup$ @hunter No, TrueCrypt needs to try them all since its files have no unencrypted header. IMO it's a good example of what not to do. They could have simply hardcoded PBKDF-2-HMAC-SHA-512 with 100'000 iterations and it would have been far stronger that what they have ATM. $\endgroup$ – CodesInChaos Aug 7 '13 at 19:28
  • $\begingroup$ @CodesInChaos - oh really?? That's a terrible design decision. For encryption, the user can also choose between AES, Serpent, Twofish, and any (cascading) combination of the three. Do you know whether Truecrypt uses the same 'trial and error' approach to decryption? Definitely agree with you about increasing the PBKDF2 rounds, I think it's currently fixed at 1000 (nowhere near enough)... it doesn't make much sense to let users choose a hash algo, but not the number of iterations. $\endgroup$ – hunter Aug 7 '13 at 19:52
2
$\begingroup$

To supplement the other answers:

...decreasing the chances of any intruder to find out the hashing system used...

If you don't pad your hashes to make them of equal length, the attacker can figure out which scheme is used. That would unnecessarily increase your complexity factor (and might even confuse your own code if not done right).

Furthermore, you are dividing your users in three categories:

  • The less technically-inclined

This class of users will get irritated, confused and potentially feel stupid. Interesting article on this but the point is, they might end up hating you. Or they might escalate to know-it-all's.

  • The know-it-all's

...who believe a simple hash function is all it takes to make a website hacker-proof. See the Dunning-Kruger effect and decide if that's your target audience.

  • Those who know what they're talking about

The people sites like this attract (except for me, I'm more of a know-it-all). They will avoid your website like the plague, and if they absolutely must register to see something, they'll use Bloody Vikings! and PASSword1 as their password, and never set foot in your website again. They might even send you a strongly-worded email about your policy (if you're lucky), or even use you as a counter-example in their next presentation.

Bonus: You are also violating Kerckhoffs's principle by relying on the inability of the attacker to guess the applicable scheme. You want to make his life difficult - that's why we use salts and good password policies for. Enforcing the latter will get you much better results.

That said, as Alexandre et al says, use scrypt or bcrypt instead. This and this question on Security.SE might help you decide on the work factor.

Improve this answer
$\endgroup$
0
$\begingroup$

If you have only "advanced" users they will choose the "better" function available. If you have some "no-advanced" users is, probably, better that you choose at their place.

So even giving a large choice, every one should stick to the better one.

So I'd choose just one strong and secure function and stick to it.

Other people already suggested you to use scrypt, and give a look also to bcrypt.

Improve this answer
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.