0

I'm working on a site which is (try to be) super secure. I read a lot about password hashing and using salts, but not everything is clear to me. I would like to use sha-256 hash algorithm with salt. I know about salts that all of them should be unique per-user per-password.

I'm wondering what if I use the password as salt too? Hash the password with sha256 and then hash it with an other algorithm and use it as salt. In this way I don't have to store the salt in the database. Is this possible? or should I generate a random string?

halfer
  • 19,824
  • 17
  • 99
  • 186
Bakayaro
  • 120
  • 8
  • 1
    No, use `password_hash` - it is the standard way to hash and salt passwords with PHP. The idea with this is that the hashing algorithms are deliberately slow, and cannot be parallelised, whereas SHA-256 might be too fast. If your hashing algorithm is fast then hashed passwords could be derived just by brute-force searching. – halfer Apr 24 '14 at 10:47
  • possible duplicate of [Secure hash and salt for PHP passwords](http://stackoverflow.com/questions/401656/secure-hash-and-salt-for-php-passwords) – halfer Apr 24 '14 at 10:48
  • Its not the same question but has a good description, thanks. Maybe I wasn't so clear. I want to use my password as salt too in a hashed form. – Bakayaro Apr 24 '14 at 10:58
  • You can supply a salt to the algorithm I suggested. However it is not common to use the password itself as a salt - the salt is meant to be something per user (e.g. their username) that can be stored unencrypted and unhashed in the user table. It is designed to make it computationally expensive to crack passwords, since a rainbow table would have to be generated for every user. Bottom line: since I am not a cryptographer, I would just use the recommended approach. – halfer Apr 24 '14 at 11:10

1 Answers1

0

No, that is still a one-way algorithm.

If another user uses the same password the hash value will be the same as the hash of the pass of the first user. That misses the point that hash values must be different for each user and each pass entry.

I suggest to use the date of registration of a user (for example) as salt. This way for each user and each pass the hashing algorithm will be different (ok, if two users have the same pass AND the same reg. date it will be the same).

Or maybe you can use user id for salt, or some combination between user id and reg.date and user name.

Edit: Your approach is actualy better than hashing with known algorithm without salt, but worse than hash+propper salt.

What you do is just applying custom hash function of your own. That can't be easyly brute-forced without knowing the custom algorithm, but is vunerable to other attacks.

And I suggest not placing a table with name "SALT" in the db, for if DB is hacked the attacker wii get the passwords AND the salts for them.

user1328370
  • 401
  • 1
  • 3
  • 6
  • but the user names are public, isnt that a problem? or should I hash it too? – Bakayaro Apr 24 '14 at 11:07
  • Traditionally, salts have been stored in the user table unencrypted, as far as I know. They are there just to increase the complexity of attempting to reverse the hashing. [This WP article](https://en.wikipedia.org/wiki/Salt_%28cryptography%29#Benefits) refers to a "public salt", which I think means that it's okay for the salt to be readable from the table. – halfer Apr 24 '14 at 11:15
  • Probbaby not, depends of what you intend to do. If the unames are hashed you won't be able to tell a user what's his user name. For the most cases user names aren't private information and applications display them on the page, allow other users to view them and so on. There is an approach, however, to devide login name and user name - user logs with his login name (can use mail for that) and presents himself to others with different name. In this case login names can be private and can be hashed. – user1328370 Apr 24 '14 at 11:17
  • My advice is to use some combination of uId, uname, regdate and so on to construct a salt. It's important that the fields you use for salt don't change over time. This makes much types of attacks pointless, since if only the DB is hacked, the attacker cant get the passwords (he doesn't know which fields and in what combination are used as salt). If the attacker views only the algorithm for constructing the salt, but he can't view the DB - he can't have the passwords (which in inprobbable, 'cause if he gains access to the application in most cases he also gets access to DB, because of that). – user1328370 Apr 24 '14 at 11:28