I never understood what hash salting was until I read
this. A really good article which explores all the angles on making a basically secure web-app, with a lot of examples.
So the lessons for developers:
- Password storage should always be done using a strong hashing algorithm. IT should be one designed for password storage and also use a cryptographically random salt. It also must be a slow hashing algorithm - read Our password hashing has no clothes if this is a foreign concept.
- Password retrieval should never happen. Indeed it can’t if you’ve implemented the previous step correctly. Always implement a secure password reset process. Read Everything you ever wanted to know about building a secure password reset feature for some tips on this.
- Never mix HTTP content into your HTTPS pages. If HTTPS is important to you - and it should be - either explicitly refer to the HTTPS protocol in your references or even easier, use protocol relative URLs. There’s plenty of info in OWASP Top 10 for .NET developers part 9: Insufficient Transport Layer Protection.
- Always send authentication cookies over HTTPS. These are almost as valuable as the password itself; it gives anyone who holds them the rights to perform any tasks the user who originally authenticated to the system can. See the link in the previous point for more information.
- There should never be restrictions on password entropy. Don’t exclude special characters, don’t chop the length at a short, arbitrary limit (if you have to, make it 100 chars or so) and definitely don’t implement a system which is case-insensitive. See Who’s who of bad password practices - banks, airlines and more for more common mistakes.
- Ensure basic security configurations are correct. Tracing is off, custom errors are on, a default redirect page exists, debug mode is off, etc. This is obviously for ASP.NET, but there are parallels in other web stacks. Check your .NET apps with ASafaWeb.