1

I read that LastPass uses PBKDF2-SHA256 for storing the Master Password hash, I wonder how this compares to BCrypt and why did they chose this, as SHA256 is a quick hash (probably compensated by PKDF2?).

mFeinstein
  • 251
  • 4
  • 13
  • This is pretty much an open debate. Everybody has their own horse in the race. Some people recommend Argon2 because it won the PHC. Some people recommend scrypt because it's been around for long. Others love PBKDF2 because it is recommended by NIST and has FIPS implementations. My personal opinion is that with decently chosen parameters, I've never seen such a hash being cracked. –  Apr 03 '20 at 06:20
  • From what I saw they do 100100 iterations. So while SHA-256 may be fast, that many iterations it's certainly not as fast. – Swashbuckler Apr 03 '20 at 14:14
  • Actually, both are bad since they don't have memory expansion like Scrypt and Argon2. – kelalaka Apr 03 '20 at 18:52
  • This discussion also seems relevant: https://security.stackexchange.com/questions/4781/do-any-security-experts-recommend-bcrypt-for-password-storage/6415#6415 – Luke Quinane Jul 21 '21 at 03:03

1 Answers1

6

I can tell you why we, 1Password, use PBKDF2 instead of a more modern successor. Quoting from the 1Password Security Design document,

The choice of PBKDF2-HMAC-SHA256 as our slow hash is largely a function of there being (reasonably) efficient implementations available for all of our clients. While we could have used a more modern password hashing scheme, any advantage of doing so would have been lost by how slowly it would run within JavaScript in most web browsers.

Because all of our key derivation is performed by the client (so that the server never needs to see the password) we are constrained in our choices by our least efficient client. The Makwa password hashing scheme\autocite{pornin:MAKWA}, however, is a possible road forward because it allows some of the computation to be passed to a server without revealing any secrets to that server.

Basically, we needed a slow KDF that would run efficiently in all clients, including our web client. And PBKDF2-H256 is the best that web crypto could offer.

I can't speak for LastPass, but I would suspect that their reasons are similar.

Slow hashing offers diminishing returns

While it would be nicer to move to a more modern slow hash, it is important to keep in mind that there are limits on what these can buy us. For example, if you have 100,000 rounds of PBKDF2, then to get the same strength increase to adding a randomly chosen digit to the end of your master password, you'd need to move to 1 million rounds. Maybe you are willing to wait a couple of seconds when unlocking your password manager, but you are also going to be sucking power from your battery on mobile devices.

So it is important to have a slow KDF, but we also reach a point where the effort should go into encouraging stronger master passwords. I wrote about this in Bcrypt is great but ...

I don't want to turn this into a sales pitch, but I should point out that as we've always understood the limits of slow hashing, we designed 1Password so that the data we hold on our servers is not vulnerable to such cracking. Our use of PBKDF2 (and the strength of your master password) is defends you if your encrypted 1Password data is stolen from your machines.

The mysterious future

I can't make any promises, but we are actively looking at WASM to get around these sorts of constraints. It turns out that there are challenges to safely integrating WebAssembly into web-apps and we haven't even begun any sort of performance testing.

Jeffrey Goldberg
  • 6,420
  • 17
  • 21