The golden rule about storing a password is to not store a password... I can't wait till SQRL takes off
I argue that one-time password with a secure MFA implementation is essentially the best viable solution.
Ask HN: Current Crypto Best Practices
21–30 of 71 posts
Re: Ask HN: Current Crypto Best Practices
#22Not necessarily best practices, but I recommend the Matasano Crypto Challenges to basically everyone. I make all of the developers on our team do them too: http://cryptopals.com
Those challenges teach vulnerabilities in old, low level cryptographic primitives. As much as I enjoyed those challenges, they are not a good place to start for a developer trying to build a secure application.
Re: Ask HN: Current Crypto Best Practices
#23Cryptography Engineering [0] is a great book that covers key topics in cryptography with a focus on best practices for implementors and system/protocol designers.
Matthew Green's blog, A Few Thoughts on Cryptographic Engineering [1], has a wealth of interesting posts that are often aimed at explaining cryptography to a "technical but non-cryptographer" audience, and tend to be motivated by recent events in security/cryptography news.
[0]: https://www.amazon.com/Cryptography-Engineering-Principles-P... [1]: https://blog.cryptographyengineering.com/
Re: Ask HN: Current Crypto Best Practices
#24OWASP (non-profit) https://www.owasp.org/ NIST (government) https://www.nist.gov/publications/
FYI I think you're getting downvoted because NIST is known to have recommended a pseudo-random number generation algorithm that is believed to have been intentionally designed with a backdoor [1], presumably by some US 3 letter agency. OWASP seems like a decent source for learning about security topics at a high level (particularly web app security). [1] http://dualec.org/
I didn't follow that discussion closely, so I will avoid the argument here on that subject. Overall, NIST is a good resource for comparison. If you work with government, enterprise security, or compliance, you want to go through NIST. If you have spare time I recommend read https://beta.csrc.nist.gov/publications.
NIST is also responsible for running https://nvd.nist.gov/ which is a great asset for finding CVE.
Re: Ask HN: Current Crypto Best Practices
#25The golden rule about storing a password is to not store a password... I can't wait till SQRL takes off
It won't. See http://security.blogoverflow.com/2013/10/debunking-sqrl/ for a myriad of reasons. I've also come to realize that one should take everything that SG says with a large table spoon of salt.
Why is that? I've heard lots of people saying that, but not had any concrete reasons why. As far as I know, he's generally correct about the things he discusses. And pretty good at making technical discussions interesting.
Re: Ask HN: Current Crypto Best Practices
#26The answers for this depend on what you're trying to do. Can you be more specific? Coda's password storage advice is still the best advice for people who don't know what they'd do otherwise.
Re: Ask HN: Current Crypto Best Practices
#27Cryptographic Right Answers is a good place to start https://gist.github.com/TheZ3ro/fb521a3cde0c91fcb350
The original from tqbf: https://gist.github.com/tqbf/be58d2d39690c3b366ad It's definitely completely relevant today. Find out what you want to do and check that list. A few things I would update: * password handling -> Scrypt or Argon2 * Client-server application security -> TLS or Noise * Hashing/HMAC algorithm -> Blake2/prefix-MAC or KangarooTwelve/KMAC * Fingerprint -> TupleHash * key derivation -> HKDF or SHAKE o…
Why would you make those updates? I like Noise more than I like TLS, but if you look at the recommendation where it says "use TLS" and ask yourself "how would I as a Python application programmer actually use Noise", I don't see the applicability.
Similarly: I like Blake2 more than I like SHA-2, but SHA-2 is universally available and strong (in the context of those recommendations, I also didn't want to explain the difference between SHA-2's HMAC and Blake2's keyed hash MAC). And, of course, part of the point of recommending SHA-2 was to recommend against Keccak. :)
I don't think I actually made a key derivation or fingerprint recommendation. I like HKDF!
Re: Ask HN: Current Crypto Best Practices
#28OWASP has some nice guidelines on a lot of topics, including storing passwords. Start at https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet
OWASP's cryptography advice is almost invariably awful, and that password storage thing is among the worst of it. It's better now than it was when it recommended against password hashes (note that it still recommends "cryptographically strong salts") but remains factually incorrect in more than one place, including the notion that PBKDF2 is better than bcrypt (the opposite is true).
Re: Ask HN: Current Crypto Best Practices
#29Earlier quoted context omitted.
It won't. See http://security.blogoverflow.com/2013/10/debunking-sqrl/ for a myriad of reasons. I've also come to realize that one should take everything that SG says with a large table spoon of salt.
> The proposed SQRL scheme derives all application specific keys from a single master key. This essentially provides a single juicy target for attackers to go after. That sounds like the same problem password managers have. And yet they are still recommended over (re-)using your own passwords for each website.
The crucial difference is that with a password manager, passwords are protected by a master key, but not derived from it. So you can rotate passwords whenever you want, either proactively or reactively, mitigating the effects of a password database compromise.
Re: Ask HN: Current Crypto Best Practices
#30Not necessarily best practices, but I recommend the Matasano Crypto Challenges to basically everyone. I make all of the developers on our team do them too: http://cryptopals.com
Those challenges teach vulnerabilities in old, low level cryptographic primitives. As much as I enjoyed those challenges, they are not a good place to start for a developer trying to build a secure application.
Low level, yes. But, old? We cover AES, HMAC, stream ciphers, GCM, RSA, DH, SRP, and elliptic curves. The criteria for inclusion on the first 6 sets of challenges was "had to be something we took advantage of on the job at Matasano". It's not textbook stuff.
Part of the point of the crypto challenges was to illustrate why people shouldn't work directly with low-level primitives, as a sort of antidote to the kind of advice OWASP gave out.