When performing brute-force attacks, it’s our first instinct to go to the current season and year, i.e., Winter20, Winter2020. But it’s important to keep in mind that many organizations use a 90-day password change window, and 90 days can be a deceptively long time. For instance, as of today, February 25, 2020, the oldest passwords in such an organization would land in the end of November. It’s possible that a user has a November19 or Fall2019 password set.
To make the task of creating weak password lists a little easier, I’ve created weakpasswords.net (and south.weakpasswords.net for our friends in the Southern Hemisphere). This site displays a list of candidate passwords for brute-force attacks based on the current date and is updated daily via a cronjob.
I typically see one or both of these pieces of advice regarding the ubiquitous “security questions”:
1. Users should go to absurd lengths to hide personal details about themselves online to make it impossible for hackers to guess the answers to security questions.
A company might ask you to use your favorite movie as a security question? Better not let anybody know about your affinity for Italian horror films.
2. Users should never answer security questions truthfully. Treat them for what they (sort of) are, secondary passwords and use arbitrary answers to them.
Like so much of infosec, these pieces of advice treat the user as the problem rather than the convoluted security mechanisms they are forced to endure. The best advice is, simply,
3. Stop asking users security questions.
Security questions add additional difficulty to accessing accounts without adding any additional security. At best, they force users to create and track multiple pseudo-passwords. At worst (which I suspect happens routinely), they trick users into tying easily discoverable personal information to their accounts, which makes targeted hacking attempts much more likely to succeed.
Just stop using them.
Somebody made off with terabytes of data from Citrix, and one of the interesting tidbits from Citrix’s press release about the breach is speculation that the hackers used “password spraying,”
While not confirmed, the FBI has advised that the hackers likely used a tactic known as password spraying, a technique that exploits weak passwords. Once they gained a foothold with limited access, they worked to circumvent additional layers of security.
The Secret Security Wiki provides additional information about how password spraying attacks work,
Traditional brute-force attacks attempt to gain unauthorized access to a single account by guessing the password. This can quickly result in the targeted account getting locked-out, as commonly used account-lockout policies allow for a limited number of failed attempts (typically three to five) during a set period of time. During a password-spray attack (also known as the “low-and-slow” method), the malicious actor attempts a single commonly used password (such as ‘Password1’ or ‘Summer2017’) against many accounts before moving on to attempt a second password, and so on. This technique allows the actor to remain undetected by avoiding rapid or frequent account lockouts.
Clever. With access to enough account usernames, somebody somewhere in an organization is likely to have practiced poor password hygiene.
SplashData looked at the passwords of 5 million accounts that were leaked by various breaches in 2018, and found that many users are still using very simple, easy-to-guess passwords.
The top 10 most common passwords, for example, were:
According to SplashData, 2018 is the fifth year in a row that “123456” and “password” were #1 and #2 respectively on their list of common passwords based on analysis of breaches in that year. SplashData offers sensible steps to better create and manage passwords,
1. Use passphrases of twelve characters or more with mixed types of characters.
2. Use a different password for each of your logins. That way, if a hacker gets access to one of your passwords, they will not be able to use it to access other sites.
3. Protect your assets and personal identity by using a password manager to organize passwords, generate secure random passwords, and automatically log into websites.
But, fundamentally, the systems that are in widespread use these days are far too difficult for end users to easily secure.
DinoPass.Com bills itself as an “awesome password generator for kids.”
It’s “Simple Password” generator creates passwords/passphrases consisting of two randomly generated words in all lower case with a two digit number appended. So it turns passwords like:
happyglass25 rosecamp73 slowmonkey14
I ran across this Hacker News thread recently about Facebook’s practice of accepting four different versions of a user’s password. According to an email from Facebook, their system will accept:
- The original password – password
- The original password typed as if caps lock was enabled – PASSWORD
- The original password with the first character automatically capitalized, which is still a “feature” on some mobile phones – Password
- The original password with an extra character added at the end – Password2
Researchers at Cornell, MIT and Dropbox published a paper in 2016 about this practice, cleverly titled pASSWORD tYPOS and How to Correct Them Securely. According to the abstract,
We provide the first treatment of typo-tolerant password authentication for arbitrary user-selected passwords. Such a system, rather than simply rejecting a login attempt with an incorrect password, tries to correct common typographical errors on behalf of the user. Limited forms of typo-tolerance have been used in some industry settings, but to date there has been no analysis of the utility and security of such schemes.
We quantify the kinds and rates of typos made by users via studies conducted on Amazon Mechanical Turk and via instrumentation of the production login infrastructure at Dropbox. The instrumentation at Dropbox did not record user passwords or otherwise change authentication policy, but recorded only the frequency of observed typos. Our experiments reveal that almost 10% of failed login attempts fail due to a handful of simple, easily correctable typos, such as capitalization errors. We show that correcting just a few of these typos would reduce login delays for a significant fraction of users as well as enable an additional 3% of users to achieve successful login.
We introduce a framework for reasoning about typo-tolerance, and investigate the seemingly inherent tension here between
security and usability of passwords. We use our framework to show that there exist typo-tolerant authentication schemes that can get corrections for “free”: we prove they are as secure as schemes that always reject mistyped passwords. Building off this theory, we detail a variety of practical strategies for securely implementing typo-tolerance.