6

Since hashing password has become a hot topic recently, it is only natural to expect things to change and assume that some time down the road you might want to replace/tweak the algorithm used in your system. That would naturally result in different types of hashes stored for old and new users.

I wonder would it be acceptable if I just stored the algorithm used in the database prepended to each hash? Something similar to how the output of bcrypt looks: $2a$... (the algorithm version). What if I stored it by name like sha1$f6238eb6ca...?

Does it make things considerably worse to explicitly expose the algorithm used? I'm thinking, even if the attacker knows the exact algorithm (of a very few) it is more or less the same order of work to crack it, x1 or x5 is not a big deal, the same O(effort). But it makes things simpler for me to manage.

What do you experts think?

Update. I was thinking about another option such as referring to a particular algorithm by codes such as alg1, alg2 and writing down the explanations of those references somewhere else, in the application, perhaps, to keep this information at hand. If my original idea should turn out bad, would this approach correct it?

Improve this question

5 Answers 5

Reset to default
13

Sure it's ok. This is a simple application of Kerckhoffs's principle: the secrecy is not in the algorithm, but in the key or password. For starters, anyone who has access to your implementation, or to its documentation, or who knows what is supported by the libraries your application is built with, knows what algorithm(s) your application may be using. At most, the attacker would have to try a small list. And if there are several possibilities, your application would also have to try that list, making authentication slower for no good reason (you increase your own workload by the same amount as the attacker's).

As you've noticed, it's common practice to prepend the identification of the algorithm to the salt and hash. Granted, common practice isn't always sensible, but here it is. Bcrypt uses numerical codes inherited from Unix practice. You can use your own naming scheme if you prefer, though as usual you should stick to what your library provides unless you have a very good reason to do your own thing.

Improve this answer
2
  • Thank you for you reply. I remembered that principle when I was considering the idea. Glad my thoughts were confirmed. Sorry I can't upvote I'm unregistered here.
    – anon_user
    Jan 21, 2013 at 1:36
  • 1
    WHy not register here- it's free and only takes a second.
    – Rory Alsop ♦
    Jan 21, 2013 at 7:35
2

It doesn't make things worse doing this, and in fact many hashing storage solutions do exactly this (similar to your bcrypt output example) so that the OS (or application) knows what hashing algorithm to use to compare to the stored hash.

The security is not reliant on keeping the algorithm secret in any way - it relies on the algorithm being robust enough that the chances of two passwords delivering the same hash under normal circumstances is incredibly low, and the effort required to brute force compare generated hashes is as high as possible.

Improve this answer
1
  • Thanks you for your answer. Didn't know other people have been doing this. I guess it must be okay then. Sorry I can't upvote I'm not registered here.
    – anon_user
    Jan 21, 2013 at 1:38
0

Typically the length of the hash output alone is enough to give up that secret:

MD5: 128 bit
SHA1: 160 bit
SHA256: 256-bit
SHA512: 512-bit

Trying to keep your algorithm secret is a losing battle. You want security through secrecy, not security through obscurity.

Improve this answer
4
  • I thought of that. But if you use PBKDF2 or scrypt the output length is whatever you ask for. One could even choose a size from your list to add confusion as to which of the algorithms has produced the hash.
    – anon_user
    Jan 21, 2013 at 1:48
  • @anon_user In which case you'll have someone fooled for about 90 seconds until they dig through the code to find out what your key deriviation parameters are. The real value in saying $2$ instead of $sha1$ is space.
    – tylerl
    Jan 21, 2013 at 2:20
  • 1
    That is funny but could backfire... ops, I misread your response. I thought you were suggesting putting there a wrong algorithm purposefully. :)
    – anon_user
    Jan 21, 2013 at 2:46
  • I think one would need something beyond length if one wanted to allow the security of existing passwords to be upgraded immediately. For example, if a database which had contained a mixture of MD5 and SHA1 wanted to upgrade to a better algorithm, one could hash the existing hashed password, but would need to know not just the hash method used for the final hash, but also the one used for the earlier one.
    – supercat
    Sep 28, 2014 at 17:02
0

As others have already explained, trying to keep the algorithm secret is not a good idea. However, if you want additional protection from attacks that compromise the database but not the executable code, you can store a secret "pepper" value and/or algorithm in the code, so that the attacker will have to figure out what exactly do you do with the data before you hash it. Trying to keep the algorighm secret in this case still provides little security (as it's not that hard to figure out), but keeping the key secret will complicate any attack considerably.

See How to securely hash passwords? for more info on the topic.

Improve this answer
0
0

First of all on of the requirement for modern encrypting standards was that the having known an algorithm by attackers doesn't decrease a protection of the system if all rules, in particular, for keys, are done.

Think about that many of algorithms are open source, in fact, any in Linux. So the basic concept of security here is the strength of keys used.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .