CODEWITHSUNDEEP
securityhashpassword-protection
sfinxen
sfinxen

Reputation: 13

Storing and using piece of a hash

I am building a secure loginmodule and I've been reading all these guides about salting the password before hashing etc.. However I felt that all the passwords are still "dehashable" with access to both the hash and the salt.

So I started thinking about what if I just store a piece of the hash in the database instead. In PHP when hashing with SHA-256 I get a 64character string, what if I just save like 50 of these in the database and do the same 50char comparison when logging in.

Bruteforcing would give some extra false-positives. But still they would have to try a lot and a lot of passwords and the real password is certainly not dehashable.

Am I missing something with my idea or could this actually work?

/ Andreas

Upvotes: 1

Views: 119

Answers (2)

bobince
bobince

Reputation: 536675

I felt that all the passwords are still "dehashable" with access to both the hash and the salt.

A hash cannot be reversed: that is the very purpose and nature of the hash.

The attack is that, knowing the hash due to some other information leak, you brute-force the problem by calculating hashes for all likely values for the input variable, and if you get a hit there is a very good chance that the value you guessed was the one that was originally used to create the hash.

Salt slows this attack down in that it has to be done separately for every password instead of pre-calculated over all at once, but modern hardware can calculate hashes so fast now that this doesn't have the deterrent value it once did.

You can certainly reduce the likelihood of that brute-force guess being right by reducing the amount of hash data you store: for example if you kept only 8 bits of hash then an attacker couldn't really guess the original password because one in every 256 passwords would match. But the necessary downside of that is that your own use of that hash for authentication is massively weakened, allowing 1 in every 256 random guesses to get in.

The benefit of making the stored hashes less uniquely guessable is directly proportional to the cost of making the main authentication interface more susceptible to chance. The case of an off-line guessable hash only occurs when there is a database breach, rather than being a constant threat like the guessable authentication interface, so we generally care about it less.

In your example, a 200-bit hash (50 hex digits) is still likely to give a unique value for all common password strings, so there is little real benefit.

Ultimately the problem of preventing off-line guesses against a leaked database is unsolvable, but the best approach we have at the moment is making the hash calculation slow for both the attacker and the real authentication server. See bcrypt and PBKDF2 for the common implementations. Even so, this can only slow down mass-guessing offline attacks for long enough to give you time to ask your users to change their passwords after having discovered a data breach.

Upvotes: 1

Jonathan Leffler
Jonathan Leffler

Reputation: 754820

No hash worth the name is reversible. Throwing away 14 characters from the output of a SHA-256 hash reduces it to SHA-228; this is probably not what you had in mind. If you use a big enough salt (64 bits or more) and it is properly random, you'll be safe enough, and safer if you store 64 characters than just 50 characters.

Upvotes: 2

Related Questions