Home > OS >  Potential security issues with storing bcrypt hash in local storage?
Potential security issues with storing bcrypt hash in local storage?

Time:09-02

I'm building a website that uses a password to encrypt/decrypt text. I'm storing the bcrypt hash of the password in database and check whether the password is correct before decrypting.

I want the website to also work offline and the only way I can think of doing this is localStorage.

What are the security considerations that I should take before storing password hashes in local storage?

CodePudding user response:

An interesting question! Without knowing more about your threat model (what's the worst thing an attacker could do with the cracked password that they couldn't do because they now have access to the client endpoint?), I can answer generally.

While password hashes are designed to be resistant to offline / local attack, that's a last resort - they're really intended to be entirely out of reach of the attacker, so they can't be guessed repeatedly at the attacker's leisure with arbitrary local compute resources and with no throttling. (As the attacker, having a password hash to attack is exactly what I need to get started!)

But since you're specifically protecting what will effectively be a local decryption key, the hash might indeed need to be stored locally. If so, I would recommend making the bcrypt 'cost' (work factor) as high as the user can tolerate. (Since the work to validate the hash is distributed per client, you can afford to make that cost significantly higher than you might be able to absorb on the server, to mitigate thundering herds).

So if the user can tolerate having to wait for a couple of seconds, a bcrypt cost of 16 might be a reasonable client-side value (but you'll need to test this for your own use cases, and the value will also change over time). Make the number as high as your users can take.

  • Related