Password (IN)SANITY: Intelligent Password Policy & Best Practices

13 min readAug 9, 2017

© Pinky and the Brain Swearing Video [NSFW]

Password policies need to evolve as we learn how humans use and abuse them. We all need to educate our family and friends and develop applications and services capable of change.

This article takes a fresh look at passwords, multi-factor authentication, and biometrics — outlining best practices and imminent threats our users face: so you can challenge bad practices.

About the Author

Andrew Douma is a vendor-neutral IT Security Professional. He performs professional audits, penetration tests, and risk assessments. He designs secure networks and engineers high-assurance systems in the Cloud.

You can connect with him on GoodReads, LinkedIn, Medium, and Twitter.

Something you know

The combination of a username (often your email address) and password are regularly the sole means of authenticating your identity as a valid user — which in term dictates what you are authorized to do.

We forget that discovering valid usernames is half the battle for cyber criminals, why make it easy?

Discovering valid usernames is half the battle for an attacker; aided by large public datasets from past data breaches — or predictable (corporate) email address patterns, coupled with names harvested from LinkedIn.

Most security controls do not detect let alone block attacks against web applications and web browsers. An attacker with no prior knowledge can learn a lot by how a web application or service responds to his requests.

Whenever you log in, oftentimes an app checks your username first, if it finds a match, it will take the computational effort to hash the password, and compare it against the hash value stored in its database.

Though this may appear to be a sound strategy, it allows an attacker to enumerate valid/invalid usernames based on the time it takes to get a response. The extra database lookups and hashing make it apparent.

Even if the attacker has no success enumerating valid usernames via timing attacks, often subtle changes in the HTML body, HTTP response headers or the way Cookies are handled still give it away.

Thankfully, fewer developers give away even easier clues in error messages these days. Showing a different error message depending on if the user exists or whether it was an invalid password is a dead giveaway.

Even when the login process is designed with care, mobile APIs, registration forms, username/password recovery and change features are seldom fitted with the same protections.

Given time, between the lists of commonly used passwords and their human-preferred permutations, an attacker can expect to recover passwords for ~20% of users. Phishing the rest is made easy if usernames are email addresses.

It remains challenging to strike up the right balance between User Experience (Security UX) and application security (more on that later.)

Something you have

You will find that logging into bank or investment accounts may involve additional steps, generally referred to as Multi-Factor Authentication (MFA).

Ideally, these steps revolve around a physical device providing one time passwords or cryptographic tokens — and not an out-of-band (OOB) email or text message!

Let’s look at an example:

The login form above first evaluates the validity of the IBAN account number and checks if the card number is currently active
The user inserts their bank card into the device and enters their PIN code, which they did not get to pick themselves
The colorful QR code generated is scanned by the user with a camera on the back of the device
Triggering the device to generate a Login code, granting the user access

The bank makes additional efforts to safeguard the supply-chain from device manufacturing to distributing it to clients. These devices are tamper resistant, wiping its chips when opened (yup, I have tried).

Software-based time-based one-time password (TOTP) emulator apps are in every App-store but can never offer the same level of assurance as hardware devices.

Using a FIDO/U2F compatible security token like the Yubikey 4 is the best way to secure your accounts online.

Why is Out-of-Band Authentication bad practice?

Conceptually sending an email or text is another sound strategy that provides a good user experience. However, if used for anything other than alerting you of important account activity, dangerous for several reasons:

Secrets are sent across a public mobile telephone network — which is far from secure! (due to SS7 protocol vulnerabilities)
Senders rarely verify if the number is associated with any Telco provider and not some VoIP service; that does not establish possession of something you have
Smartphone malware is capable of intercepting and relaying text messages, and many devices run outdated versions of Android
Designers rarely consider adding MFA steps for account information changes — leaving you unprotected when your valid session token is compromised

In addition to each of these deal breakers:

Across the globe it has proven trivial to convince a friendly customer service rep to add a new line, transfer/forward a phone number or change your address and request a new SIM card in the mail if need be
How unique do you think your answers to security questions are? Can I find the information in your inbox/mailbox? Anywhere online or in a genealogy database? How many websites asked you the same questions?

The National Institute of Standards and Technology (NIST) has declared that OOB authentication methods should be retired in the recently completed SP 800–63 Digital Identity Guidelines.

Knowledge of your full name, phone number, and home address can unlock a world of hurt. Information like this is readily available by scouring Facebook events and often provided anywhere you have signed up.

The National Cybersecurity Center of Excellence (NCCoE) launched the MFA for E-Commerce project to demonstrate that contextual risk calculation, can increase assurance in purchaser identity.

Something you are

Biometric sensors come built into today’s devices; such as my ThinkPad’s fingerprint reader and Touch ID-enabled iPhone.

