In Progress
Unit 1, Lesson 1
In Progress

Password Authentication with Brandon Dees – Part 2

In Episode #531, guest chef Brandon Dees showed us why every web application developer needs to be concerned with security, and how password-authenticated systems are often more vulnerable than we realize. Today, Brandon joins us again to provide some concrete pointers on password authentication security, including educating your users and why it’s of utmost importance to be extra careful with your staff accounts.

Enjoy!

Video transcript & code

Why Authentication Matters, Part 2

In the last episode, we talked about the importance of strong passwords and authentication security in general. Now let's discuss some actionable ways to improve password strength for yourself and understand what we can recommend to our users to do their part in protecting their own accounts.

Length vs randomness

In the last episode, as well as in RubyTapas Episode #306: Random Samples, Episode #310: Randomness,  Episode #311: Secure Random, and Episode #315: Random Seed we learned about entropy, or randomness, and how it impacts password security.

So how do we get enough entropy into our passwords? We have to use higher quality randomness, or else pile on more of it using length.

Remember that passwords should never be stored in plaintext. Rather, it's currently considered best to instead store a hash digest of the password itself, computed using a standard cryptographic algorithm that produces the same output for a given input, and is always a fixed length. Hashing passwords only protects against certain forms of attack, and only weakens those attacks to make them more time and energy intensive to succeed at.

All 12-character passwords stored using an outdated hashing scheme can be cracked using a conventional gaming PC in a matter of days in an offline attack scenario. Modern secure password hashing schemes significantly increase that cost, but 12 random bytes is still considered the minimum "reasonably hard to crack" password by experts.

Adding another random character multiplies the median brute force crack time by a large factor. Adding another random byte increases it even more. But what if those bytes aren't random?

There's still a beneficial tradeoff between length and brute force guessing time that we can use to our advantage.

All we need to do to create a strong and memorable password is to add enough total entropy to compensate for a lower per-character difficulty increase.

Diceware

But humans are generally weak at memorizing things, and even worse with truly random strings of characters. This is why we are so tempted to create predictable and easy to crack passwords in the first place.

Enter Diceware, a system designed to give us a human-usable solution to this challenge of needing increasingly long and random passwords as computational power becomes cheaper and faster.

The basic idea is to construct a passphrase using a series of words instead of individual random characters, which are more memorable due to the meaningful associations we can make with them in our minds. I won't explain this system in detail today, but I'll link to the original source and a good practical guide in the show notes.

Password re-use is a public health problem for the web

Having an unguessable password to protect your account is important, but the unguessability becomes irrelevant if you use the same password on other accounts and one of those is breached, effectively revealing your password to the internet. One of the most common techniques for taking over accounts on the internet is to look up passwords from prior data breaches and simply try them on other sites. This method is known as credential stuffing and is simple to automate. As a responsible developer you may have done all the right things to securely store hashes instead of plaintext passwords, but if some of those same passwords were leaked by another service online where they stored insecure hashes or plaintext, then your unguessable passwords are now known and don't need to be guessed anymore.

This problem is so widespread that experts consider it a "public health crisis" for the internet. The established rule of thumb is to never re-use a password across multiple accounts.

To keep track of all the unique passwords, it's recommended to use a good password manager.

Privileged credentials are a target on your back

Some accounts are more highly targeted than others, and some credentials are more important to protect than others. We can't always distinguish these without becoming omniscient, but there's a category of accounts that is always extra sensitive and important to take strong precautions with.

Accounts with privileged or administrative access, which generally include developers' accounts and customer service or admin roles. In many systems these credentials are an effective back door to access all of the data and capabilities.

When you have any account with privileged access, it's extra important to use very strong credentials to avoid becoming the attack vector for something big and bad.

One noteworthy example is Buffer's 2013 Breach, in which a customer service "impersonate user" feature was used to take over many other accounts and use the system to distribute spam posts across the web.

Whenever it's an option, enabling two-factor authentication using a time based password can prevent many of these types of attacks, so I strongly recommend you do this for all of your accounts that allow it. If you're developing or managing a system that supports these types of high-leverage accounts, I recommend leveraging your influence as a trusted expert to enable two factor authentication as a supported option for all accounts, and if possible, make it mandatory to use for privileged access. My friend Frank Rietta covers how to implement 2FA in rails apps in episode #530.

Conclusions and recommendations

The bottom line points I'd like to make are these:

  • Remember that as developers, we're trusted by our users to be responsible professionals. They rely on us to build systems that provide them with the appropriate protections. They expect us to educate them on what they need to know to use our products safely.

  • Help your users understand how to succeed at managing passwords to secure their accounts. Point them to helpful plain-english guides and suggest using a good password manager. Actionable feedback on the quality of their password choice at creation time, as an approximate measure of entropy, is also a good nudge.

  • Follow established industry best practices and standards for securing passwords for your authentication systems.

These recommendations do evolve over time, so plan for occasional maintenance and migration work as stronger solutions come along and reach mainstream adoption.

  • As a developer or administrator with privileged access to systems that manage sensitive data such as passwords, treat your own authentication credentials with extra seriousness. Use a password manager to securely generate, store, and enter unique credentials for all of your accounts.

Use very strong passphrases for those edge cases where you must be able to enter your credential yourself from memory, such as the password vault itself, your device disk encryption keys, and your encrypted backups.

Further reading recommendations

Selected case studies (mat honan, bufferapp, etc.)

Recommended tools

Responses