21 Mar 19 Facebook Stored Hundreds of Millions of User Passwords in Plain Text for Years Hundreds of millions of Facebook users had their account passwords stored in plain text and searchable by thousands of Facebook employees — in some cases going back to 2012, KrebsOnSecurity has learned. Facebook says an ongoing investigation has so far found no indication that employees have abused access to this data. Read more in the full article here.
It’s Time to Break Up Facebook msn.com Facebook co-founder urges FTC to break up the company --- Chris Hughes wrote that CEO Mark Zuckerberg has "unchecked power."
This is actually normal for application developers and programmer even with Google and Apple developers. We actually get a sample size of the database from production environment and dump it to the development and testing environment and in plaintext to speed up the development. The news site only exaggerated it together with Krebsosecurity. The key here is knowing those employees that have access to the data and logging their activity. Making sure they cannot get the data out of the system. No personal storage devices and no connection outside.
^^ I’m appalled you work with a company that does that. The approved practice is to ‘obfuscate’ data (replace all identifiable data with something else) during export if needed to simulate in other environments. If it can’t be done the other option is to generate dummy data to similar volume in production but never allow anyone even customer service, and especially developers access to private customer data like passwords.
That is actually the best practice to obfuscate the data but that not always applied. If the development is very fast pace which is majority of clients demand it is seldom applied. You know it takes time to generate and test if your obfuscated data is going to work with the environment. Most of the time obfuscating requires the data to be tested unlike when dump is exact copies of production. When you have monthly releases and time/budget isn't on your side, what usually happens is you remove some steps on your development. Just delete all dump data after finishing the release. Good if you can always apply the best practices and delivering clients demand on time. If you are always pressured to lower the time of development and doesn't want to do unpaid overtime, you have no choice to sacrifice some best practices.
^ Let's be clear. Are you suggesting it is ok to use personally identifiable data making it accessible to developers and engineers in order to meet development timelines/demands? What company do you work for? So i know which services to avoid.
Noted on your, or your company’s, priorities. If time was your concern you only need to do the right approach. You’ll find out it doesn’t/wont take a lot of time...but I am not to judge as I don’t know the tools you’ve tried.
Mm...is such practice part of the TOS of the service? Are the users aware? Spill it out so I, too, can avoid that service.
Ditto. And if he hasn’t even read the TOS they give to clients I’m sure the justifications he pointed out will clear them of any liabilities...
Of course it is not okay but a lot of top IT outsourcing company does this just to keep the client. Here's more you won't even know those data are same with production unless you're a curious developer. Heck management doesn't even knows that they are production data. We just received it from another outsource company. We don't have the luxury of time to verify it that it is not from production environment and we assumed the data is already sanitize. As for the company, just think of the top 3 IT company. On paper we follow the best practices. Before audit we just cleaned our tracks.
There is one time when I tried to ask budget from managers to apply best practices in the development and defended that we need this but they say there is no budget for that and do that on your free time. Don't fix when it ain't broke. Test environments are usually scaled down version of the production and way less powerful. Imagine the time saved when you disable encryption of passwords during testing and development.
Hint top 3 IT outsourcing company. I only hopped to those. They prefer global clients. TOS is usually confidential and developers rarely have access to read it. I don't know if management have the luxury of time to discuss the details of TOS to developers. Users of the test data are usually not aware that they are dump from production. Dump test data from production are usually the best. They cover all scenarios unlike generated test data. Generated test data will pass the testing but when deployed in production it usually fails. Unless you're that good generating test data that will covers all scenarios and you know exactly what the database in production contains.
^^ Well at least you should now be aware of the risks you’re getting into - and it isn’t acceptable practice. I’ve worked in bigger companies than you...there’s always a required security training to teach you these things - this exact same thing we talk about.
Mm....well I just hope that your company’s clients does not include local banks. I shudder to think of what such practice can do to what we take for granted: online banking security are extremely secure and users’ credentials are not stored in textfile.....parang ma pag practisan ng developers of the apps (for the banks).
Most developers are aware and we cover our tracks perfectly especially before audit. Security training are good but how much hours are you willing to burn on it. Developers are more likely use those ours in debugging and coding. Let say the training is for one week. You compress it to one hour to save time and use it in developing.
Local banks don't outsource development here. Usually outside the country. Bank are worst actually. Sending test data thru email not password protected. Especially old employees. But there environment is usually contained on premise. So you can't actually export data outside the environment.
No matter how much CYA you do, bad practice gets exposed. I’ve worked my way up from a grunt to overseeing these risks (developer to a boss). You won’t be the last to try to tell bosses nothing bad will happen. Know how to prevent these security breaches? Never do these ‘shortcut’ practices. At the end of the day you should realize you’re on the other group, if not wrong group, to think this is normal. I hope we’ve never dealt with your company in any of our projects.
