Security consulting firm Latacora writes about cryptography recommendations, PGP, SSH keys, Noise protocols and SOC2.
HN commenters point to its Cryptographic Right Answers and PGP Problem posts as reliable guidance and list the blog among their favorites.
It wasn't in the scope of this audit, but it's still somewhat concerning... PBKDF2 with SHA-256 (a super fast hash with hardware support) as a key derivation function (which should be slow and difficult and hard to do in hardware)? That doesn't sound right. The answer provided (cross platform compatibility) doesn't sound satisfying.
Was this discussed with the prior audit?
EDIT to add: Here's the 2018 "cryptographically right answer" on password hashing ( https://latacora.singles/2018/04/03/cryptographic-right-answers.html ):
Password handling
Percival, 2009: scrypt or PBKDF2.
Ptacek, 2015: In order of preference, use scrypt, bcrypt, and then if nothing else is available PBKDF2.
Latacora, 2018: In order of preference, use scrypt, argon2, bcrypt, and then if nothing else is available PBKDF2.
You care about this if: you accept passwords from users or, anywhere in your system, have human-intelligible secret keys.
But, seriously: you can throw a dart at a wall to pick one of these. Technically, argon2 and scrypt are materially better than bcrypt, which is much better than PBKDF2. In practice, it mostly matters that you use a real secure password hash, and not as much which one you use.
Don’t build elaborate password-hash-agility schemes.
Avoid: SHA-3, naked SHA-2, SHA-1, MD5.
EDIT to UPDATE:
Bitwarden has commented (about an hour ago) that they'll fix this! Cool.
https://community.bitwarden.com/t/switch-to-argon2/350/23
https://github.com/bitwarden/jslib/issues/52
I would point you to latacora's updated recommendations about password handling: https://latacora.singles/2018/04/03/cryptographic-right-answers.html
Adding a salt and hashing a password is not something someone should be doing in 2018. Use scrypt, or another one of the recommended algorithms, as it is a complete implementation that is well researched and can be simply dropped into most systems.
And my response was in reference to how many password you should blacklist, which using a good algorithm is still feasible to brute force easy to guess passwords in an offline attack.
In transit? Unless you know why you need something else - just use TLS. If you get to choose (as in - do not need to support WinXP/IE6/Android versions < 4.4) - select TLS1.2 with "safe/modern" cyphers.
Read the "website security" and "client server application security" sections of this and choose the advice closest to your project needs:
http://latacora.singles/2018/04/03/cryptographic-right-answers.html
and the discussion of that from last week:
https://news.ycombinator.com/item?id=16748400
The great advice there is "Let AWS AELB handle it for you".
Please consider some sort of access log for all activity around the secrets you’re managing, exposed to users in their account. Also consider a way to revoke all secrets/tokens at once with a privileged (MFA authorized) user action.
Best of luck, I think this product has a lot of value ahead based on the pain points addressed.
EDIT: This might also be of use before your SOC 2: https://latacora.singles/2020/03/12/the-soc-starting.html
I've always assumed that PuTTY used its own private key format because the OpenSSH one was terrible until about 2013.
See eg https://latacora.singles/2018/08/03/the-default-openssh.html (which is from 2018, but I think the weakness has been well known for a long time).
Some favorites of mine I haven’t seen mentioned:
https://blog.acolyer.org
https://jvns.ca
https://stratechery.com
https://blog.cloudflare.com
https://latacora.singles
https://www.schneier.com
https://www.ben-evans.com
plus an endless amount of newsletters…