PBKDF2 iteration count in the browser

jon_mackle

I've read that new accounts default to using 100,000 PBKDF2 iterations. However, I just tested signing in to my new account from Safari on my iPhone (which does not support WebCrypto), and the login took 0.1 seconds. I also tested on Firefox on iOS and the result was the same.

How can you possibly perform 100,000 iterations on a mobile browser that quickly? Even desktop browsers without WebCrypto can't handle more than 5,000 iterations.

rickfillion

Hi @jon_mackle,

You're right, without WebCrypto that wouldn't be possible. Safari on iOS does infact support a subset of WebCrypto... a large subset of it. It's available under window.crypto.webkitSubtle as opposed to the standard window.crypto.subtle. I don't think we're using a non-native PBKDF2 implementation anywhere. It would take too long to do the 100,000 iterations.

Cheers.

Rick

jon_mackle

So how do you handle browsers that don't support any subset of WebCrypto?

And secondly, do you authenticate the iteration count coming from the server? Meaning, if the server replaces 100,000 with 1, would the client obey this blindly and send my password hash after only 1 iteration?

roustem

If the browser does not support native PBKDF2 then we "polyfill" and perform this operation in JavaScript. It is slower and takes a couple of seconds. If you open the https://start.1password.com and inspect the console you will see the result of the crypto tests:

For example, Safari 11 supports supportsNativePBES2:

Crypto init and tests are complete
supportsRSA_OAEP_256: true
supportsNativeAES_GCM: true
supportsNativePBES2: true
supportsNativeECDSA: true
importRequiresArrayBuffer: false

Re: iteration count coming from the server. I don't think there is anything in the web client (after all the web client code is served by the server as well). It would be great if our native clients could validate this, I will open an issue.