Let's say I have a database with a bunch of users in it. This user database would typically have a hashed password per user. Would it be bad practice to prefix this hash with the hashing algorithm used?

For instance, instead of the hash aaf4c61ddcc5e8a2dabede0f3b482cd9aea9434d, I store sha1_aaf4c61ddcc5e8a2dabede0f3b482cd9aea9434d, since the method for making the hash is SHA1.

I noticed Argon2 does this, and I actually think it is quite convenient, because it makes it easier to partially migrate to newer hashing algorithms for newer users over time.

I don't use SHA1 in my production code for passwords. SHA1 was chosen randomly. This question is not about the use of the hashing method.

  • Comments are not for extended discussion; this conversation has been moved to chat.
    – Rory Alsop
    Nov 13, 2018 at 13:54

5 Answers 5


Many different password hashing systems do this. The type of hashing mechanism used should not be (and should not need to be) a secret. Kerckhoffs's principle says:

A cryptosystem should be secure even if everything about the system, except the key, is public knowledge.

So, if your system is properly secure, it should not matter if the hash mechanism is exposed.

  • 13
    Why “should not be”? Should not need to be secret is Kerckhoffs's principle, but as long as it doesn't cause you to compromise on the key safety it certainly can't cause harm either if the hash algorithm is secret too. Nov 8, 2018 at 16:13
  • 9
    @leftaroundabout that's about Kerckhoffs's. Operationally and policy-wise, to classify the hashing algorithm as a secret is a problem. It attempts to provide security by obscurity, and it introduces control costs that outweigh the benefits. Not to mention the practical use case provided by Toby Speight. It's not about prepending the alo type, it's about the classification of the data about the algo type.
    – schroeder
    Nov 8, 2018 at 16:35
  • 2
    Classifying it as a secret is not necessary for it being secret. It may be secret incidentally, for performance reasons. Nov 8, 2018 at 16:38
  • 19
    I was under the impression that adding "security by obscurity" is still a good thing. Systems should be secure, even if you know all of the details of the system, but adding obscurity adds security (to slow down attackers, to hide systems when 0-day bugs get found, etc). It this fair? Nov 8, 2018 at 17:15
  • 15
    @NathanMerrill I would say that it should be taken on a case-by-case basis. In this case, I think the benefit of having the algorithm stored with the hash significantly outweighs the very slight security benefit you'd get by obscuring it.
    – Jeremy
    Nov 8, 2018 at 19:04

I agree with schroeder that this is OK to do. Even without a prefix, an attacker can probably figure out what algorithm you are using. And anyway, it is the strength of the hashing algorithm that protects the passwords, not the secrecy of the algorithm.

Note that many hashing algorithms and libraries already do this for you. They embed all the relevant information - algorithm, cost factors, salt, the actual hash - into one serialized string. See for instance the Modular Crypt Format or the PHP password_hash function. So don't go making up your own scheme. If you are using a descent hashing library you already got one.

Don't use SHA1 to hash passwords, though. That is not OK.

  • 1
    Yeah I used SHA1 because I the hash of "hello" was too long for an example in SHA512. Nov 8, 2018 at 13:44
  • 20
    @MathiasLykkegaardLorenzen Don't use SHA512 either, unless it is just a component in a bigger scheme with more iterations. But off course for an example, anything goes! :-)
    – Anders
    Nov 8, 2018 at 14:05
  • 6
    @MathiasLykkegaardLorenzen And don't just use multiple iterations either! Use a proven construct like PBKDF2, which uses HMAC (not just raw hash iterations).
    – forest
    Nov 9, 2018 at 2:38
  • 15
    It's not insecure for what it was designed for (i.e. hashing data), but it was designed to be fast. You want your password hash function to be slow to stave off brute force attempts.
    – hlt
    Nov 9, 2018 at 8:29
  • 4
    Yes it still matters. Hashing functions are not meant for password storage due to their speed. With a single p3.16xlarge instance on Amazon, you can do 17.28 billion guesses per second on SHA512. That means that you can crack any 8 character password of letters and numbers in only 151.17 seconds. Key derivation functions are made for storing passwords as they are slow. With bcrypt on workfactor 12 you can only do 424200 guesses per second. That would take 34.8 days per password. Additionally bcrypt and argon2 has built in salts, so you don't have to worry about salting the passwords.
    – FrederikNS
    Nov 9, 2018 at 17:21

No, it's not bad practice, and arguably, you should keep this information.

As you observe, this allows you to change algorithm for new passwords whenever you like, without invalidating all users' existing passwords (doing that tends to make you unpopular, for some reason).

There's an argument that this allows an attacker to search out the older, weaker passwords to attack first, but you haven't reduced their security at all (assuming Kerckhoff's Principle, that the algorithm itself mustn't need to be a secret).

  • 2
    If one can store a combination of algorithms and salts, there's no need to keep weaker passwords once stronger algorithms are available. If the current entry says that putting the password through weakAlgorithm with salt1 yields X, simply compute Y by putting X through a strongerAlgorithm with salt2 then change the entry to say that putting the password through the weakAlgorithm with salt1, and then putting the result of that through a stronger algorithm with salt2, will yield Y. No need to wait for the user to log in.
    – supercat
    Nov 8, 2018 at 21:16

It's good practice to store the hashing algorithm, but proper password hashing functions such as Argon2 and PBKDF2 already take care of this. It is however bad practice to use SHA1 or SHA256 alone for password hashing because they're a fixed (and relatively small) amount of work to crack using dictionary attacks and brute force. Those passwords should be migrated to a secure hashing function by rehashing the password on their next login. See https://crypto.stackexchange.com/a/45405 for details.


It's not bad practice, it's actually a common thing to do. In fact if you open the /etc/shadow file on a linux machine you will see your hashed password prefixed with $x$salt$ where x is a number indicating which hashing algorithm was used.

Now a few things to consider:

  • do not use SHA1 directly as a hashing algorithm. Use bcrypt, scrypt, or argon2 instead (which you did mention but this can't be repeated too much). These do use simple hashing algorithm like SHA1 as a base, but they run it in a special way that makes it resistant to attacks.
  • for practical reasons, since you're using a database and not a file, you might want to store the hashing method and salt in separate rows. However you can also choose to store the string starting with $x$salt$ in your database, and parse the salt and hashing method from that string at the time you check the password. It's probably fast enough that it makes no significant difference. And in both cases the security of your system will be the same.
  • 1
    The OP says in comments that SHA-1 was only used as an example and is not used in production
    – schroeder
    Nov 9, 2018 at 19:35
  • One needs to use more than "run that several times", it needs to have a CPU utilization or ~100ms and a random salt.
    – zaph
    Nov 9, 2018 at 19:58
  • @schroeder I wasn't so sure by reading the question. Nov 11, 2018 at 16:15
  • @zaph absolutely agree, but I didn't want to get into specifics. Edited my answer to make it less ambiguous Nov 11, 2018 at 16:15

You must log in to answer this question.

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