Cybersecurity Myths You Should Stop Believing
You hear about it in the news all the time: “This company just got hacked and had a major security breach!” Some think if companies made their security practices more difficult, they could prevent leaks. That’s rarely true. There are a lot of myths about web security that seem well intended, and we see them […]
You hear about it in the news all the time: “This company just got hacked and had a major security breach!” Some think if companies made their security practices more difficult, they could prevent leaks. That’s rarely true. There are a lot of myths about web security that seem well intended, and we see them everywhere. So, we have compiled a list of myths on security and what you should do instead to prevent a breach.
Myth: Making passwords difficult to manage is more secure
One might think that by disabling the copy-and-paste function in the log-in field that it makes users’ passwords more secure. The thought process behind this is that users must know their password off the top of their head. If it is difficult for your own users to enter their password, it must be even more difficult for hackers, right? Wrong! Most hackers use the power of their computers to enter the passwords; assume they are just bypassing the site and talking to the servers directly. So, disabling copy-and-paste or trying to prevent password managers just makes your users slower and more frustrated. This frustration can cause users to be more likely to use less secure passwords because they’re forced to type them constantly. Who wants to type a long secure password every time?
Instead, companies should ensure their site allows for automation techniques like copy-and-paste and tag credential fields. Therefore the password manager can automate the process and use proper and secure (long) passwords. If having an extra long, super secure password is just as easy as a short one, the users will be more likely to choose the more secure option.
Myth: Special characters, lower/uppercase, numbers make a password more secure
Surprisingly, most sites subscribe to this myth so it is easy to see why so many people believe this to be true. Try and guess which password is more secure: “29^K*xu#” or “bold engage thanks math socks.” Just because the first option has lots of numbers and symbols does not make it more difficult for a hacker (or their computer) to guess. Computers are very good at guessing the first option, as it is only 8 characters. Let’s assume we have 90 characters to pick from: A-Z, a-z, 0-9, plus about 28 special characters. This means users can have 4.3Ă—10^15 passwords, which may seem overwhelming to a human, but it is easy for a computer. So, in terms of the second option, how can just five words be more secure? Most English speakers know 40,000-48,000 words. We’ll assume we are on the high end of that spectrum. Given that information, and the five words used in our second option, a user could have 2.5Ă— 10^23 passwords that a computer would need to try to hack. That is 59,000,000 times more difficult to guess than the first option! Now, if a user was asked to remember and type their password, which would they be more comfortable with? Most users would prefer option two (“bold engage thanks math socks”) because it’s less random and easier to remember.
Therefore, instead of limiting users to passwords with caps of 8, 16, 20, or even 99 characters, it could be useful for companies to allow them to have password lengths of 255 (or even no maximum length!). Companies can also stop requiring lowercase, uppercase, numbers, and/or special characters. We now know this does not add any extra security, but it does slow users down and encourage bad security behaviors. If you research it, you’ll find that passwords involved in a security breach are mostly just one or two words with a special character and number inserted. Hackers know to look for passwords like these, making this type of password even less secure.
Myth: Having your servers keep user passwords make your site more secure
Some sites store a plain text copy of user passwords, and some will even recover a forgotten password by emailing the user their lost password. While this sounds convenient, this practice is very insecure. If (or, rather, when?) that server is hacked, then all of the password data will be taken. Often this data can be used to gain access to other accounts as well because passwords are repeatedly reused. Explaining to users that their plain-text passwords in addition to other information was lost in a data breach is the kind of PR that ends companies.
So, what should you do instead? Well, you can start by not having users send their passwords to your server in the first place. The simplest way is to just have web clients hash (and salt) the password before even sending it to the server. This results in the server only knowing the halt for authentication without ever seeing or knowing the true password. Therefore, if/when the server gets hacked, it still would not be able to give away users’ credentials. Why? Because it never knew them in the first place – it only knew the hash. If a proper hash (and salt) is used, the resulting key can be far more secure than most passwords users produce on their own. This adds another benefit that was alluded to earlier: the ability to let users use just about anything for their passwords. By using a good hash, if the user wants their password to be eight or 8,000 characters long, the hash will be the same length! This allows users to enter long passwords without imposing limits. It is still important to enforce a minimum length for a password, like 16 characters (and prevent repeating or ascending/descending sequences). Good security should also allow (but not require) special characters, spaces, numbers, and be case sensitive. If a service follows these practices and they get hacked, they have not leaked anything useful for hackers regarding users’ credentials that can be used to steal information on other sites.
Myth: Backup security questions should be used to recover forgotten passwords
Sites often ask for a set of security questions as a backup in case you forget your credentials. But the types of questions asked are frequently questions that can be answered with a simple public records search. Additionally, they almost always are saved as plain-text because they are often verified by a support representative, which reiterates our problems above. If one site gets compromised, it would be easy for your users to become a double victim; either by a case where your servers get breached leading to users’ other sites getting breached or due to other sites getting breached also leading to your users getting breached. Why would a hacker try to guess your ultra-complex hard to guess password when they can just look up your mother’s maiden name?
Pro-tip: the answer is not to use unique or less frequently used backup security questions. The answer is not to use them at all. Instead, if you need to have a password recovery method, use email. Almost every service nowadays requires an email, so why not put it to use? Another option is using SMS if the service collects user phone numbers. But remember that the password recovery process should be behind a CAPTCHA or similar technology to make automation (and brute force) more difficult. And make sure never to send a user a plain-text password; rather always use a URL link with a reset token.
Alan lives and breathes science, engineering, and computers. He is an engineer with a background in desktop architecture and design including integrations with engineering simulation software. Alan has had the wonderful opportunity to train and educate users in using complex engineering tools. He has a passion for learning technologies and techniques for robustness, reliability, maintainability, and passing that knowledge to others via mentoring, coaching, and paired programming. Outside of work, he loves playing board games, developing mods for video games, driving boats and D&D. Alan is also an enthusiastic fan of orange and emojis. 🧡