BreachExchange mailing list archives
How Companies Should Secure Your Passwords
From: Inga Goddijn <inga () riskbasedsecurity com>
Date: Wed, 11 Jan 2017 14:57:45 -0700
https://scotch.io/bar-talk/how-companies-should-secure-your-passwords In 2016, Twitter, Dropbox, MySpace and Yahoo! <https://auth0.com/blog/yahoo-confirms-data-breach-of-half-a-billion-user-accounts/?utm_source=scotch.io&utm_medium=sp&utm_campaign=companies_protect_pwds> all announced major password breaches. All in all, approximately one billion unique user accounts were compromised.
From veteran tech companies to innovative upstarts, it was a rough year for
password security on the internet. In the wake of these breaches, here are some crucial best practices for protecting user passwords that every company that deals with them should be following. # Hashing <https://scotch.io/bar-talk/how-companies-should-secure-your-passwords#hashing> Lesson #1 of handling user passwords: you never “secure” or do *anything* with a bare-text user password. You also don't *encrypt* passwords. Encryption is a two-way cryptographic operation. You have an algorithm, a key, and a message. If an attacker gets access to the key you're using to encrypt user passwords, they can reverse the encryption with ease. A *hash,* on the other hand, is a cryptographic scramble that can only be checked against a string. You cannot retrieve the original plain-text password when it has been properly hashed. Salts—random pieces of data intended to protect against dictionary attacks <https://en.wikipedia.org/wiki/Dictionary_attack>—are typically added to strengthen the hash. In practice, the whole process looks something like this: [image: Salting a password] Not all hashing algorithms are made equal, of course. At Auth0, we use bcrypt <https://en.wikipedia.org/wiki/Bcrypt>, which is unique in a few ways but most notably in terms of speed. The speed of its operation can be set manually, and it can adapt in the event of an attack. With MD5 <https://en.wikipedia.org/wiki/MD5>, previously one of the most popular hashing algorithms, the speed at which it worked was its most glaring security vulnerability. To find an effective attack vector (i.e., for sending rogue certificate authority certificates) against a hashing system, one needs to locate two inputs which produce the same hash. Using off-the-shelf GPUs <http://bvernoux.free.fr/md5/index.php>, it became possible to compute through 16-18 million hashes per second—a fact which made true security with MD5 hashing impossible to achieve. The speed and the efficiency of the MD5 algorithm, an ostensible benefit to users, became MD5's biggest vulnerability. Recognized as early as 2005, the implications of this were not widely understood until the Flame malware attack of 2012 <https://en.wikipedia.org/wiki/Flame_%28malware%29>. With bcrypt, on the other hand, one can choose how quickly each iteration lasts. One could set each bcrypt invocation to be 100,000,000 times as expensive as a single MD5 invocation—making a brute force attack futile. Bcrypt is now the default password hashing algorithm for OpenBSD and several other Linux distributions. Implementing it, or one of its close relatives like scrypt, is the most fundamental thing a company can do to secure its users' sensitive information. # Craft UX to Nudge People Towards Safer Decisions <https://scotch.io/bar-talk/how-companies-should-secure-your-passwords#craft-ux-to-nudge-people-towards-safer-decisions> One of the most prevalent weak links in password security is credentials re-use. When people use the same password across numerous websites, it multiplies the number of potential attack vectors for a cracker—especially if any of those sites are storing passwords as MD5 hashes or, even worse, in plain text. Simple hashes can be searched and connected to passwords using Google—maybe the most rudimentary method of getting someone's information short of directly asking them for it. There are many reasons users re-use their passwords—laziness, password fatigue, simplicity. But a website should never *help* users make the poor decision to re-use a password, especially when the password they're nudging users to re-use unlocks something as fundamental to their email. Here's Twitter's old sign-up page. Notice that it appears Twitter is asking new users for their email address and *email password* upon registration: *Email *and *password*. It's subtle, but in the milliseconds that a user spends filling out these form fields, it's not hard to connect the second thought with the first and re-use one of the most vital username/password combinations most people have. The new Twitter sign-up page does a better job of dissociating the request for an email address from the request for a password: [image: Twitter new signup page] Yet it's still not as strong a message as “Do not use your email account's password” would be in preventing password re-use. When it comes to protecting user passwords, make sure that your site's UI and UX are nudging users towards the right kinds of decisions and not the lazy kind. # Enforce Password Strength Standards <https://scotch.io/bar-talk/how-companies-should-secure-your-passwords#enforce-password-strength-standards> Strong passwords are good passwords. Strong passwords are also harder to remember than “password” or “123456,” so you shouldn't simply hope that your users will pick something long, complex and secure. Enforcing strength standards is how you exert beneficial “soft power” over the kinds of passwords your users are choosing—so you should do it. The most basic level of enforcement keeps users from choosing dictionary words, or combinations of dictionary words. These kinds of passwords require much less effort to be brute forced. The best passwords combine different cases, numbers, and symbols—and are a certain length. [image: Auth0 Password Strength configuration] Auth0's standard for a password of excellent strength <https://auth0.com/docs/connections/database/password-strength/?utm_source=scotch.io&utm_medium=sp&utm_campaign=companies_protect_pwds> is: - At least 10 characters - Including at least 3 of the following 4 types of characters: a lower-case letter, an upper-case letter, a number, a special character (e.g. !@#$%^&*). - Not more than 2 identical characters in a row (e.g. 111 is not allowed) - Not more than 128 characters. # Enforce Other Password Best Practices <https://scotch.io/bar-talk/how-companies-should-secure-your-passwords#enforce-other-password-best-practices> A short password or one derived from a dictionary word can be simple to crack, but length and complexity aren't the only factors to take into account when setting your standards for password strength. No old passwords Especially after such wide-reaching security breaches as MySpace's and Yahoo's, you want your users to be coming up with new passwords—not re-using ones they used in the past. Cyber-criminals are constantly trying to use these leaked credentials to access valuable applications, possibly even yours. They use botnets and other techniques to validate accounts, allowing them to steal personal data, protected content, money, or even sell the accounts on the dark web. *It happens <http://www.bbc.com/news/technology-38070985> every day*. [image: Botnets may target your app] As a tool like Have I Been Pwned <https://haveibeenpwned.com/> can show, passwords involved in security breaches can often linger around on the internet in anonymous Pastebin files for years after the actual breaches. To solve this problem, Auth0 offers the Breached Password Detection <https://auth0.com/breached-passwords/?utm_source=scotch.io&utm_medium=sp&utm_campaign=companies_protect_pwds> solution, to ensure your users don’t become victims of these leaks. Our security team maintains a continuously-updated collection of breached credentials and constantly checks them during login or signup attempts. The Breached Password Detection feature: - Notifies the user via email when we detect that their password has been breached in a cyber attack. - Optionally blocks the user’s login attempt until a password reset has been done. And best of all, setting this up on your account is as fast and easy as flipping a switch. [image: Enabling Breached Passwords Detection] No personal data in passwords Using information that can personally identify you in a password is very poor security practice, but many people do it. Since using some mutation of their name, email address or birthday isn't something that's going to appear in a dictionary, they think they're being secure. The problem with that approach is that there is so much information out there about most of us—birthdays included—that using any information that can personally identify you in your password can be just as easy to crack as a dictionary phrase. This isn't an exhaustive list of user attributes you should ban from all passwords on your site—there are likely to be edge cases specific to your company or industry that you'll want to include on it—but it's a good start. Don't allow users to put any of the following in their passwords: - name - username - nickname - user_metadata.name - user_metadata.first - user_metadata.last - firstpart () example com # Mission-Critical Security <https://scotch.io/bar-talk/how-companies-should-secure-your-passwords#missioncritical-security> This isn't an exhaustive list of everything that companies need to do to keep their user information safe. From passwordless login <https://scotch.io/bar-talk/auth0.com/passwordless/?utm_source=scotch.io&utm_medium=sp&utm_campaign=companies_protect_pwds>, to multifactor authentication <https://auth0.com/learn/get-started-with-mfa/?utm_source=scotch.io&utm_medium=sp&utm_campaign=companies_protect_pwds>, Breached Password Detection <https://auth0.com/breached-passwords/?utm_source=scotch.io&utm_medium=sp&utm_campaign=companies_protect_pwds> , to better customer support <https://auth0.com/blog/5-ways-to-make-your-app-more-secure-in-less-than-20-minutes?utm_source=scotch.io&utm_medium=sp&utm_campaign=companies_protect_pwds/> and protection against social engineering-type attacks <https://auth0.com/blog/how-paypal-could-have-avoided-account-hack/?utm_source=scotch.io&utm_medium=sp&utm_campaign=companies_protect_pwds>, the number of mechanisms and tools that companies can use to prevent and mitigate the damage from breaches are many. There are also many *cost-effective* ways to keep user passwords safe. No company, large or small, should assume that the cost of securing sensitive user information outweighs the cost of dealing with the fallout. Auth0 allows companies to easily implement each of the above mechanisms, including others like rate limiting (so brute-force intruders get cut off automatically after a certain number of attempts to compromise a password) and anomaly detection. As we've seen with companies like Yahoo!, the blow to your reputation and standing from an egregious breach can far exceed the expense of maintaining user security.
_______________________________________________ BreachExchange mailing list sponsored by Risk Based Security BreachExchange () lists riskbasedsecurity com If you wish to Edit your membership or Unsubscribe you can do so at the following link: https://lists.riskbasedsecurity.com/listinfo/breachexchange
Current thread:
- How Companies Should Secure Your Passwords Inga Goddijn (Jan 12)