Security

10 common security mistakes that should never be made

There's no shortage of difficult security challenges -- so why take chances and overlook the easy stuff? Chad Perrin describes some of the worst (and all too common) security oversights he sees on a regular basis.

There's no shortage of difficult security challenges -- so why take chances and overlook the easy stuff? Chad Perrin describes some of the worst (and all too common) security oversights he sees on a regular basis.


The following is a list of security mistakes I see all the time. They're not just common, though -- they're also extremely basic, elementary mistakes, and anyone with a modicum of security knowledge should know better than to make them.

Note: This information originally appeared as an entry in our IT Security blog. It's also available as a PDF download.

#1: Sending sensitive data in unencrypted e-mail

Stop sending me passwords, PINs, and account data via unencrypted e-mail. Please. I understand that a lot of customers are too stupid or lazy to use encryption, but I'm not. Even if you're going to give them what they want, in the form of unencrypted sensitive data sent via e-mail, that doesn't mean you can't give me what I want -- secure communications when sending sensitive data.

#2: Using "security" questions whose answers are easily discovered

Social security numbers, mothers' maiden names, first pets, and birthdays do not constitute a secure means of verifying identity. Requiring an end user to compromise his or her password by specifying a question like that as a means of resetting the password basically ensures that the password itself is useless in preventing anyone who is willing to do a little homework from gaining unauthorized access.

#3: Imposing password restrictions that are too strict

I've seen an unacceptable number of cases where some online interface to a system that lets you manage your finances -- such as banking Web sites -- impose password restrictions that actually make the interface less secure. Six-character numeric passwords are dismayingly common, and the examples only go downhill from there. See "How does bad password policy like this even happen?" for another example in more detail.

#4: Letting vendors define "good security"

I've said before that there's no such thing as a vendor you can trust. Hopefully, you were listening. Ultimately, the only security a corporate vendor really cares about protecting is the security of its own profits and market share. While this may prompt a vendor to improve the security of its products and services, it sometimes prompts exactly the opposite. You must question a vendor's definition of "good security," and you must not let vendors tell you what's important to you.

#5: Underestimating required security expertise

People in positions of authority in corporations often fail to understand the necessity for specific security expertise. This applies not only to nontechnical managers, but to technical IT managers as well. In fact, standards working groups such as the one that produced the WEP standard often include a lot of very smart technologists, but not a single cryptographer, despite the fact they intend to develop security standards that rely explicitly on cryptographic algorithms.

#6: Underestimating the importance of review

Even those with security expertise specific to what they're trying to accomplish should have their work checked by others with that expertise as well. Peer review is regarded in the security community as something akin to a holy grail of security assurance, and nothing can really be considered secure without being subjected to significant, punishing levels of testing by security experts from outside the original development project.

#7: Overestimating the importance of secrecy

Many security software developers who make the mistake of underestimating the importance of review couple that with overestimation of the importance of secrecy. They justify a lack of peer review with hand-waving about how important it is to keep security policies secret. As Kerckoffs' Principle -- one of the most fundamental in security research -- points out, however, any system whose security relies on the design of the system itself being kept secret is not a system with strong security.

#8: Requiring easily forged identification

Anything that involves faxing signatures or sending photocopies or scans of ID cards is basically just a case of security theater -- putting on a great show without actually providing the genuine article (security, in this case) at all. It is far too easy to forge such second-generation (or worse) low quality copies. In fact, for things like signatures and ID cards, the only way for a copy to serve as useful verification is for it to be a good enough copy that it is not recognized as a copy. Put another way, only a successful forgery of the original is a good enough copy to avoid easy forgery.

#9: Unnecessarily reinventing the wheel

Often, developers of new security software are re-creating something that already exists without any good reason for doing so. Many software vendors suffer from Not Invented Here disease and end up creating new software that doesn't really do anything new or needed. That might not be a big deal, except that new software is often not peer reviewed, it makes security mistakes that have already been ironed out of the previous implementation of the idea, and it generally just screws things up pretty badly.

Whenever creating a new piece of software, consider whether you're replacing something else that already does that job and whether your replacement actually does anything different that is important. Then, if it is doing something important and different, think about whether you might be able to just add that to the already existing software so you will not create a whole new bundle of problems by trying to replace it.

#10: Giving up the means of your security in exchange for a feeling of security

This is a mistake so absurd to make that I have difficulty formulating an explanation. It is also so common that there's no way I can leave it out of the list. People give up the keys to their private security kingdoms to anyone who comes along and tells them, "Trust me, I'm an expert," and they do it willingly, eagerly, and often without thought. "Certificate Authorities" tell you who to trust, thus stripping you of your ability to make your own decisions about trust; Webmail service providers offer on-server encryption and decryption, thus stripping you of end-to-end encryption and control over your own encryption keys; operating systems decide what to execute without your consent, thus stripping you of your ability to protect yourself from mobile malicious code.

Don't give up control of your security to some third party. Sure, you may not be able to develop a good security program or policy yourself, but that doesn't mean the program or policy shouldn't give you control over its operation on your behalf.

About

Chad Perrin is an IT consultant, developer, and freelance professional writer. He holds both Microsoft and CompTIA certifications and is a graduate of two IT industry trade schools.

17 comments
letter_2_roy
letter_2_roy

Dear Sir / Madam, Hi, this is too important to forget as an Sys. Administrator, is an opinion of mine so far. This is quite excellent and deserves a bravo !! With thanks & regards, Swapan.

