Passwords became the scapegoat

One of the areas I've been researching for a while is historical data and credential breaches. There's something circular about all of them.

The unfortunate part is that almost all of them could have been prevented with resources that were already available. A gap in expertise around best practices was the biggest and most common reason. Another organic reason is that security is always seen as a cost, so, for understandable reasons, it sometimes comes too late.

The common theme: passwords as credentials became the scapegoat for everything below.

1. Storing passwords in plain text or with weak hashing

• Some quite big-name companies stored passwords in plain text or as MD5 hashes.
• LinkedIn's 2012 breach exposed passwords hashed with unsalted SHA-1.
• Okta had an isolated issue where a cache key was built by combining the user ID, username and password, then hashing it with bcrypt. Bcrypt ignores everything after 72 bytes, so with a long enough username the password fell outside the hashed input, and a cached login could succeed without the right password.

2. Databases reachable from the internet with default passwords

• Enterprises used to keep databases behind DMZs where the internet couldn't reach them. That safeguard just went out of fashion.
• Databases offer TLS connections, but hardly anyone uses them.
• Databases let you enforce firewall rules, which work if you use them.
• MongoDB instances with default passwords were a popular target for attackers in the past.

3. Credential tables next to regular business tables

• Password tables sat alongside business tables, accessible to almost everyone in the company.
• Databases do support granular permissions and custom roles. It's a dying art as DBAs disappear.

4. Credential databases backed up like regular files

• Backups were accessible to everyone and don't always get the same attention and scrutiny.
• Interestingly, quite a lot of data leaks are attributed to vulnerable backups.

5. No rate limiting at all

This was probably too much work for smaller companies, so maybe we should discount that. For bigger companies, though, having no rate limiting on sensitive endpoints is unacceptable, even if it's quite common.

6. No account lockout after failed sign-in attempts

This used to be a default for companies using LDAP or Active Directory.

How complexity made it worse

All of this made stricter password complexity rules look like the natural fix. It turned out that complexity made it hard for people to come up with passwords that fit the criteria, so they came up with one super password and used it everywhere.

One site with strict password rules gets hacked, and the same password works for that user everywhere else.

Fast forward to email addresses replacing usernames. Now when one of those sites gets breached, the same email and password combination unlocks the user's accounts on all the other sites.