# Secure password storing mechanism [closed]

I recently thought about a secure password storing mechanism.

I wanted to ask if the following password storing mechanism is resistant against rainbow tables with a secure password and the attacker knowing the hashing and salting mechanism.

## tl;dr:

Instead of using a randomly generated salt, the salt is derived from the password. Therefore the salt also isn't stored in the database.

1. User types in password ($password = "MySecurePassword123") 1. $password is being hashed with sha256 ($hashed_pw = ccf9ac1c9ce02b9bb7810a1fff51e474f37d98c3582f2d3b5036caf559afd9bc) 1. First 5 (let's say min. password length is 8) characters from $password are hashed using sha256. Let's call the resulting hash 'salt'. ($salt = 52824aa0d517c8d6e24d59e1374ee202e97ba730b00ae577c94cdf157cbc29af) 1. $salt is being appended to hashed_pw and hashed again with sha256 ($result = sha256($salt + $hashed_pw) = 63617328f94d025f2489f170388b42d954a73391250b0ad29bbfb7ce2f8373e1) Finally $result is being stored in the database.

Used tool for generation of sha256 hashes: https://emn178.github.io/online-tools/sha256.html

• This is way off topic. But it's not even resistant to basic lookup tables: a given input will always result in the same output. Not only will duplicate password have the same stored value, but building a lookup table is trivial (and cheap, it's just three sha256 operations). This is why random salts are used. Please stick to existing implementations. – Marc Jan 10 '18 at 10:03
• @Marc I was not going to actually implement it, just thought about it. I don't think it would be trivial to create a lookup table even if some passwords were relatively weak, since there is a different hash for every different password and the attacker doesn't knows the password. – bn4t Jan 10 '18 at 10:09
• Lookup tables are built by iterating through possible password and running each password through your algorithm and a mapping of output -> input. Since the output for a given password is always the same, I can easily use this kind of lookup table. And since the operations are pretty cheap, I can do it fairly quickly. – Marc Jan 10 '18 at 10:20
• @Marc Can you write this as an answer so I can accept it and close this question? – bn4t Jan 10 '18 at 14:50

This is a very insecure way of storing passwords.

There are two important factors at play here:

• the same password will always result in the same output allowing the use of simple lookup tables
• your entire algorithm is computationally cheap allowing the quick computation of the lookup tables or just brute force

This means that an attacker can compute a lookup table of output -> password fairly quickly and check the raw values in your database against the lookup table.

A rough approximation: I can download the 10 million password list and run each password through your algorithm. openssl speed sha256 reports that my laptop can do ~3M ops per second on 64 byte blocks (the size in your last step). Divide that by three (number of sha256 operations you are doing, although some are on smaller blocks so even faster) and I can build a 10M lookup table in seconds on average hardware.

If you use this method for a site with thousands of users, you will find a large number of users using passwords found in the database.

This approximate method can be implemented and run in minutes and will determine the passwords for a considerable fraction of your users (depends on how well-behaved they are, but even one is too many). Note how there is no mention of rainbow tables. These are not needed as a given password always results in the same stored value.