With Pwned Passwords API, annoying password policies can finally go away
Update password policies at your company by following the 2017 NIST regulations—improving user experience drastically, and the Pwned Passwords API can help.
Some of the biggest names in the industry have spent the last decade and a half declaring that “passwords are dead,” but it’s become quite clear that they’re anything but. Still, that doesn’t mean we can’t make passwords less obnoxious and eliminate some of the more annoying password policies that have been in place for a long time.
In 2003, the National Institute of Standards and Technology (NIST) released password policy guidelines that many organizations use today, and that have been annoying users for nearly the entire time. These policies included password rotation and constructing a password that’s a mix of upper and lowercase letters, numbers, and special characters (ugh).
As was widely reported last year, the author of the 2003 NIST Special Publication 800-63A, Bill Burr, regrets ever making those password suggestions. Thankfully, NIST released a 2017 version of their guidelines, providing updated password policy guidelines.
Jack was excited when the new NIST guidelines debuted, seeing that the federal password policies suggest ending password rotation and complexity requirements. It would require some additional work for IT admins to set up, especially when it comes to ensuring end users don’t try to use passwords appearing in data breaches.
NIST Regulations
First, let’s take a look at the NIST password policy guidelines (I’m not covering every rule, just the big ones). The 2003 guidelines resulted in passwords that were difficult for users to remember, but not for computers (e.g., “p@$$word1”). Password rotation also meant that users may just change their passwords from “password1” to “password2,” making it easy for someone to potentially guess their new password if they got a hold of their previous one.
To follow the new 2017 NIST guidelines, IT should drop composition rules. Don’t force the use of at least one uppercase letter, lowercase letter, number, and special character unless users actually want to. Additionally, unless there’s evidence of a breach, users shouldn’t be required to change their password periodically (i.e., kill password rotation—yay!). IT also needs to make sure to keep passwords safe by instituting one-way hashes and salting.
Next, change password creation requirements involving character lengths: longer is more secure. Oftentimes, systems require users stay within a specific character length (usually around 6-8 characters), but NIST says to make passwords at least eight characters long and allow for really long passwords, should the user so desire. Longer passwords make it even more difficult, expensive, and time-consuming to crack.
Users should not be allowed to create passwords that are dictionary words, feature repetitive or sequential characters, and use context-specific words (NIST says, “such as the name of the service, the username, and derivatives thereof”).
Lastly, users cannot select passwords discovered in previous public breaches. This particular aspect can be difficult to implement, and that’s where a handy-dandy little compiled list/API comes into play: Troy Hunt’s Password Pwned API.
Pwned Passwords
Troy started compiling all known data breaches and launched haveibeenpwned.com in 2013 to help consumers (and organizations) learn if their user credentials leaked. Users can enter their email address on the website and discover if it ever leaked during one the numerous breaches. IT admins can also use haveibeenpwned to search for accounts on a specific domain (after undergoing a domain verification process) and get notified if a future breach includes any email addresses from their domain.
Troy then expanded it into a Haveibeenpwned API and later released the Pwned Passwords API. The latter API (also available as a downloadable file) came about as a result of the 2017 NIST guidelines, as there really wasn’t a database of breached accounts anyone could compare user passwords against—making it hard to actually follow the NIST guidelines.
Since releasing the Pwned Passwords API v1 in August 2017 (v3 came out in July 2018), numerous companies have incorporated it into their consumer-facing offerings. Some of the bigger names include 1Password, Australian online retailer Kogan, and the MMORPG Eve Online.
We wondered whether any of the enterprise identity management providers used the API, and looked into Azure and Okta.
Microsoft doesn’t appear to have a database of breached passwords or use the Pwned Passwords API with Azure Active Directory. Instead, Azure AD Password Protection (currently in public preview), does feature a banned password system that prevents using the 500 most common passwords as well as allowing admins to create their own custom list of banned passwords. Theoretically, you could just add the downloadable Pwned Passwords list here, unless you’re limited to a finite number of banned passwords.
Okta does use the API, to some degree. They created a Chrome extension and recommended that developers use the Pwned Passwords API in conjunction with PassProtect (which also uses the Haveibeenpwned API), but it doesn’t appear Okta uses it in their enterprise products (or just aren’t open about it). However, they have said previously that Okta Identity Cloud does include a compromised password detection feature that checks user passwords against ones used in data breaches.
So, it doesn’t appear that enterprise identity management providers have such an extensive list to compare new passwords against, which is something that Okta commented on in their blog post. “In order to check a user’s password against a list of breached passwords you need to have a massive database of every set of leaked credentials. This is not only impractical, but a risk on many levels (security, legal, compliance).”
Identity protections slowly improving
Following the 2017 NIST guidelines and changing password guidelines for your organization is just one part of overall puzzle that is improving identity and access management.
(This is just like how I wrote recently about hardware security keys, such as the Yubico YubiKey or Google Titan Security Key, which are also still just one aspect—albeit a strong aspect—of authentication.)
The overall trend is to include not just one or two factors, but many factors, including device context, user behavior, and more, to strengthen security.
But passwords are still a very important (if not the most important) aspect of IAM because they’re still the primary way to get into most accounts. At least now we can make password policies easier!
