Summary

Companies often make critical password security mistakes that compromise user data, such as setting inadequate password requirements, mishandling tokens, storing passwords in plain text, over-relying on passwords without two-factor authentication, enforcing periodic password changes that lead to predictable patterns, and not using salting and peppering techniques to secure hashes.

Abstract

The article discusses common password security errors made by companies, emphasizing the importance of protecting sensitive data. It highlights poor password requirements that limit complexity and length, which can lead to easier password cracking. The misuse of authentication tokens, similar to treating them as passwords, increases the risk of session hijacking and other attacks. Storing passwords in plain text is a critical flaw, as evidenced by past breaches in major companies. Over-reliance on passwords without additional security measures like two-factor authentication leaves systems vulnerable to catastrophic attacks. The practice of enforcing periodic password changes is questioned, as it often leads users to choose weak, predictable passwords. Instead, the article suggests maintaining a list of banned passwords and checking credentials against public data breaches. Finally, the article stresses the importance of using salting and peppering to enhance password hash security, making even weak passwords more resistant to cracking.

Opinions

The article implies that many companies, especially small and medium-sized ones, are not adequately securing user passwords, which is a significant concern given the value of data.
It criticizes the practice of enforcing arbitrary password rules that do not actually improve security and may, in fact, weaken it.
The author expresses frustration with companies like Bank of America and BlackRock for their suboptimal password policies, such as limiting password length or disallowing special characters.
There is a clear opinion that tokens should be handled with more care to prevent session hijacking and that storing passwords in plain text is an inexcusable mistake, even for large companies.
The article advocates for the use of two-factor authentication and criticizes companies that do not offer this security feature.
It suggests that the common practice of requiring frequent password changes is less effective than maintaining a list of banned passwords and checking for compromised credentials.
The author is in favor of salting and peppering as essential practices for securing password hashes, thereby significantly improving security against password cracking attempts.

The Worst Password Mistakes Companies Make

Inadequate passwords requirements, unsafe token handling, and more

Nowadays, data is one of a company’s most valuable assets. It should be kept secure at all costs, since a leak can have catastrophic consequences in terms of users’ trust and business development. Many companies, though, make huge mistakes when it comes to security. This is especially true for small and medium businesses, although even big enterprises sometimes happen to get hacked because of a fatal mistake, that may lead to scandals.

Bad password requirements for users

Most web applications require you to sign up for an account to use them. We’re all familiar with password requirements certain login systems enforce, from a minimum length to the use of at least one special character. Some companies, though, get this completely wrong.

What’s the dumbest password rule you can think of? You can probably find it in this GitHub repository. It contains a list of inadequate requirements real companies enforced on their customers

What about Bank of America not allowing more than 20 characters or disallowing special characters? Isn’t it supposed to keep your money safe?

What do you think instead of disallowing passwords longer than 10 characters? BlackRock has actually made it!

Enforcing such restrictions greatly reduces the hash cracking time and also tells hackers what passwords for that specific website look like, totally for free.

Treating tokens as passwords

Many companies make their services available via some kind of authentication token. This isn’t inherently a bad practice, but you should always check whether tokens come from a trustworthy source or could have been compromised. You should neither allow the same session token to be used by different devices nor let a token alone grant access to an authenticated session.

The problem with tokens is that they can be stolen with relative ease since they are mostly stored in the browser under little protection. This opens your application to session hijacking attacks or even fake login pages. Recently, I’ve encountered a school management software company — whose name I won’t share, since they haven’t currently fixed the issue — that doesn’t perform checks on their session and login request tokens.

Storing passwords in plain text

This may seem like an error only an inexperienced developer could make, but many big companies like Facebook, Google, and GitHub have actually done this.

We all know that in case of a data breach in your database systems, all your user accounts can easily get compromised. You may not think, though, of sensitive information leaching through misconfigured logging systems. In 2019 millions of Facebook and Instagram users had their passwords found in logs stored in a readable format (about.fb.com).

Giving too much power to a password

Passwords shouldn’t be enough to be able to perform any critical operation in any system. Privileged roles must always be protected by two-factor authentication, since a single compromised privileged account could be the cause of catastrophic attacks.

Another similar issue is not providing your users with a two-factor authentication option. It’s unbelievable how many companies still don’t support this method at all.

Enforcing periodic password change

It’s no secret that the more time passes, the more likely is a password to be cracked. This is why many companies require their customers to change their authentication credentials periodically, leaving the responsibility of choosing strong passwords to them.

This can be a problem, though, because users normally stick to predictable patterns such as modifying “Summer2020” to “Summer2021” and they will usually try to work around insecure password policies. Instead of this approach, the National Institute of Standards and Technology (NIST) recommends enforcing a banned password list in order to block users from choosing weak and predictable secrets, including dictionary words, usernames and sequential characters such as “1234”.

Moreover, credentials should be periodically checked against public data breach databases in order to find out whether using a specific password is secure. Be careful, though, not to send your precious strings unencrypted through the Internet: it’s much more secure if done locally.

Not salting and peppering

As much as computers have become more powerful than ever, password cracking has never been faster. The problem is that technology greatly advances, but common passwords remain the same.

Salting consists in adding unique randomized data as an additional input to the password hashing function. The random salt would then be stored in a database and retrieved upon login requests.

Peppering consists in adding a secret piece of data as an additional input to the password hashing function. The pepper, unlike salt and hashes, are stored separately in order not to be leaked in case of a database breach.

This additional data that gets added to the password makes it unique and thus harder to crack using rainbow tables. Salting and peppering can increase the security of weak passwords and make complex ones nearly uncrackable.

Conclusion

To wrap it up, security isn’t about being 100% fail-proof. It’s rather about researching the best practices to protect systems against already-known threats and finding new vulnerabilities before malicious hackers do.

These are only a few of the many mistakes that get made in the password handling field, but they are nonetheless significant and should be avoided in any kind of application that requires some level of security.

I hope you enjoyed this article. If you know of any other big mistakes regarding passwords, please share them in a comment. Thanks for reading!

If you liked this article, I suggest you check out also this story below:

Exotic Programming Languages: Why Hackers Use Them

The world keeps evolving and so do cybercriminals. It’s important to keep up with the change so as to not fall victim…

javascript.plainenglish.io

More content at plainenglish.io. Sign up for our free weekly newsletter here.