this is a really smart idea - proactive account protection. it would be great if users had two factor auth on everywhere and different passwords for every site, but that just isn't reality.
as the amount of breaches of random sites has gone up over the years, and the exposure of poorly stored creds from those other sites too often exposes that one password they are using everywhere and requires locking out that account. doing this in an automated way is really smart to save the time of an engineer going and grabbing the pastebin and invalidating creds. well done.
neat idea. Would be really cool if there was a way to provide this DB to other sites to enable similar proactive account protections, without having to build their own.
I proposed something like this a few weeks ago, but oddly it only gleaned down-votes <shrug>. If there are suggestions as to how this could work in a way that would be trusted and secure, I'd be interested in hearing them.
This is a great idea, but I'd be concerned that a bunch of the users would freak out when they were told that Facebook checked whether their current password has been compromised. Anyone know how they word the notice to the users to keep non-techie people from getting concerned that Facebook is looking at their passwords?
I could be wrong, but I imagine most non-techie people would assume (incorrectly) that Facebook has their plaintext passwords anyway, and that that's the mechanism by which their passwords are verified at login time. I don't feel like the concept of a salted hash is familiar to most people. As a consequence, I don't think people would actually find this especially concerning.
Seconded. With a small amount of experience over a long period of time dealing with customer support, my observation is that most people assume passwords are stored in plain-text, and don't even consider an alternative. At my current place of employment, we frequently get people phoning up, asking for their password; some seem a bit put-out when we explain we cannot provide it.
As people who know more about this, it is our responsibility to ensure those who know little, and care even less, don't have to worry about it. On the surface, this initiative by Facebook is an excellent example.
Very cool! https://haveibeenpwned.com/ added a similar feature recently, which anyone can use to get notifications if their email appears in a paste or DB leak.
2. After the data has been downloaded and parsed, an automated system checks each one of them against the Facebook internal databases to see if any of the email addresses and hashed passwords match valid login information on Facebook. We hash each password using our _internal password hashing algorithm_ and the unique salt for that person. Since Facebook stores passwords securely as hashes, we can't simply compare a password directly to the database. We need to hash it first and compare the hashes.
This seems to imply Facebook is rolling their own cryptography...
Its also very self-serving of them to recommend Facebook Login without even mentioning OpenID. Facebook Login in no way improves the security of your Facebook account, in fact I'd argue its likely to do the opposite due to phishing etc. It seems pretty transparent they're pushing an agenda in the guise of security advise, here.
Ever since my College Operating System's class, I've heard this line misunderstood time and time again. The real security principle here is "Principle of Least Privilege", not "Security through Obscurity". Facebook (I hope) isn't relying on some horrible security system to protect their users in the hope that no one guesses what it is. More likely, they are just hiding information that unprivileged users don't need to know. Maybe they rolled their own, maybe they are using someone else's technology, but they certainly have no obligation to their users to spell out exactly how they handle their logins.
Security works best when it is like an onion - layered.
Tweaking a password hashing algorithm (for example, changing the initialization constant in bcrypt) does not hurt security, and means that the attacker will not have sufficient information to crack the passwords with just a database dump, and even if they have everything a work factor should still deter cracking. Using md5 with the output xored against a constant would not, however, do much good.
17 comments
[ 3.4 ms ] story [ 30.4 ms ] threadas the amount of breaches of random sites has gone up over the years, and the exposure of poorly stored creds from those other sites too often exposes that one password they are using everywhere and requires locking out that account. doing this in an automated way is really smart to save the time of an engineer going and grabbing the pastebin and invalidating creds. well done.
As people who know more about this, it is our responsibility to ensure those who know little, and care even less, don't have to worry about it. On the surface, this initiative by Facebook is an excellent example.
2. After the data has been downloaded and parsed, an automated system checks each one of them against the Facebook internal databases to see if any of the email addresses and hashed passwords match valid login information on Facebook. We hash each password using our _internal password hashing algorithm_ and the unique salt for that person. Since Facebook stores passwords securely as hashes, we can't simply compare a password directly to the database. We need to hash it first and compare the hashes.
This seems to imply Facebook is rolling their own cryptography...
Its also very self-serving of them to recommend Facebook Login without even mentioning OpenID. Facebook Login in no way improves the security of your Facebook account, in fact I'd argue its likely to do the opposite due to phishing etc. It seems pretty transparent they're pushing an agenda in the guise of security advise, here.
Tweaking a password hashing algorithm (for example, changing the initialization constant in bcrypt) does not hurt security, and means that the attacker will not have sufficient information to crack the passwords with just a database dump, and even if they have everything a work factor should still deter cracking. Using md5 with the output xored against a constant would not, however, do much good.