<div dir="ltr"><a href="https://scotch.io/bar-talk/how-companies-should-secure-your-passwords">https://scotch.io/bar-talk/how-companies-should-secure-your-passwords</a><br><div class="gmail-content">
<p>In 2016, Twitter, Dropbox, MySpace and <a href="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">Yahoo!</a> all announced major password breaches. All in all, approximately one billion unique user accounts were compromised.</p>
<p>From veteran tech companies to innovative upstarts, it was a rough year for password security on the internet.</p>
<p>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.</p>
<h2 id="gmail-hashing"><a href="https://scotch.io/bar-talk/how-companies-should-secure-your-passwords#hashing"><span class="gmail-icon">#</span> Hashing</a></h2>
<p>Lesson #1 of handling user passwords: you never “secure” or do <em>anything</em> with a bare-text user password.</p>
<p>You also don't <em>encrypt</em> 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. </p>
<p>A <em>hash,</em> 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. </p>
<p>Salts—random pieces of data intended to protect against <a href="https://en.wikipedia.org/wiki/Dictionary_attack">dictionary attacks</a>—are typically added to strengthen the hash. In practice, the whole process looks something like this:</p>
<p><img src="https://cdn.scotch.io/13133/Vdxtfn1RiaeWHCvblHJQ_Screenshot%202016-11-09%20at%2011.19.05%20AM.png" alt="Salting a password"></p>
<p>Not all hashing algorithms are made equal, of course. At Auth0, we use <a href="https://en.wikipedia.org/wiki/Bcrypt">bcrypt</a>,
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.</p>
<p>With <a href="https://en.wikipedia.org/wiki/MD5">MD5</a>, 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. </p>
<p>Using <a href="http://bvernoux.free.fr/md5/index.php">off-the-shelf GPUs</a>,
it became possible to compute through 16-18 million hashes per second—a
fact which made true security with MD5 hashing impossible to achieve. </p>
<p>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 <a href="https://en.wikipedia.org/wiki/Flame_%28malware%29">Flame malware attack of 2012</a>. </p>
<p>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. </p>
<p>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. </p>
<h2 id="gmail-craft-ux-to-nudge-people-towards-safer-decisions"><a href="https://scotch.io/bar-talk/how-companies-should-secure-your-passwords#craft-ux-to-nudge-people-towards-safer-decisions"><span class="gmail-icon">#</span> Craft UX to Nudge People Towards Safer Decisions</a></h2>
<p>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. </p>
<p>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. </p>
<p>There are many reasons users re-use their passwords—laziness, password fatigue, simplicity. But a website should never <em>help</em>
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.</p>
<p>Here's Twitter's old sign-up page. Notice that it appears Twitter is asking new users for their email address and <em>email password</em> upon registration:</p>
<p><em>Email </em>and <em>password</em>. 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. </p>
<p>The new Twitter sign-up page does a better job of dissociating the request for an email address from the request for a password:</p>
<p><img src="https://cdn.scotch.io/13133/1v1dTNHDRNqpineDIEHS_Twitter%20new%20signup%20page.png" alt="Twitter new signup page"></p>
<p>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.</p>
<p>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.</p>
<h2 id="enforce-password-strength-standards"><a href="https://scotch.io/bar-talk/how-companies-should-secure-your-passwords#enforce-password-strength-standards"><span class="gmail-icon">#</span> Enforce Password Strength Standards</a></h2>
<p>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. </p>
<p>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.</p>
<p>The best passwords combine different cases, numbers, and symbols—and are a certain length. </p>
<p><img src="https://cdn.scotch.io/13133/3m7P9RD8TcuDtkFTkhzp_auth0-password-strength.png" alt="Auth0 Password Strength configuration"></p>
<p>Auth0's standard for a <a href="https://auth0.com/docs/connections/database/password-strength/?utm_source=scotch.io&utm_medium=sp&utm_campaign=companies_protect_pwds">password of excellent strength</a> is:</p>
<ul><li>At least 10 characters </li><li>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. <code>!@#$%^&*</code>). </li><li>Not more than 2 identical characters in a row (e.g. <code>111</code> is not allowed) </li><li>Not more than 128 characters.</li></ul>
<h2 id="enforce-other-password-best-practices"><a href="https://scotch.io/bar-talk/how-companies-should-secure-your-passwords#enforce-other-password-best-practices"><span class="gmail-icon">#</span> Enforce Other Password Best Practices</a></h2>
<p>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.</p>
<h3>No old passwords</h3>
<p>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.</p>
<p>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. <strong>It <a href="http://www.bbc.com/news/technology-38070985">happens</a> every day</strong>.</p>
<p><img src="https://cdn.scotch.io/13133/QkhktRbOQqSJulCwF5ix_botnets.png" alt="Botnets may target your app"></p>
<p>As a tool like <a href="https://haveibeenpwned.com/">Have I Been Pwned</a>
can show, passwords involved in security breaches can often linger
around on the internet in anonymous Pastebin files for years after the
actual breaches.</p>
<p>To solve this problem, Auth0 offers the <a href="https://auth0.com/breached-passwords/?utm_source=scotch.io&utm_medium=sp&utm_campaign=companies_protect_pwds">Breached Password Detection</a>
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.</p>
<p>The Breached Password Detection feature:</p>
<ul><li>Notifies the user via email when we detect that their password has been breached in a cyber attack.</li><li>Optionally blocks the user’s login attempt until a password reset has been done.</li></ul>
<p>And best of all, setting this up on your account is as fast and easy as flipping a switch. </p>
<p><img src="https://cdn.scotch.io/13133/65EtUftS3RzwxXby4DFQ_enabling-bpd.png" alt="Enabling Breached Passwords Detection"></p>
<h3>No personal data in passwords</h3>
<p>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. </p>
<p>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.</p>
<p>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:</p>
<ul><li><code>name</code></li><li><code>username</code></li><li><code>nickname</code></li><li><code><a href="http://user_metadata.name">user_metadata.name</a></code></li><li><code>user_metadata.first</code></li><li><code>user_metadata.last</code></li><li><code>firstpart</code>@<a href="http://example.com/">example.com</a></li></ul>
<h2 id="gmail-missioncritical-security"><a href="https://scotch.io/bar-talk/how-companies-should-secure-your-passwords#missioncritical-security"><span class="gmail-icon">#</span> Mission-Critical Security</a></h2>
<p>This isn't an exhaustive list of everything that companies need to do to keep their user information safe. From <a href="https://scotch.io/bar-talk/auth0.com/passwordless/?utm_source=scotch.io&utm_medium=sp&utm_campaign=companies_protect_pwds">passwordless login</a>, to <a href="https://auth0.com/learn/get-started-with-mfa/?utm_source=scotch.io&utm_medium=sp&utm_campaign=companies_protect_pwds">multifactor authentication</a>, <a href="https://auth0.com/breached-passwords/?utm_source=scotch.io&utm_medium=sp&utm_campaign=companies_protect_pwds">Breached Password Detection</a> , to <a href="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/"> better customer support</a> and protection against <a href="https://auth0.com/blog/how-paypal-could-have-avoided-account-hack/?utm_source=scotch.io&utm_medium=sp&utm_campaign=companies_protect_pwds">social engineering-type attacks</a>, the number of mechanisms and tools that companies can use to prevent and mitigate the damage from breaches are many.</p>
<p>There are also many <em>cost-effective</em> 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. </p>
<p>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.</p>
<p>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.</p></div><div class="gmail-inner-guts gmail-guts gmail-no-top-margin"><div class="gmail-sidebar"><div class="gmail-not-fixed"><div class="gmail-block gmail-custom-form"><div class="gmail-row gmail-baby-gutter">
</div>
</div>
<div class="gmail-block">
<div id="gmail-bsap_1291897" class="gmail-bsap gmail-bsap_1291897">
</div>
</div><br><div class="gmail-block">
</div>
<div class="gmail-block">
</div>
</div>
</div>
</div>
<br></div>