Hacker News Reader

Comment by jfindley | Hacker News Reader

Your crypto choices seem somewhat unusual. PBKDF2, while not necessarily unsafe, is a fairly old KDF to choose for a new product. Can you go into more detail about your rationale for choosing this over newer KDFs? Why did you choose AES256-CBC over other, safer modes? Why are you doing crypto in javascript despite shipping browser extensions and mobile clients?

I don't want to imply that these things automatically make it insecure, but to me at least they raise questions, and none of your copy appears to address this. Thanks!

View on HN

Thanks for the question. Sorry I couldn't get to these questions sooner as I have been overwhelmed a bit with all the questions and feedback rolling in.

PBKDF2 is an standard that is readily available in all the frameworks being used for this product. This is important because all products must be doing crypto the exact same way and this can be a bit of a challenge to keep in sync without a standard. I am also attempting to keep my third-party library exposure to a minimum when it comes to crypto functions. I realize that PBKDF2 is a pretty old function, however, I am not aware of any risks in using it as long as iteration levels are properly increased over time.

AES256-CBC is used because it provides the level of crypto that is needed for this type of application. I realize that CBC lacks the integrity checks that other methods may offer, however, I am not sure integrity is needed to still provide a secure exchange of ciphers from a trusted source as is being done here.

Crypto is only done in Javascript for the the website and browser extensions. Maybe I am not understanding your question here fully, but I am not sure of any other way to handle Crypto on the client side for these environments. For the mobile products, crypto is being done using local CommonCrypto (iOS), BouncyCastle (Android), and .NET.

I hope this answers your questions and thanks again for having a look!

The logic through the system is for actually hashing a password is a little strained, and I'm not sure if it's obviously secure or not:

psuedo steps:

  1.) Get a master password from the user
  2.) Get an email from the user
  3.) Call makeKey(masterPassword, email) where makeKey is 5000 rounds of pbkdf2(masterPassword, email) with a resulting 256 byte hash.  Seems weird to use the email as a salt rather than random bytes.
  4.) Take the result of makeKey and call pbkdf2(masterPassword, hash) for 1 round and resulting in a 256 byte hash.

So a 256 byte key is created from the 'master password' and email (as salt) with 5000 rounds of pbkdf2. Then the result is used as a salt for a single round of pbkdf2 of the 'master password' again.

It just seems odd to use the master password to create a hash, then rerun the same hash algorithm with that hash as the salt.

My guess is that it's because PBKDF2 is provided as part of the .NET Framework.

It is? I've been using the PBKDF2 NuGet package, which I do not believe is from Microsoft. Are there classes I've missed that are built into .NET?

EDIT: It seems .NET does support it, but only with SHA-1.

Note that .net core supports sha1 through sha512[0]

[0] - https://github.com/aspnet/DataProtection/blob/00d593f1f29884...

Thanks; this is really helpful to know. I'm in the process of converting a bunch of repos to .NET Standard so it looks like I can just ditch the PBKDF2 NuGet package.

> Your crypto choices seem somewhat unusual. PBKDF2, while not necessarily unsafe, is a fairly old KDF to choose for a new product. Can you go into more detail about your rationale for choosing this over newer KDFs?

What would you recommend for resource constrained environments, like mobile phones? PBKDF2 is already very slow (from a UX perspective) on low- and mid-range Android phones. You also don't have the luxury of having tons of RAM available for a memory hard KDF.

The slowness generally is configurable parameter ("work factor" or some such) and the value is a trade-off between security and usability. The choice of KDF does not really enter into the picture, I think all of mainstream ones can be configured to be fast enough for mobile devices.

Is there any real advantage to using, say, scrypt or Argon2 if you're going to be turning its work factor down to "PBKDF2 level" anyway? I could be wrong, but seems like diminishing returns. From a practical point of view, PBKDF2 ain't broke and is already available out of the box almost everywhere.

I will answer this question in a bit when I have some more time.

Reply on news.ycombinator.com