In addition to fingerprints, other conventional biometrics include:

Face recognition
Voice analysis
Handprint scans
Retina scans
Handwriting recognition

Biometrics can provide a great user experience, but they are not as secure as you may currently believe. The current generation of (affordable) sensors is relatively easy to bypass.

Latest developments:

Adobe has previously demonstrated their “Photoshop for Voice” technology, and the Samsung “Iris” Scanner can be tricked by a contact lens placed on a zoomed-in infrared photograph of yours.

Many fingerprint sensors are quickly bypassed using a thin film and some light pressure or by recreating a 3D printed stand-in based on a publicly available picture (damn those Megapixels!)

All while you and I leave them behind on every coffee mug we touch during our lunch break or with every voicemail we leave behind. Once a biometric is compromised, there is no option to rotate it — for some, we would not have to.

It needs to become known that a human fingerprint is not that unique, and any uniqueness observed will not guarantee that two individuals’ prints are always sufficiently different that they could not be confused.

There are also many legal considerations from crossing international borders to biometrics rarely being constitutionally protected. So stick with a 6+ digit PIN code for all mobile devices and adjust your settings to ‘require it immediately’ and ‘automatically erase all data’ after ten failed attempts (backups!)

Biometrics need to be tightly bound to a particular device that supports proper hardware-enabled crypto, similar to per-user X.509 certificates. Never to be used as the sole factor of identity verification, but as part of a multi-step authentication process backed up by something else.

Current Best Practices for Consumers

If you spend money online you have a say in bringing about positive change and awareness:

Pick products that support MFA over those without — tell the losing party why you choose their competitor!
Publicly ask your favorite sites to adopt proper MFA on Social Media — heck start an online petition to get it done
Complain and publicly alert others when websites send you a plain-text reset password via email — even louder if it was the one you set at signup!!

If your bank lacks any second-factor authentication, or still sends secrets in a text, consider it a strong indicator of their overall security posture.

Sophos’s advice on passwords from 2014

Strong Passwords

Let’s skip the frequently regurgitated and by now mostly depreciated advice on passwords strength and skip to the good stuff:

Never reuse the same username/password at multiple websites
Reusing passphrases means you risk everything on one breach

When that 3rd party website you signed up for three months ago is compromised, your email/username and password hash are sold, traded and eventually leaked onto the public internet for free.

Long passphrases are usually easier to remember and hard to crack
Your brain is terrible at picking truly random letters or numbers

Password Manager

Password managers help you generate, store and even input the best passphrase a website will accept. Think of them as the modern equivalent of writing down your passwords.

However, if the attacker obtains your ‘notebook,’ you are in big trouble. A Password Manager is a standard application that can be targeted by an attacker, just like Anti Malware solutions.

The usability vs. security tradeoff is still worth it.

Typically, an attacker will harvest any stored credentials, copy all Browser cookies to hijack any web sessions still valid, remove them from your cache and enable a keylogger to capture your username and password next time a website asks.

A password manager maintains an encrypted database to store everything. By copying the right files and capturing your master password with a keylogger, an attacker obtains access to every single username/password stored.

Keeping your devices up to date and hardening them remains relevant. It remains difficult to fully trust Android devices.

Personal Paranoia

Before Password Managers became so ubiquitous, I developed my own strategy to thwart attackers:

I registered a random domain name and kept it private
I linked it to a catch-all inbox at Zoho Mail ($24/yr)
I signed up with a websitespecificusername@randomdomain.eu
I set as strong a password as the website would allow
I always gave random answers to any knowledge based security questions
I sent this info via an encrypted email to a separate free email account

This made it very difficult for attackers to guess my usernames, very easy to setup Inbox filters and also trace which websites sold (or “lost”) my information.

It works, but there is a tradeoff between security and usability.

Recommended Password Managers

As an avid Unix user, I use ‘pass’ (password store) which is a local GPG2 based solution with many clients, GUIs, and extensions. LessPass is another solution for tech-savvy users.

I have started steering people away from 1Password, due to their pushy marketing practices, and LastPass, due to their history of security fails. Sending them to SpiderOak’s Encryptr, Bitwarden or Enpass instead.

Some prefer a deterministic solution, but be wary of their inherent design flaws. With a hosted SaaS solution, you trade-in some privacy for usability.

You may be interested in Password Safe, which was designed by Bruce Schneier (encryption expert) and works with a YubiKey 4 on Windows. It can be found in most Linux software repositories, and there is a good clone for macOS/iOS that can be synced over iCloud or Dropbox.

Another favorite Password Manager is the cross-platform and open source KeePassXC, one of the many forks of KeePass for Windows.

Ultimately the choice is yours —determine your comfort level but above all start using one!

