[BreachExchange] How Companies Should Secure Your Passwords

[Inga Goddijn]

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 at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.riskbasedsecurity.com/pipermail/breachexchange/attachments/20170111/b641527c/attachment.html>