When submitting bug reports, it is a good idea to
- Realize that you’re asking for help from people who (usually) have day jobs, and
- Expend at least some amount of effort to show you’re not expecting someone else to do all the work.
With that in mind, let me introduce to you the Best Bug Report Comment, Ever†
First the bug report:
I don’t have the exact errors to post because I deleted my compile log, but they are the same errors you get if you don’t have the bzip2 development libraries installed, which of course I do in /www
Then someone helpful asks for more information.
Please recompile so that you can tell us te exact errors.
And then, GOLD:
The php developer who added/maintains bzip2 support will know what I am talking about. I am not going to compile when I know this! It would be a waste of my time.
Now, not to worry; a few minutes later the submitter saw the error of his ways, compiled his code, posted the exact error message and got help.
Learning how to ask questions is a skill. Mastering this skill can only help, because everyone (even the Super-cool techno guru) has to ask for help at some point, so why not be as effective as possible?
† Until I find another one. That place is GOLD!
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.
(Photo credit: Wikipedia)
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.