Current Best Practices for Designers & Developers

So how do we prevent the end-user, our family, and friends, from shooting themselves in the foot? What password policy works?

It is up to you, the UX designers, app developers, and sysadmins of this world to challenge existing password policies and create applications and services capable of change.

You need to understand how easy it is to create a convincing copy of your website and host it on an identical looking domain name with a trusted TLS certificate.

By training your users and deploying security headers like HSTS and X-XSS-Protection as well as DMARC you can thwart many attacks against you systems and client browsers.

Put technical defenses in place so that simpler password still provide an effective level of security:

Secure your Environment

Never “roll your own” MFA/CAPTCHA/Crypto creations! There are so many mistakes you would inadvertently make
Deploy a WAF and HIDS — if only in detection mode
Correctly implement server-side TLS (require TLS 1.3 internally)
Correctly configure your web server and frameworks!
Correctly set up SPF (no ~all), DKIM signing and DMARC reporting
Correctly implement XSS and CSRF protections
Disable all default credentials, even in development environments!
Secure access to administrative passwords, tokens, certs, API keys!
Keep your systems up to date and require MFA for administrative access
Review SSO libraries if you support OpenID, OAuth2, SCIM2 or SAML
Never store passwords as plain text! Hash the plain text password with a random salt of at least 32 bits in length using a suitable one-way Key Derivation Function (KDF), etcetera etcetera!
Explore better balloon hashing algorithms such as Argon2id and Lyra2. Cloud based GPU and low-cost FPGA/ASIC hardware are an imminent threat; PBKDF2, bcrypt nor scrypt offer 100% protection

Security UX

Understand why focusing on usability benefits security
Always notify users of significant account activity via OOB channels
Always include account audit trails in your designs for web administrators, customer support and users
Never disable copy & paste functionality on password fields, there is zero security benefit and decreases usability (tech-savvy tip: right click, inspect, edit at will)
Never expire passphrases, compromised passwords are exploited immediately, and password rotation leads to security fatigue
Never truncate passphrases, still prevalent in IoT!
Always include compatibility for password managers in your acceptance testing

Signup

Always educate users on using passphrases, password managers, phishing and pretexting. Seeing a green address bar holds no value these days.
Never impose password complexity rules, require long 16–128 character passphrases instead, allow at least 64 characters!
Always allow any ASCII and all UNICODE characters, including spaces!
Always blacklist common passwords using NIST Bad Passwords. Consider adding your brand name, URL, and other custom words.
Password strength meters sometimes help but go with DropBox’s zxcvbn
Always offer to “show my passphrase as I am typing’’, re-hide it afterward, this improves accuracy and usability (especially on mobile!)
Never ask for password hints, for the type of users who utilize this feature makes it incredibly easy to guess the password

Login

Always educate users on using passphrases, password managers, phishing and pretexting and under what circumstances your reps would reach out
Always show the same generic error messages, regardless of if a user exists or not, irrespective of if a passphrase was correct or not!
Actively monitor for, throttle and later temporarily block IP addresses launching attacks
Add an ever increasing waiting time after each failed login attempt
Show a CAPTCHA puzzle after 3 failed login attempts, send an OOB alert
Lock an account after 10 failed login attempts, send an OOB alert
Unlock the user account after a few hours to avoid help desk calls
Periodically measure how long a valid login vs an invalid login takes (time curl) If an invalid login takes less time, add a sleep delay so it takes the same as a valid login
Adding an additional random delay at the end of both valid and invalid logins increases exploitation difficulty immensely

Password Change or Reset

Always educate users on using passphrases, password managers, phishing and pretexting and on using randomly generated codes as security answers
Always be ready to OOB notify, revoke all valid sessions, and request a password reset from one or more users on the indication of suspicious account activity or website compromise
Never ask knowledge based authentication or security questions, the concept is flawed, there are no good security questions
Always require a minimum topology change between old and new passphrases
Always revoke all valid sessions after a password change, log the user out of all devices and require a new login

OWASP Cheat Sheets

The Open Web Application Security Project (OWASP) produces free methodologies and documentation to improve web application security.

A selection of recently updated cheat sheets:

Note that not all current OWASP recommendations are NIST SP 800–63 compliant or on par with my recommendations. Same applies to the testing guides referenced below.

OWASP v4 Testing Guide

Similarly, the golden standard for web application penetration testing is the OWASP Testing Guide, relevant sections include:

Get intimate with your application and APIs using Burp Suite, PappyProxy, and ZAP and get familiar with blocking brute-force/password grinding tools.

Do you have any advice? Corrections or additions? Please do not hesitate to reply!

Feel free to share your experiences, advice, and questions in private or through the comments section.

Click the ♡ to recommend this article.