24 ms·
Facebook stored millions of Instagram passwords in plain text
- wowWhoCanEven 8y agoDude. This is fucking. Stupid.
- hprotagonist 8y agoNew rule: whenever facebook announces a breach and scale of effect, just square the scale of effect right off the bat. You'll probably still be a little low, but you'll be a lot closer to the number in the second (or third or fourth) press release.
- ryanlol 8y agoThis isn't a breach.
- deleted 8y ago[deleted]
- mgraczyk 8y ago1e6^2 = 1e12, trillions of passwords? ...
- zephyrnh 8y ago"The security lapse was first reported last month, but at the time, Facebook said it only happened to “tens of thousands of Instagram users,” whereas the number is now being revised up to “millions.” The issue also affected “hundreds of millions of Facebook Lite users” and “tens of millions of other Facebook users.”"
- sreyaNotfilc 8y agoI wonder how much of this is the responsibility on how Instagram was built. Like Instagram may have been built so fast that those things never were accounted for. Not that I'm giving Facebook excuses, but maybe something was overlooked before acquisition. Then again, Facebook is breaching security protocols left and right.
- lightgreen 8y ago1e12 square passwords.
- hmate9 8y ago"...various errors seem to have caused Facebook’s systems to log some passwords in plain text since as early as 2012." 1) As a software engineer I can't imagine how such errors could possibly have entered production code accidentally, especially after code review. If precise details of these errors are released I am open to have my mind changed. 2) Even if it did, I can't see how it would take facebook's tens of thousands of engineers 7 years to find this "bug".
- verelo 8y ago"1) As a software engineer I can't imagine how such errors could possibly have entered production code accidentally" Like i'd love to agree, but frankly, i'm not surprised. I feel like I've seen crazier things happen on production environments...
- eatmyass 8y ago>1) As a software engineer I can't imagine how such errors could possibly have entered production code accidentally, especially after code review. If precise details of these errors are released I am open to have my mind changed. You can't imagine? Really? Error occurs, request that caused error gets logged.
- throwaway2016a 8y agoNot too far fetch... For example, I've seen people put in place logging systems that logged the whole request body and then someone changed a field name and all the sudden as a side effect the code that sanitizes the body to remove the sensitive information no longer does it's job.
- hunter23 8y agoObviously you shouldn't log passwords, but what kind of security mechanism have been effective to catch this error? One thing I can think of is have some production test accounts that are regularly used and have a unique password. Then have an automated task that periodically greps the production logs for the password to see if you have a log leak. Any other approaches?
- human20190310 8y agoYou could grep production logs and other data stores for commonly used passwords like "password123".
- UncleMeat 8y agoBetter hope data isn't encoded in some other format. Better hope you have na exhaustive list of all the production logs.
- kevin_thibedeau 8y agoMore dependable would be tests that inject unique privileged information and then check for that appearing anywhere it shouldn't.
- londons_explore 8y agoYou need to do both. Real users will find routes through your app that automated tests never consider. For example, what if the users 1-year login cookie expires as they're on step 3 of a 4 step "change your avatar" process. That's highly unlikely, and probably not even tested. Yet it might well work (due to good modular design), but also log inappropriate data.
- MartinCron 8y agoI actually really like that idea, constantly scanning logs for hyper-specific red flags. I might start doing this.
- 8y ago
- eridius 8y agoLiterally every single time Facebook announces something like this, they always announce low numbers and then repeatedly revise them upwards. Is there no penalty to them for basically lying to everyone in their initial announcement? Doing it once can be explained as they sincerely thought their original number was correct, but they have a history of doing this and there's no chance I believe now that they aren't doing this on purpose.
- UncleMeat 8y agoThis seems like it would happen with most breaches. You learn about an issue, do some investigation, get an estimate, then inform the public. If Facebook had waited for months to complete the investigation and get these numbers, do you think people would have accepted that? Probably not. So they publish what they know when they think they've got it figured out. But probably this launches up a team that goes looking for other bad logging. Then a while later they find some more errors and the numbers are revised up. This seems expected.
- eridius 8y agoI can't think of any other company that has a history of downplaying breeches and then revising the numbers upwards. If you don't know how many people are impacted, you aren't supposed to just make up a number. At a bare minimum you'd say something like "We know 10k users are definitely impacted, and we estimate this could be as high as 5M" or whatever the appropriate ballpark is.
- kibibu 8y agoLinkedIn went from 6 million to 107 million...
- eridius 8y agoOuch. Is this a one-time thing, or do they have a history of that? What I was trying to say was that I can understand companies making this mistake once. Maybe even twice. But once a company has an established pattern of doing this, they lose the benefit of the doubt and we have to assume they're doing it deliberately. Even more-so if they do scummy things like try to bury their "it's 1000x worse" update with other high-profile news. Facebook has a long history of this kind of thing now, every single new privacy violation of theirs must be met with the expectation that it's actually 1000x worse than they say. I'm not aware of any other companies with a history of doing this multiple times.
- anarazel 8y agoAnd they announced it while they thought the attention was elsewhere (due to the Muller report release), and in an easy to miss manner (as an update to a blog post). Very trust inspiring.
- bhelkey 8y agoEdit: The following is correct but misleading. The Muller report was reported to be released before the Facebook security update. Facebook announced this before the Muller report was released. The Facebook security post was updated April 18, 2019 at 7AM PT [1]. The Muller report was released "Thursday morning, shortly after 11 am [EDT]" [2] [1] https://newsroom.fb.com/news/2019/03/keeping-passwords-secure/ https://newsroom.fb.com/news/2019/03/keeping-passwords-secur... [2] https://www.vox.com/2019/4/18/18411966/mueller-report-release-time-trump-russia-redactions https://www.vox.com/2019/4/18/18411966/mueller-report-releas... Disclosure: I work for a big tech company but not Facebook. All opinions are my own.
- k_sh 8y agoSure, but the Mueller report was widely reported[0][1][2] to be released Thursday morning days ago. [0]: https://deadline.com/2019/04/redacted-robert-mueller-report-coming-thursday-morning-donald-trump-bill-barr-russia-1202596040/ https://deadline.com/2019/04/redacted-robert-mueller-report-... [1]: https://www.washingtonpost.com/world/national-security/mueller-reports-release-is-expected-thursday-justice-dept-says/2019/04/15/dd44eb02-5f91-11e9-9412-daf3d2e67c6d_story.html https://www.washingtonpost.com/world/national-security/muell... [2]: https://www.cnbc.com/2019/04/15/mueller-report-expected-to-be-released-thursday-morning.html https://www.cnbc.com/2019/04/15/mueller-report-expected-to-b...
- bhelkey 8y agoI wasn't aware of this. I updated my comment to reflect this.
- anarazel 8y agoBarr's press conference was at 9.30 AM EDT, however.
- basetop 8y agoEarlier post of the exact same story. https://news.ycombinator.com/item?id=19693233 https://news.ycombinator.com/item?id=19693233
- johnsimer 8y agoI feel like this could be avoided by hashing the password on the client side as well before sending it to the server, no?
- blattimwind 8y agoYes, but while "storing passwords in plaintext is bad, mkay?" is accepted in the industry, "transmitting passwords to the server is bad, mkay?" is, in fact, not accepted. It is usually considered "best practice" to transmit passwords to the server, which is obviously wrong.
- Spooky23 8y agoI’d argue it is “best practice” to present credentials to an authentication server, and provide a token to the various user services to reduce the impact of things like over-logging.
- itslennysfault 8y agoThat doesn't work. If you hash on the client then the hash IS the "password" and is thus sensitive info that you'd need to hash again on the server and shouldn't be stored anywhere in plain text.
- kalleboo 8y agoWhile I agree with what you say, one could argue there is the additional element of protecting against user password reuse between sites. If the client-side hash is strong enough it means that your plaintext password leak becoming a hashed password leaks at least protects the user from reuse on other sites.
- eurleif 8y agoThat defeats the purpose of hashing. In your model, the hashed password is all an attacker needs to log in, so the hashed password essentially IS the password. Thus, when you store hashed passwords, you are doing the equivalent of storing plaintext passwords.
- xfitm3 8y agoIf you do layer 7 NSM/DPI then you're most likely logging passwords. The good news is this data typically has significantly stronger controls over access logs as it's collected for secops.
- wickrom 8y agoHow does Facebook, hiring some of the best engineers in the industry with the biggest bucks ends up in such a mess
- happppy 8y agomaybe they need passwords to login as user?
- jordache 8y agoeven if they want to emulate a user, they can do so without their password. Or if doing so in a simplistic way, they can login with said user's hashed password, instead of the original plaintext.
- jammygit 8y agoBut think of the whiteboard algorithms they can all put together in a pinch
- EastSmith 8y agoI am wondering why sending onetime login link to an email is still not a thing?
- sreyaNotfilc 8y agoOK, this is getting ridiculous. There is no best practices. You think a company worth Billions would have a standard of ethics. Afterall, that's what they interview on. Best Practices. Ethics. Doesn't Facebook have blogs on things like efficient servers, algorithms and such. They are obviously at the forefront of technology (or know about it). Why aren't they implementing these things? It seems to me that the more your company is worth, the less you get to bend rules, all to chase more money. HR an lawyers will take care of the rest.
- jordache 8y agoMaybe instead of quizzing obscure sort algorithms at interviews, they should have simple yes/no questions such as: Should you store plaintext password on the server side?