The course is free and takes 6 weeks long, and is very interesting if you had never dwelled too deep into security or crypto. There's also a new cryptography class that will be available in September of 2017 - https://www.coursera.org/learn/crypto2.
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 or BLAKE2X
And of course for each of these items, if a NaCL/libsodium solution already exist, just use it.
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!
For pretty much any crypto task that a "run-of-the-mill programmer" is likely to run into, they've got you covered.
Secret key encryption: https://download.libsodium.org/doc/secret-key_cryptography/a...
Password hashing: https://download.libsodium.org/doc/password_hashing/
The problem I have with most of the crypto libraries is that their attack surface is absolutely enormous.
Most people don't need SSL. Most people don't need a zillion choices.
Most people need a single choice that actually works and is resistant to programmer error.
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/
Start at https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet
[protected form] = [salt] + protect([protection func], [salt] + [credential]);The code examples are in Python, but I plan to add pages in other languages.
I've also come to realize that one should take everything that SG says with a large table spoon of salt.
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 OWASP guidance is OK for a quick access to best practices, but insufficient for rigorous learning.
Cryptography takes time to digest the fundamentals and recognise how new concepts are both beneficial and, vitally, disadvantageous; sadly, there is no cheat sheet or quick fix.
Source: computer security PhD student.
* PyCon Crypto 101 - https://www.crypto101.io/ (and if you use Python, please use Cryptography library for encryption/decryption please, Python built-in provides sha and hmac already though, and please adopt your framework's security implementation whenever possible).
* Mozilla Web Security Guidelines - https://wiki.mozilla.org/Security/Guidelines/Web_Security
* Mozilla Secure Coding Guideline - https://wiki.mozilla.org/WebAppSec/Secure_Coding_Guidelines
* Mozilla Server Side TLS - https://wiki.mozilla.org/Security/Server_Side_TLS
* Mozilla Intro to Cryptography (slide: https://april.github.io/crypto-presentation video: https://www.youtube.com/watch?v=bg32spD2mB0)
* Mozilla Web wiki - https://developer.mozilla.org/en-US/docs/Web (understand CORS, Cookies, CSP, etc)
* Google's course on security - https://google-gruyere.appspot.com/ (original course page has been taken down by Google already)
Book recommendations:
* The Web Application Hacker's Handbook
* The Tangled Web: A Guide to Securing Modern Web Applications (written by the famous Michał Zalewski working at Google, and lately known for developing the American Fuzzy Loop AFL which has been used for uncovering many new CVE bugs).
* Hacking: The Next Generation
* Securing DevOps (to be released soon)
Publications:
* USENIX - https://www.usenix.org/ (tons of free high quality conference talks, I like USENIX over ACM)
* Real World Crypto
Getting real
* Go find bug bounty program out there, many well-written posts how one discovered bugs
* Follow a bunch of security engineers / security-minded folks on Twitter (e.g. @matthew_d_green would be a good start)
OWASP is a great reference, you read it as an index page. But like others have pointed out, the Wiki is often outdated, but concepts almost always remain the same. Use multiple resources before implementing a solution, and never just copy and paste solution posted by others on Stackoverflow. Sorry for so many Mozilla stuff definitely there's some bias from me but I trust folks running the sec team there.
> The other Password Hashing Competition finalists (Catena, Lyra2, Makwa, and yescrypt)
These were promoted above PBKDF2; algorithms with few implementations. PBKDF2-HMAC-SHA-512 with sufficient iterations is typically robust, and has been scrutinized.
I personally prefer scrypt, but in lieu of a solid scrypt or bcrypt lib I wouldn't hesitate to lean on PBKDF2 over the others.
Argon2i was in the same boat but being in libsodium went a long way to reinforcing trust, although Argon2i and Argon2d should really have had distinct names.
Although PBKDF2 is more widely available than bcrypt or scrypt, it doesn't offer the GPU resistance that we need from a password hashing function. If you must use PBKDF2, make sure you use at least 100,000 iterations and a SHA2 family hash function.
To reiterate: PBKDF2 can still be secure. It's the least secure of the acceptable password hashing algorithms on this page, so we aren't going to provide any example code.
I should probably update it to use one of the more modern algos, but the availability of good bcrypt libraries makes it solid advice still.
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.
I did the challenges years ago when you had to email in for them. Since then I can count at least five occasions where having done the challenges has allowed me to identify vulnerabilities in real-world crypto. I was usually able to recommend fixes that in theory made those codebases more secure. This is keeping in mind that I'm at best a hobbyist security researcher and just barely a professional developer.
I think there are about seven or eight people on Earth that I would trust to securely implement cryptography in their code. For the rest of us I'm happy with doing the best we can with libraries that make that easy (NaCl), and otherwise trying to find ways to break the thing. The cryptopals challenges help you do that, so that's where I'd recommend a developer start.
I see a lot of "don't use" but I don't see any "do use" for that case.
Underlock is a small Ruby library that helps with Encrypting/Decrypting of files and other data.
OWASP seems like a decent source for learning about security topics at a high level (particularly web app security).
NIST is also responsible for running https://nvd.nist.gov/ which is a great asset for finding CVE.