Recently, at a client, I had the opportunity to review their security implementation on their website. I realized that it is very important to never try to design one’s own security, because of the Dunning Kruger effect. In a nutshell, folks who don’t know very much about security think they know “enough,” and folks who are very knowledgable (e.g., Bruce Schneier) realize they don’t know all that much.
So what does this mean? It means simply this:
If you design your own security system, you’re going to get it wrong.
Here are some examples of how to get things wrong.
- Storing passwords in plaintext so you can send the person the password if they forget.
- When (not if) someone breaks into your database, they instantly own every single account. They can log in, view your user’s details and change them. Since most people reuse the same password for multiple systems, the attacker can try those passwords on other popular services, such as Facebook, GMail, LinkedIn, Twitter, etc.
- Relying on application-level security to protect your data.
- This is dangerous because it is hard to ensure 100% coverage. EVERY access point—of many—to your data must be secure. Failing to cover one point leaves the system wide open. A better solution is to apply security at the data-store level. Typically, this is done using triggers and stored procedures. Your RDBMS doesn’t support those (or weakly supports them)? Find another RDBMS.
- Using the same salt for every password in the system.
- You don’t understand what salts are for and how to use them properly.
- Requiring “complex” (a number, upper- and lower-case letters and symbols but not very long) passwords.
- Nope. Ineffective.
- Relying on Two-Factor Authentication.
- For now it is working, somewhat, but crackers are rapidly finding ways to circumvent this technique.
- Relying on a “security question” in case the person forgets his/her password.
- Oh, you’ll love this. You’re creating a weak password as a backup to a (hopefully) strong password. Fail.
- Assuming by keeping the details of your implementation secret, you will be secure.
- This is dangerous because you think you’re secure. In fact, you are less secure. Kerckhoffs’s Principle is always a good starting point for security implementation: if an attacker could see all of my code and had a copy of my database, could she/he break into my system?
Getting it right
The first step is admitting that you don’t know what you’re doing.
Now go find someone who does: there are plenty of security libraries out there for every language. Find one that is mature and widely used and implement it. Keep up to date on the library’s mailing list so you will receive alerts, and update whenever there’s a new version.
Security is hard to do. It is extremely hard to do correctly. Don’t fall into the trap of thinking you can get it right without years and years of study and experience.
Related articles
- Blizzard hacked, warns users to change passwords (zdnet.com)
- Security tip: do not answer security questions correctly (ghacks.net)
- Security Questions: The Biggest Joke in Online Identity Verification (theatlantic.com)
- An even easier way to better passwords (rgbartlett.co.uk)
