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.
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.
Every few months, someone comes out with a clever attack on LastPass. In January, for example, Sean Cassidy released his LostPass phishing attack that “allows an attacker to steal a LastPass user’s email, password, and even two-factor auth code, giving full access to all passwords and documents stored in LastPass.”
LostPass is a clever phishing attack. Essentially an attacker creates a fake notice that a user’s LastPass session has expired and asks them to log in. The fake version is visually identical to the actual notice LastPass uses, and even technical users would be unable to distinguish between the real notice and a phishing attempt.
LastPass responded by removing the button in its session expiration notices (so users will, presumably, be able to better distinguish fake versions which would need to have some sort of “login” button). LastPass also now requires users to go through an email-based process to approve logins from any previously unknown device or IP address.
LastPass also points the finger at Google, saying it identified these sorts of problems with the way Chrome displays notifications, but that its complaints fell on deaf ears,
A point that was only briefly raised in Cassidy’s research was the role that the browser itself plays in this attack. LastPass has encouraged Google for years to provide a way to avoid using the browser viewport for notifications. As a true solution to this threat, Google should release infobars in Chrome that give extensions the capability to do proper notifications outside the DOM. You can see our plea for this back in January 2012 with still no resolution; please star this issue to help us raise awareness.
It is good that people like Cassidy are out there looking for ways to get around LastPass’ security, and also good that LastPass generally responds to these sort of attacks much more quickly and effectively than a lot of companies. Every time a vulnerability in LastPass is found, people I know ask me whether they should still use LastPass, and my answer so far has always been “yes.”
So far the vulnerabilities that have been found in LastPass are of the sort that I still feel far more secure using it to manage my passwords than using some other password manager or (even worse) some other method for creating and managing the passwords to the dozens of services I have credentials for.
This excellent talk by Hoyt Kesterson at the RSA 2013 conference deserves a lot more views than it has received.