4

I have a scenario where I already have a table of resource passwords stored as unsalted 128-bit hashes. I'm unable to force owners to provide new passwords, so I'm trying to mitigate the situation by re-hashing all of the passwords with a salt.

Unfortunately, I can only pull the salt from existing data, and the only data I can guarantee will remain consistent is the object's (sequential) 32-bit integer ID.

Aside from adding an extra layer of obscurity, is there any benefit to extending the length of the salt by hashing the ID? Would just repeating the integer to obtain a 128-bit value have the same results? Or are both of these approaches pointless?

3
  • Do you mean new_hash = MD5(old_hash + salt) or new_hash = MD5(old_password + salt)? It probably isn't relevant to your question, but I just want to be sure about what re-hashing all of the passwords with a salt means.
    – Jedi
    Jun 24, 2016 at 1:24
  • 4
    If you change your hashing algorithm to scrypt or bcrypt, then a random salt will be automatically included as part of the hashing process. This salt is concatenated with the resulting hash so it will be stored in the password field along with the password. This solves your apparent issue of not being able to add a new salt column to your password table.
    – Numeron
    Jun 24, 2016 at 1:27
  • why can you only pull the salt from existing data? can't you randomly generate a new one? Jul 19, 2016 at 23:56

2 Answers 2

3

Actually most implementations of algorithms like BCrypt will generate a salt on their own, from the random source of the operating system. This is the best one can do and there is no need to derrive a salt from other parameters.

A salt should be globally unique for each password, so an attacker cannot find any precalculated rainbow-tables, and would have to build a separate rainbow-table for each password.

  1. Locally unique: If every password of your database gets a different salt, the attacker cannot reuse the rainbow-tables. Hashing the integer (user id) will not make any difference in this case.
  2. Globally unique: If you use worldwide unique salts, an attacker cannot find already precalculated rainbow-tables. Finding precalculated tables for user ids is slightly easier than finding them for the integers hashes, so hashing would indeed improve security a little bit.

Once again, you can get a salt without derriving it from other parameters, and you shold do it. Let the hash function do it, or get it from the random source of the operating system.

2
  • 1
    Note that you can turn a locally-unique salt into a globally-unique salt by concatenating a globally-unique constant value to them (a "pepper").
    – Philipp
    Jul 20, 2016 at 13:04
  • 1
    @Philipp - Actually a pepper serves its own purpose and should not be used to make a salt globally unique. A pepper must be kept secret and should not be stored together with the salt. Jul 20, 2016 at 13:19
1

To answer the question you specifically asked...No, hashing the Int32 value to use as the salt is not significantly stronger than using the Int32 directly. It would, as you already suspect, be more obscurity than security. As Martin pointed out in his answer, the key property of a salt is that it be globally unique. You do not get this property with either an int or the hash of an int, so you would be adding complexity to the solution, but not much security.

You must log in to answer this question.

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