ssharkins
ssharkins

Most people fail to make the connection between data and assets -- your data is money. I think a company should treat their data just like every other physical asset and then, once security is in place, try to breach it. That's what physical security personnel do. I wouldn't take on a security project, I just don't have the skills, but that's one thing I would add to the process -- purposeful intent to breach the system, on a regular basis.

jdclyde
jdclyde

It is amazing how many times we are approached to outsource our security. Sure, they probably have better tools and more knowledge about security, but that doesn't mean you hand it over to an outside source. Oh, and just because someone has a nametag and a clipboard, does NOT mean you let them into your server room. Last, I get sales calls all the time, and they ask me what we are using for a firewall. ??????? Sorry, I don't give that information out to ANYONE. If you know the firewall, you know what exploits to look for.

apotheon
apotheon

What other security mistakes do you see people making far too often -- mistakes that are so basic and obvious they should never have been made in the first place?

jeduk
jeduk

"Last, I get sales calls all the time, and they ask me what we are using for a firewall. ??????? Sorry, I don't give that information out to ANYONE. If you know the firewall, you know what exploits to look for. " Are you sure you are'nt a victim of Point 7?

wallionmick
wallionmick

People were least bother about the fact and basics..! Its just irresponsibility..!! Mick..!! . imprinted lanyards | best imprinted lanyards

Lee77
Lee77

RE: #1 - with every site requiring passwords even to post comments, I don't consider most passwords to be 'sensitive' data. RE: #2 -what law requires you to provide your real mother's maiden name, city of birth etc for those requests?. I know that most people instinctively answer honestly; I found it easier to craft an alternate identity for that purpose.

Mahriman
Mahriman

Yes, they exist. In the drawer. On the monitor. On the desk. Everytime I see one, I destroy one and lock the user out of the network and wait for them to call first level support and get briefed on security policy.

Sterling chip Camden
Sterling chip Camden

... containing sensitive info is definitely the most rampant. I see it all the time, even from people who create software products that include security features. They should know better.

lauterm
lauterm

Just because you don't rely on secrecy doesn't mean you should willingly hand over any information to anyone without a need to know.

djimenez
djimenez

this is clear evidence that your password security system has failed. Do not blame or punish the poor user, it is not his or her fault. The fault is with stupid, thoughtless policies enacted by management. In my previous company, we had impossibly complicated passwords (8 or more characters alpha numeric passwords, that kept changing every 3 months). Not only that, we had at least 25 different passwords to "remember" at any one time, in order to access necessary resources such as the intranet, salesforce.com, certain company databases, e-trade, etc, etc. Not surprisingly, most employees (and me among them, although I know better)used post it notes or other low tech means to "remember" all these crazy passwords. Given this situation, why would you punish the poor user, unless you are a sadist who enjoys exercising the little power you have over the user? Place the blame where it really belongs, on ridiculous management policies that frustrate good employees and do not let people access the systems they need to do their work, and confront the management idiots that think these draconian passwords are a great idea. BTW, employees do not take kindly to people like you that add to their frustration - did you ever wonder why IT is so busy responding to "unnecessary" calls, that have you running all the time and cause you to feel superior and complain about the "stupid users"? Employees strike back in the only way they can...... :-)

buddyfarr
buddyfarr

I have brought this up before but the director of one of our divisions said that I should not question their tactics because their staff know more about HIPPAA than I ever will. Ha, obviously not.

davids
davids

If you encrypt the email, how do you get around the problem of sending the decryption key to the recipient? It would be great if we all had public-key systems set up, but most people don't, and don't have the expertise to set them up. So we come down to voice telephone and the postal service. And what makes you think they are secure?

apotheon
apotheon

If you don't have a reason to give out some information, don't give it out. You only run afoul of Kerckhoffs' Principle when you have a reason to make some information about your policies in place known, but try to keep it secret because you think doing so will improve security, or when you expend a bunch of resources trying to keep policy information secret when you could be directing those resources elsewhere. One doesn't have to actively advertise one's technology choices to avoid running afoul of Kerckhoffs' Principle -- particularly in cases where you may not presently have a way to benefit from peer review.

Neon Samurai
Neon Samurai

.. then that is a failure of the password policy because users make no effort to remember them? As someone who has eight or more chracter alphanumeric passwords; you get used to memorizing them. My new password takes a day to memorize through normaly working tasks. I do have twenty-five or more passwords mostly in the twenty random character range. For those, I use a password manager. I remember my complicated passphrase for that tool and after that, I have the library of accounts and authentications right there. I think keys are far too comlicated. I have to remember a car key, a seporate key for my house.. a bike lock key.. a mail box key.. This is madness. And they are all so complicated too. I say we have one key that fit to the same lock barrel on all these different thinks in one's life. And, no more than four dropper teeth per lock barrel because that means the keys take up less space in my pocket. Heck, we should al just leave our key in the front door because forgetting the keys in the house somewhere is really a failing of the use of locking mechanisms. I don't fully disagree; there are insane password requirnments out there that go beyond providing good security without adding value. The thing is that a brute force on a password of 15 characters takes no time at all these days though. Heck, winXP or anything previous gives up it's user account passwords in under fifteen minutes. To keep the discussion productive though, what would you recommend in replacement of passwords? Flashkey hosted certificates means users having to carry a seporate bit of hardware and you'll still want secondary authentication by finger print scanner or similar which means further hardware costs to replace all those notbooks without scanners or include add-on scanners.

Editor's Picks