It was smart of Facebook to look for reused passwords.
Troy wondered if there might be a security risk to announcing having found these matches (I suppose the reasoning is that if passwords are reused once, they are probably reused more than once, and so looking for such notices might help crackers track down easily compromised accounts), but decides there is not. Given the low-key way FB have gone about this, I guess this is right, and maybe this should be best practice for future password leaks. I wonder if anyone else has done this?
> I work at Facebook on the security team that helped protect the accounts affected by the Adobe breach. Brian’s comment above is essentially spot on. We used the plaintext passwords that had already been worked out by researchers. We took those recovered plaintext passwords and ran them through the same code that we use to check your password at login time.
> Like Brian’s story indicates, we’re proactive about finding sources of compromised passwords on the Internet. Through practice, we’ve become more efficient and effective at protecting accounts with credentials that have been leaked, and we use an automated process for securing those accounts.
I don't have the resources of a Facebook, but I'd pay a few hundred bucks a year for a HTTPS secured REST API which let me post an email address and receive a list of candidate passwords. Bonus for a callback if someone I've queried gets added. The service would maintain that list in a fashion similar to whitehat security researchers.
Use case is to implement the FB-style security escalation for high-value accounts at my businesses, without requiring an on-call security team. If a dentist loses their client database because they reused the password on a PHPBB somewhere I'm likely in for a lot of headaches even if eventually found to not be at fault.
The app part is trivial, the hard part would be maintaining good up to date datasets to make this actuallly useful. You'd also need quite a few more costumers than one patio11 to make it worth your while, and ironically, the need for this service in the first place suggests the potential market is still small.
I.e. lots of organizations don't quite realize they have a need for this and would have a hard time understanding why its useful.
Hey, thanks for pointing that out, that's the second time I've heard that recently. I think Ghoetery is getting a little over-excited and hiding the parent element containing Disqus which also contains the body of the post. I'm going to take a look at how to rejig the markup so that this doesn't happen in future.
It's a stupid interaction with Disqus. I don't think it's the site's (troyhunt.com) fault because the text of the article is all in the original HTML of the page. It is Ghostery and the way it blocks Disqus that causes the article to vanish.
Err, we've got a bug in Ghostery 5.0 for Disqus specifically that will be fixed in 5.1. Its related to click-2-play, so you may either disable it in Ghostery advanced options, or unblcok disqus on the site.
I kept using ghostery because I didn't know of any alternative and sometimes I can't install adsuck. (which is is better than a huge hosts file. An oversized hosts file can have a negative impact on DNS and overall network responsiveness).
Try using Readability. Even if ghostery blocks the content after it loads, Readability will just format it and show it to you, without sending data to Disqus et al.
0. Password hints, the horror. As a user, the wisest thing is to just put something misleading and use good password hygiene.
1. This reminds me of a funny thing I did at big name university that shall remain nameless. On the CS network which used NIS, I ran getent passwd as a regular user and received everyone's hashed passwords! Then, I piped that through john the ripper.... Say hello to 50 user's passwords in 30 seconds with nothing more than the standard English dictionary. (In an era just before shmoo, et. al. rainbowtables.). Dept chair, ~20 profs and some students. Drop a cron to start xeyes every 30 minutes anyone? }:)
How is Facebook getting the plaintext passwords to compare to their hashed user passwords? Since the passwords are 3DES encrypted, only adobe should be able to do that.
They could just be using email addresses, but that seems rather blunt.
I'm not a huge fan of Facebook, but what they're doing does seem like an excellent idea.
The passwords were all encrypted with the same key, and ECB mode still leaks some patterns. Jeremi Gosney of Stricture Consulting Group was "fairly confident" of his decoding of many of the passwords. http://www.zdnet.com/just-how-bad-are-the-top-100-passwords-...
I believe the question was more of how does facebook know it was the same password? My guess is this was a "lazy" calculation. That is, they had to get their users to reenter their password so they could check it then. (Make sense?)
To be more precise, Facebook knows hash(random_salt, facebook_password), and could do a check on the actual facebook_password when a user logs in, but I assume that it's not stored. Everyone knows encrypt(key, adobe_password), since that was what was leaked, and presumably adobe still has the key, so they know adobe_password.
Facebook wants to determine if facebook_password == adobe_password. Without the key, that's impossible. And I think 112 bit keys as provided by 3DES are still secure, even considering an adversary with the resources of Facebook.
A lot of the articles analyzing the adobe passwords seem to be comparing known-common passwords, passwords hints, and the insecurities of ECB-mode, which doesn't really scale. It seems like it would be better for facebook to just have a blacklist of common passwords (123456, password, etc), although then I suppose they don't get credit for pro-actively responding to a password leak (note: I'm not claiming that's why they're doing it - it seems like a good response, and I'm genuinely curious how they're doing it).
Edit: I just thought of way they could do it. Generate a histogram over the first 8 bytes of each encrypted password. Pick a threshold (e.g. 2, or 10, but you'd have to look at the data to get a good number) above which the password is considered "common" and therefore insecure. Go through the list of email addresses in the adobe dump that have a "common" password, and if there's a facebook account with that email address force a password reset. That seems like it would work fairly well, and doesn't require any knowledge of the plaintext passwords.
They said in the article, they took the plaintext from the Adobe leak and hashed it using their own login algorithm, then compared hashes. Edit: wait, must have been a different article. Oh well, I read it somewhere :)
Ah, that makes a ton of sense. I was thinking in the case of if a hashed database of passwords got leaked. If you know the scheme, you could do this sort of comparison at a login. But, yeah, overly complicated for this scenario, I believe.
Great insight/writeup but the last bit gets to me:
Ultimately, password hints are evil and they add nothing to an online system that can’t be achieved with a secure password reset feature.
It's a classic case of someone criticizing one important feature without suggesting viable alternatives. He might as well have said,
Gasoline engines are evil and they add nothing to a world that can't be achieved with a more efficient propellant.
Yeah, okay - but what's the more efficient propellant?!?!
Password hints aren't "evil" just because (a) Adobe happened to store theirs in plain text, and (b) some users do use seriously identifying information in theirs. Password hints make it fast and easy for an actual user who genuinely needs to reset their password to be able to do so quickly and efficiently. What's the secure password reset feature that Troy alludes to? I missed it.
I think the point about password hints is that, like secret questions, they typically reduce the security of the account when used by actual users. Alternative approaches protect users from themselves.
Oh, pish posh. You could've just as easily said, "The viable alternative is to make password resets secure" and said the same thing. It's doublespeak. It's basically an easy way to say, "There are a lot of different things you can do but I don't feel like taking the time to list each of the options right now."
> What's the secure password reset feature that Troy alludes to?
I've seen a few concepts. One I liked was the selection of two or three images from a gallery. If the user correctly identified the ones he had selected at sign-up then a new password was sent to the registered e-mail address.
But any password reset process should ensure that it never links back to the original password. Reset, not recover.
> Password hints are an absolutely ridiculous security measure.
Password hints have multiple uses. For identity management and verification systems, it's used as an additional identity check after the password if the host seems to have changed. For password recovery, it's a "need to know" factor you have to pass before you get to the "need to have" of e-mail account access. Since it's trivial to bruteforce, multiple hints of different categories are usually deployed.
In the real world, hackers compromise accounts by finding out the personal details they need to subvert password-recovery steps. Find the last four of the social, their birth date, address, and phone number, and you can basically hijack any bank, telephone, utility or government account a person has. Password hints are (when properly implemented) more secure because they can leverage other access methods.
Did they need to keep the hint plaintext? No; they can hash it just like any other password. But as the complexity requirement of the hint is much lower than that of passwords, it should be required to use another factor (such as an e-mailed confirmation code, SMS, or many more hints or sensitive information) to allow the hint to succeed.
I think you've mixed up password hints with security questions.
You seem to be talking about stuff of the form, "What is my mother's maiden name?"
A password hint is exactly what it says: a hint for what your password was, to help you avoid forgetting it. If your password is "lassie", then your password hint might be something like, "That dog you like from TV." The problem, of course, is that just about any hint that helps you remember your password also helps an attacker guess it.
Troy wondered if there might be a security risk to announcing having found these matches (I suppose the reasoning is that if passwords are reused once, they are probably reused more than once, and so looking for such notices might help crackers track down easily compromised accounts), but decides there is not. Given the low-key way FB have gone about this, I guess this is right, and maybe this should be best practice for future password leaks. I wonder if anyone else has done this?
For convenience, the announcement by Chris Long, of FB (from his comment on Brian Krebs' blog, at http://krebsonsecurity.com/2013/11/facebook-warns-users-afte...):
> I work at Facebook on the security team that helped protect the accounts affected by the Adobe breach. Brian’s comment above is essentially spot on. We used the plaintext passwords that had already been worked out by researchers. We took those recovered plaintext passwords and ran them through the same code that we use to check your password at login time.
> Like Brian’s story indicates, we’re proactive about finding sources of compromised passwords on the Internet. Through practice, we’ve become more efficient and effective at protecting accounts with credentials that have been leaked, and we use an automated process for securing those accounts.