Went through the SQL injection demo, and it recommends parametrized queries. Excellent.<p>EDIT:<p>Joined with Github, went through the password handling section, then saw this:<p><a href="http://i.imgur.com/H4h5FUY.png" rel="nofollow">http://i.imgur.com/H4h5FUY.png</a><p>No no no no NO! Do NOT use SHA256 for passwords.<p><a href="https://paragonie.com/blog/2016/02/how-safely-store-password-in-2016" rel="nofollow">https://paragonie.com/blog/2016/02/how-safely-store-password...</a><p><a href="https://codahale.com/how-to-safely-store-a-password/" rel="nofollow">https://codahale.com/how-to-safely-store-a-password/</a><p>PBKDF2-SHA256 with 100k or more iterations? Okay, fine.<p>SHA256 the cryptographic hash function not designed for password storage? Bad advice.
You should add some sort of About Us section because for this type of lessons I really need to know who is behind the site, what are his/her references & experience. Bad advice is often worse than no advice at all, and to be a trustful source of security info we need at least to have some basic info on authors. And these obviously fake "What People Are Saying" are not helping with the trust issue either.
The bit on unencrypted communication should really mention HSTS. If you're connected to a network controlled by an attacker, using TLS on its own doesn't help you. HSTS doesn't necessarily help you either, but it's a lot more likely to solve the problem in the given scenario.
Slick and a nice UI, but the security advice in this is just plain terrible.<p>Blacklist input validation as defense against XSS? Are you kidding me? And then over to session fixation, where I see the exact same ?jessionid=blah example that has been in any Web Security book for the last 10-15 years? Come on!
I feel like Secure Code Warrior has solved this problem much better with gamification.<p><a href="https://www.securecodewarrior.com/" rel="nofollow">https://www.securecodewarrior.com/</a>
> Imagine if a user has their email account hacked - the first thing an attacker will do is try to compromise their other online accounts, and long-lived password reset links make this easy.<p>I don't see how the length of time the reset link is valid really has any bearing here. I'm assuming the implication is that an attack could search for old password reset emails but if they have access to the email account, why not just request another reset?
I'm enjoying this a lot. The explanations are straightforward and the writing and animation style is entertaining. I'm liking the website parodies and the puns in the alt texts. I'm learning new things and the linked resources are good for going in-depth. I'd probably pay for advanced lessons in this style. I'll be recommending to friends!
@malcolmhere keep up the great work. I have always found the current resources to be lacking especially in terms of implementation examples. One suggestion would be to remove the Chase logo in your SQL injection examples. It is just begging for a cease and desist letter.
I like Troy Hunt's web security stuff - I'd gotten into it on Pluralsight, but then moved jobs and don't have access. I did find a free course (With SQL Injection, etc.) of his here: <a href="https://info.varonis.com/web-security-fundamentals" rel="nofollow">https://info.varonis.com/web-security-fundamentals</a>
Regarding the customer references, I'm always highly suspicious of anonymous praise. Do you not have permission from the authors or companies to use their name?