People Are Still Using Crappy Passwords in 2018

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:

  1. 123456
  2. password 
  3. 123456789
  4. 12345678
  5. 12345
  6. 111111
  7. 1234567 
  8. sunshine
  9. qwerty
  10. iloveyou

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.

EFF’s STARTTLS Everywhere Project

As a sort of sequel to its highly successful HTTPS Everywhere campaign, the Electronic Frontier Foundation has initiated a STARTTLS Everywhere project to improve email security.

Unfortunately, this is likely to prove a bit more challenging than HTTPS Everywhere because of issues with STARTTLS,

Although many mailservers enable STARTTLS, most still do not validate certificates. Without certificate validation, an active attacker on the network can read and even modify emails sent through your supposedly “secure” connection. Since it’s not common practice to validate certificates, there’s often little incentive to present valid certificates in the first place. A brief experiment on Censys shows that about half of the mailservers that support STARTTLS use self-signed certificates.

. . .

When two mailservers support STARTTLS, their insecure connection is opportunistically upgraded to a secure one. In order to make that upgrade, the two mailservers ask each other if they support STARTTLS. Since this initial negotiation is unencrypted, network attackers can alter these messages to make it seem like neither server supports STARTTLS, causing any emails to be sent unencrypted. ISPs in the U.S. and abroad have been caught doing exactly this, and in 2014, several researchers found that encryption on outbound email from several countries were being regularly stripped.

But you have to start somewhere, and the EFF should be commended for going beyond simply issuing policy prescriptions and recommendations, and doing a lot of the heavy lifting to improve end user security.

Nick Kralevich on Android Security and Safety By Design Principles

Nick Kalevich, the Android Platform Security Engineering Lead, gave a presentation at Black Hat over the summer at which he addressed hardening Android. While I have a lot of concerns about Android security, I did like Kalevich’s statement early in his talk about his team’s efforts to make things safe by design.

“When you make the safest thing to do the easiest thing to do, people will do it.”

Accepting Variations of a User’s Password on Login Attempts

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:

  1. The original password – password
  2. The original password typed as if caps lock was enabled – PASSWORD
  3. The original password with the first character automatically capitalized, which is still a “feature” on some mobile phones – Password
  4. 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.

Google’s Rank Hypocrisy on Security Patches

Mateusz Jerczyk of Google Project Zero calls out Microsoft for implementing some security patches in Windows 10, but not Windows 7 and 8.1.

The aim of this blog post was to illustrate that security-relevant differences in concurrently supported branches of a single product may be used by malicious actors to pinpoint significant weaknesses or just regular bugs in the more dated versions of said software. Not only does it leave some customers exposed to attacks, but it also visibly reveals what the attack vectors are, which works directly against user security. This is especially true for bug classes with obvious fixes, such as kernel memory disclosure and the added memset calls. The “binary diffing” process discussed in this post was in fact pseudocode-level diffing that didn’t require much low-level expertise or knowledge of the operating system internals. It could have been easily used by non-advanced attackers to identify the three mentioned vulnerabilities (CVE-2017-8680, CVE-2017-8684, CVE-2017-8685) with very little effort. We hope that these were some of the very few instances of such “low hanging fruit” being accessible to researchers through diffing, and we encourage software vendors to make sure of it by applying security improvements consistently across all supported versions of their software.

On the one hand, he’s correct. Microsoft is leaving users of Windows 7/8.1 exposed to potential security risks by not patching those OSes, and they should be “encourage[d] . . .to make sure of it by applying security improvements across all supported versions of their software.”

On the other hand, it’s a bit rich of Google to be lecturing Microsoft for not patching older OSes. Take Windows 7. That OS was released on July 22, 2009 and mainstream support for it ended on January 13, 2015. Microsoft is committed to providing extended support, however, through January 14, 2020.

So Google is unhappy that 8 years after releasing Windows 7 that Microsoft failed to implement a security patch for a known vulnerability. Fair enough.

On July 9, 2012, Google released Android 4.1 Jelly Bean. A major vulnerability in Android 4.1 was discovered in early 2015. In January 2015, Google publicly announced that it would not develop a security patch for this bug for Android 4.1. It did graciously allow that if someone else wanted to develop a security patch for the 2-and-a-half year old OS that it might be willing to incorporate those into Android 4.1.

Unlike Microsoft, Google can’t even be bothered to publish formal end-of-life dates for its software. The only policy it has in place is related to its own Nexus and Pixel devices, and states that such devices will receive “security patches for at least 3 years from when the device first became available on the Google Store, or at least 18 months from when the Google Store last sold the device.”

Compared to Google, Microsoft is a paragon of virtue when it comes to supporting its customers on aging OSes.