When you’re rushing to get a brand new app out the door in time for a planned launch, it can be easy to brush off security concerns beyond simply ensuring that user accounts are password-protected. After all, if you’re not handling state secrets or financial data, and if your app is small and unheard-of, it’s not like you’re going to be a major target of cracking attempts… right?
In today’s episode, guest chef Brandon Dees joins us to explain why even small web applications need to be concerned with good password practices. You’ll learn how your site may be a target for reasons other than those you might expect. And you’ll get a crash course on how seemingly strong passwords aren’t as safe as they may appear.
This is part one of a two-part series. In the episode to follow, Brandon will give you some concrete advice on keeping your staff accounts secure, and on educating your users about password security. Enjoy!
Episode Script
Why Authentication Matters
Authentication may seem like a mundane and well-solved problem, but it’s a very deep and nuanced subject to understand.
In practice, it’s one of the largest security gaps being exploited in the wild.
Verizon’s latest annual Data Breach Investigations Report (DBIR) indicates that credential theft is still the number one attacker action involved in data breaches.
I’ve found that many developers relegate security considerations to a low priority due to some common misconceptions. They think of application security as something that doesn’t really apply to their project, or they hope and trust that someone else is taking care of it for them, or in some cases they may understand the technical risks but just aren’t thinking about how those details can translate into potential problems for real people.
Even if we set up our applications following best practices, what the industry considers to be best practices for secure authentication have evolved substantially over the years, and continue to evolve.
Just as significantly, our users ultimately get to decide how strong their password will be.
They’re trusting us as professionals to build our applications correctly and to tell them what they need to know to use our applications safely.
I’m hoping that I can dispel some of those misconceptions and encourage a more empathetic perspective. This should help you deliver more resilient and trustworthy systems rather than adding to the growing pile of industry data breach statistics. We’ll also discuss what we should be telling our users about how they can manage their part of authentication security appropriately.
Definitions
Before going further, I want to be sure to clarify a few terms: Authentication is the verification of a claim of identity. Authentication is not to be confused with authorization, which determines whether a given identity should be permitted to perform a given action, and is a separate topic.
Entropy is a measure of randomness or unpredictability in a system. RubyTapas Episode #306: Random Samples, Episode #310: Randomness, Episode #311: Secure Random, and Episode #315: Random Seed examine some of the tools and applications at our disposal for working more directly with sources of entropy in Ruby if you want to dig deeper.
Many motives for breaking authentication
Account hijacking can have a wide range of motives, many of which aren’t extremely obvious or even direct.
There is often a financial incentive to break into a given account. There’s a black market for re-selling account data in bulk.
It’s also possible in many cases to leverage an account’s functional power to distribute spam content, which is a big industry these days. Similar capabilities may also be exploited to conduct DDoS attacks,for which there is also a big market.
There are also more targeted ways to make money with account credentials, including leveraging sensitive data against an individual person or organization to extort a ransom. These are just some of the ways attackers can leverage cracked account credentials to make money.
Account access can also often be leveraged for other types of attacks which may not be directly related. One noteworthy example is when Mat Honan had several of his personal accounts hijacked, and a lot of his personal data destroyed, all because someone wanted his rare three-letter twitter handle for vanity reasons. The story is well worth taking the time to read to get an idea of how subtly the details of how we implement authentication systems can impact peoples’ lives in ways that are hard to anticipate.
Another interesting and eye-opening example is the story of how China used individual peoples’ browsers to take down Github to defend government censorship. This attack didn’t leverage stolen account credentials, but you could imagine a possible version of this attack that would work that way instead of using traffic interception, and my point is to illustrate that there are even broad geopolitical motives for attacks against individual web users’ accounts.
There are, of course, plenty of more personal motives for breaking into accounts, also. I won’t attempt to enumerate all the possible or likely scenarios.
Entropy in passwords is critical to security
Most methods of password cracking involve some form of systematic guessing, …
…often taking advantage of knowledge about what kinds of passwords are more likely to be chosen than others to optimize the guessing process.
The main factor that protects a given credential against these types of attacks is entropy, or how much randomness or unpredictability was factored into its creation.
A long and purely random string has a lot of entropy and could require astronomical computational energy to eventually crack.
Unfortunately for passwords, people are surprisingly predictable at making up strings that should be hard to guess.
)
From favorite “random” words, to supposedly obscure media references, to substitution patterns like replacing letters with numbers of similar shape or using structured geometric patterns on a standard keyboard layout, even when we try to come up with clever tricks to make our password more unguessable, we are very strongly biased towards methods that are easy enough to remember, …
…and there just aren’t enough variations of those to resist a modern password cracking system that can check trillions of guesses per second. I’m talking about a high end consumer PC here, not even industrial scale nation-state funded server farms.
Conclusions and recommendations
Hopefully now you’ll better understand the importance of strong passwords and authentication security in general, even in places where we may be tempted to think it’s not that important. Next episode we’ll talk about some recommendations for how to keep our apps safe and help our users to do the same.
Further reading recommendations
- HOW APPLE AND AMAZON SECURITY FLAWS LED TO MY EPIC HACKING
- DDoS attacks that crippled GitHub linked to Great Firewall of China.
- OWASP Top 10 Project
- NIST SP 800-63-3 Digital Identity Guidelines, specifically section B
- Verizon Data Breach Investigations Report(DBIR)
- Buffer App / MongoHQ Data Breach 2013
- RubyTapas Episode #530: Two Factor Authentication
Recommended tools
- Troy Hunt’s have i been pwned?
- Troy Hunt’s Pwned Passwords list
- Lastpass is the password manager I recommend for most people
- Randomly generated passphrases can provide a better trade-off between total password strength and memorability. I strongly recommend following the EFF guide, using their carefully designed wordlists and a minimum of 6 words to use this technique securely. Use more words for more security. For reference, here’s the original Diceware method of generating memorable secure passwords.
So I occasionally need a password that I need to remember in my sleep without relying on LastPass. Since the bad guys have already precomputed the hash to P@ssword123, but not precomputed the hash of MNfs7^Ec2Q5HuN!9%FvY, I can assume that they have precomputed hashes for Bangalore, B@ng@l0re, Madras, M@dr@s and so on. But should I assume that they have precomputed hashes for Bangaluru123, Ponnuru123, Machilipatnam123, Lokkichoggio123? Or for B@ngaluru123, P0nnuru123, M@chilip@tnam123, L0kkich0ggio123? All easy (for me) to remember…
TL;DR — See part 2 for how to address those special case passwords. For a bit more elaboration, here you go:
Last I checked, there were rainbow tables freely available for older hashing schemes for all passwords up to 12 characters. It’s likely that the state of the art has progressed to higher character lengths and more modern hashing schemes, but I’m not really involved in that space so I don’t keep track.
B@ngaluru123is almost certainly insecure.Lokkichoggio123might possibly be safe based on length alone, but that depends on the attack strategy used, and the standard tools for doing this are getting smarter and more efficient all the time, and they also benefit from ever faster processing hardware. Troy Hunt’s Pwned Passwords list likely contains passwords similar to your examples already because “add a number to the end” and “replace a character with a different similar-shaped one” are very commonly used, and attackers know how to optimize their cracking strategies to factor the relative probabilities of these kinds of combinations. In short, adding numbers, swapping in symbols, etc. significantly increases the total possible search space relative to lower-case alphabet characters, but it doesn’t drastically increase the difficulty of guessing based on an understanding of human nature. Rainbow tables are just a very high-efficiency attack strategy for sufficiently short or predictable passwords, but they’re not the only viable attack option. There’s also brute forcing software like https://hashcat.net/hashcat/ which can systematically generate combinations and test them against arbitrary unknown hashes in an offline attack scenario. This means when the database is breached (in infosec, we regard this as a matter of when, not if, due to inability to control for all possible threats including unknown 0-day vulnerabilities in our server software) those human-devised constructions will tend to crack much sooner than say,MNfs7^Ec2Q5HuN!9%FvY. It’s generally advised to err on the side of extra safety rather than riding the minimum requirement for “hard enough to crack” since the technology is always evolving, and you likely can’t accurately predict what resources or motives your attacker may have (See the Mat Honan story I cited).While using a password manager to random-generate, store, and autofill the majority of your account passwords is a definite must, it can’t help you for those handful of exception cases where you can’t rely on access to the autofill functionality, such as your operating system login, your password vault itself, and things like your encrypted data backups. To help you out in the case of those special passwords you need to be able to remember and enter yourself, I’ve covered introduction to a well-designed system for constructing memorable and hard-to-crack passphrases in part 2.
The basic rule of thumb here is that if it’s easy enough for a human to remember, it’s too easy. There have been cases of very long quotations from literature being used as a passphrase, but cracked due to the fact that an offline cracking system understands that it should try any human-memorable text before it attempts to crack all random combinations of sufficient length. At some length of password, the number of years it would take to test a significant portion of possible combinations reach the level of being impractical for anyone to bother with. Below that minimum length, you can bet that somebody’s going to eventually try all the possible random combinations, even if it takes them a long while. So length is just one constraint that we have, but even a 100-character passphrase that comes directly from publicly-available sources of text such as a book or wikipedia will crack easily when the correct attack strategy is used. Applying the same kinds of mutations mentioned above will make this harder, but not necessarily so much harder that it won’t still crack after a while, as tools such as hashcat optimize for testing these kinds of variations out of the box. The actual entropy involved in password generation is significant, meaning you want to add true randomness rather than “human thinks this seems like randomness”. So, replacing A with 4 or @ doesn’t help you much, but replacing 3 randomly selected characters from your passphrase with other randomly selected characters adds up to [a theoretical maximum of] 24 bits of entropy (where the estimated threshold for “practically uncrackable” is thought to be 80 bits total, by some folks’ reckoning). In reality, because you’re probably choosing from the limited alphabet of a-z, A-Z, 0-9, and a few other keyboard symbols, it’s closer to a max of 15 extra bits of entropy, if wikipedia hasn’t misled me just now. So really if you want your password to be extremely unlikely to ever be cracked by humans, with some margin of safety, you may want to have at least about 20 truly random-selected ASCII characters. The passphrase generation technique I talk about in part 2 will let you use random-selected words instead of characters, and if you apply the system properly, you can produce comparable strength with 10 words. If you’re like most people, 10 random words is much easier to memorize (and possibly to correctly type as well) than 20 random ASCII characters.
I should also mention here that now that you’ve disclosed those examples, they should each be presumed to be completely insecure for use. I think I also discuss the attack pattern of password stuffing in part 2, which is one reason to never re-use passwords across different accounts, or any password anywhere that can be presumed to be known by attackers.
“now that you’ve disclosed”
Yup. Gone. Dead. Verbotten. THAT was planned before I wrote the comment.
For those that have a linear memory, random passphrases work well. For those of us with strongly associational memory, they fail miserably, as impossible to memorize. In the classic illustrative example, if I attempted to memorize it, on attempted recall I might be absolutely sure that the initial word is “landscape”, because my brain stores a concept, and the panorama I tried to memorize is a landscape. The classic “how to remember names” never worked for me; associating a mental picture with a name, i could do that. But the picture I memorized for “Hatfield”, a hat in a quaint countryside wheat field, was recalled as “Derbyshire”, a derby in the Shire…
So I rely on long passwords that are obliquely, intimately, privately personal for those few memorized passwords, and rely on LastPass for all else.
It was worth knowing that obscure Kannadic and Telegu and Turkana place names would be included in lists of precomputed hashes. Forewarned is forearmed.
(The use of trailing numbers was for illustrative purposes only; the focus was the viability of obscure place names.)
Anything that might be found in a (any) dictionary or encyclopedia or popular media is on the relative “short” lists for cracking tools to experiment with first before escalating to true random character sequences within a given length. If some kid wants to download hashcat and try it out against a breached user database, they may not be taking full advantage of this kind of knowledge by default, but if they do just a little homework, they can easily learn about these more sophisticated cracking strategies and download the relevant configurations from others who have paved the way. A financially motivated attacker (most of the real attackers these days) or a more personally motivated attacker (presumably much more rare, but a much much scarier adversary) who’s willing to pour some real resources into cracking either as many passwords from the DB as they can, or more specifically your password, they’ll crack everything below a certain length (probably around 12-13 chars). They’ll also crack everything reasonably easy to guess (see the commonly known human strategies for password construction above) below some much higher character length, and at some level of combined entropy, you might get lucky and have them give up before your password cracks, or you might still get unlucky, but with enough random bits, the odds are strongly in your favor.