Be a UX Cybersecurity Hero

Make passwords beautiful and strong for everyone

We’ve all been there: Sign up for an online service and you are presented with the classic username and password form. What drives me crazy, and simultaneously scares the hell out of me, is when a platform enforces a ridiculously low (by today’s cryptographic standards) password length maximum. Why would a developer or product manager artificially limit something that can meaningfully improve resistance to hacking user accounts?

8 Reasons You Might Be Limiting Password Length

1. You are storing access credentials in plain text: Come to the front of the class, hand over your developer card, and proceed directly to Pwned.
2. You built your own proprietary password encryption algorithm: Wrong Answer. Security through Obscurity does not work or withstand persistent hackers.
3. You are using an outmoded cryptographic library or algorithm: Upgrade immediately to responsible libraries with strong attack resistance.
4. You didn’t realize that password hashes are fixed length, regardless of input size: Increasing password length is essentially FREE!
5. We salt our hash: Salt is commendable for dictionary attacks but it doesn’t address an inherently short or low entropy password length.
6. I don’t want to change my validation routines for form inputs: You are using a standard input validation and field cleaning library, right? Just tweak that maximum number or regex pattern.
7. Complex or long passwords are not widely utilized: People are increasingly aware of attacks and are employing password managers. Let’s give everyone a chance to employ improved password hygiene. And did I mention it’s free?
8. All the other sites are doing it: Shockingly, I still see financial institutions or leading commercial sites that limit password lengths to surprisingly low levels. Be a leader and set the example for better passwords.

Place an ADT sign in your front yard

Consider a hacking team scouting two online platforms for potential attacks. They can view the password policy of each site:

Site 1: password length(6–10 characters, alphanumeric characters only)

Site 2: password length(16–60 characters, a minimum of at least one number, one uppercase letter, and one special character)

The team conclusion is likely this: I bet Site 1 doesn’t have a strong security centric stance. They probably don’t have a security officer, team, or consultant. I bet they have a lot of other vulnerabilities we can exploit if they don’t even care to put a strong lock on the front door. Let’s see what we can find.

Password length alone is certainly not going to protect an organization from all possible attacks. But why invite attention and market to the world that you maintain low security standards on user credentials? Let everyone know you care about security and it starts with ensuring strong protection for authentication on the platform.

It’s FREE!

We often hear that passwords are encrypted when stored, but that is not often the case. Passwords are typically stored as fixed-length hashes. Hashing is a one-way transformation that strives to prevent someone from reversing the transformation and discovering the original input value (i.e. plain text password in this use case). This is different from encryption which is designed for intended recipients to reverse the transformation and view the original un-encrypted information.

When a user signs up for a site, the initial plain text password is hashed and stored. This is done so that if a hacker or unintended user gained access to the user database, it would be more difficult to determine plain text passwords. When a user subsequently logs in, the plain text password is immediately hashed and compared against the earlier stored hash value. If they match, the user is authenticated and gains access.

One of the interesting properties of modern password hashing algorithms is that they produce a fixed length output, regardless of input size:

hash [redfoxjumps]->
0xab34fd3ade2370cf
hash [1234]->
0x11240aaaac091ffe
hash [blue-castle-swapmeet-ladle]->
0x90a122780eccf2aa

So if you are using a modern cryptographic library for hashing and storing user login passwords why set an artificial password length limit?

Scotty! We need more entropy! Now!

Ok, you’ve bought in to the idea of increasing user password maximums but what is the right numerical length? 12, 50, 100? Well the answer can become complicated when factoring in the real world of both hackers and users. Search online for recommended password lengths and you will find various analysis around how long it would take determined hackers to iterate through possible combinations of characters using various techniques, with various processing capacity. A lot of this analysis assumes that the characters of a password are selected with a high degree of randomness.

Well it turns out we humans are not exactly the best at selecting password characters on a truly random basis, for a bunch of reasons:

• Random sequences of characters are difficult to recall from memory
• Generating truly random sequences of characters typically requires some random environmental effect or phenomenon to be the seed of the data (e.g. thermal noise from an electrical circuit or quantum phenomena)
• Human readable character sets tend to affect or limit our choices

The “quality” of randomness in a password is often measured by the amount of entropy it contains. Once again we can go down a rabbit hole of exact definitions of entropy and how it is applied in various fields of science. But let’s simply say that predictable or heavily repeated sequences of characters exhibit low entropy. This allows attackers to pre-build dictionary attacks by running standard hashing algorithms against common password phrases or reduce the amount of time it takes to run though the universe of possible patterns to find a matching hash.

So facing this complex analysis we can fall back on the wisdom of xkcd: https://xkcd.com/936/

Instead of agonizing over the exact bit count and assuming some chaotic random perfection, let’s work with human users in mind. I am going to recommend a somewhat arbitrarily long password length that will accommodate 5 to 7 phrases that can be combined similar to the reference xkcd comic above. If we assume a maximum length of 10 characters per phrase that takes us up to 70 characters. Is that a perfect answer: No. But it should be cryptographically sufficient for semi-random phrase based passwords or random character sequences that might be generated from a password manager tool.

Just Do It! Do It! Do it, Do it, DOOO IT!

One of the other free things about changing just the maximum password length is that you are allowing platform users to opt-in without enforcing behavioral change on those not willing to consider longer and more entropic passwords. So what would this imply for implementation:

Product Owner: write a user story, submit a ticket, title it: Make Passwords Beautiful and Stronger

Front End: Pull up that password form template and adjust any validation and error checking criteria to accommodate 70 characters of password length.

Back End: Pull up any of your validation code. Adjust your maximum character comparison length to 70 characters. Wait a minute, don’t I need to change storage fields in the database? No, the resultant stored hash will still be the same length.

Check In that Change. Run Tests. Deploy. Smile. You just provided everyone on your site the ability to expand their account protection and security

Now send out an email and let everyone know: “We care about your security and safety so we just increased password lengths up to 70 characters. Read more about tips and tools to make passwords stronger and beautiful….”

Maybe it’s time for a social media campaign: #passwordsarebeautiful #onemorebyte #giveentropyachance

Next Level

Passwords aren’t going away anytime soon so why not bring the power of UX thinking to security? A few thoughts:

• Incorporate a password strength meter that measure entropy and resistance to real world attack methods and displays key metrics like average time to guess the password
• Provide a button/link to password and username hygiene with links to supportive tools to manage and select passwords
• Make your security policy a marketing tool and differentiator. Let people know you care about their security and constantly look to innovate
• Subscribe to a service or partnership that scans the dark web and other sources of stolen credentials. Let users know if their credentials are at risk
• Start enforcing higher Minimum password lengths. Netflix is an interesting example of a site that allows 60 character length passwords [Yeah!] but allows a minimum of 4 characters [:(]
• Incorporate gamification to encourage people to select better passwords

I plan to explore some of these ideas in more detail. In the mean time, please feel free to share any ideas you might have to make the password user experience better.

— David Odom

I write about technology, startups, and the future of computing. I am also a Managing Partner with SecureSet Accelerator. If you are building exciting cybersecurity or enabling technology products, come Join Us for an immersive experience where we bring customers into iterative product builds and drive rapid market traction!