Formspring springs a leak: 28 MILLION passwords reset after raid Formspring has told its 28 million users to change their passwords following the discovery of a security breach. A sample of 420,000 password hashes for the question-and-answer website have been posted online, sparking concerns that the entire user base might have been exposed. In response, Formspring disabled users' passwords …
In a completely proper environment, development should NEVER be externally accessible. Development is on an internal network, best isolated from the work network as well as testing and production. When development is done it gets moved to the test server, which is fully identical to and has the same security requirements as the production server. Final testing is done and then the tested platform is moved to the production server (or test server is promoted to prod and prod demoted to test depending on internal practices).
In that environment, it may be acceptable to use a copy of the live database for development, pursuant to other requirements like protecting personal info. I can see the use for a copy of the live database, (nothing is ever foolproof because fools are so ingenious OR your typical developer would never think of doing something that stupid with the configuration of their testing data), but it certainly entails risk and proper precautions need to be taken.
One of my all time favourite examples of the pitfalls in blurring the lines between live and dev/test environments.
A new system was built and went into test. During testing, data was ported from the shonky old system and enhanced with other data from a variety of sources, including a shedload of manual entry and correction, as much of what was done previously was manual work using paper records. Much testing was then performed, culminating in effectively live running for some two months and all was deemed well. The end result was a test server that had everything required in production, so a few corners were cut and that server went into production.
Then the project was closed. As part of the closure process, the IT lads decommissioned the machine they had on their books as the test server assigned to the project......Oops. Now what's the other big difference between test and production? Ah yes, that'll be the fact that production servers are backed up regularly.........Double Oops......
But who the hell cares about serious security on a website like this? It doesn't contain much, if any, private information, its not a bank account FFS, nor is it any site where people will implicitly trust things that you say. The problem comes if a user had used the same password on more important sites and accounts.
In any case, it wasn't that the passwords weren't properly encrypted; it was that their devs were idiots and left a dev server connected to the internet and connected to their Production database. So they really should be upgrading their firewall and/or employees.
I've never seen what I consider sufficient documentation of that claim. Yes, we keep getting reports about people using the same passwords in different hacked databases, and especially common passwords like 'password' but never from sensitive databases, only databases people don't care about.
But who the hell cares about serious security on a website like this?
Overenigineering has saved these guys' bacon. Simply following best practise instead of the far more common "it's good enough" approach also has benefits later on as you're building on solid fundamentals. So thumbs up to them. They did a hell of a lot better than LinkedIn, who SHOULD have cared.
If you do it properly you have a per-user salt in the database and a site-wide salt in a configuration file. That way even if someone compromises the database (as happens so often) then the hashes are immune to any affordable attack. They'd need access to the filesystem as well to make it feasible.
Hard to say since it was a dev server and not a prod server. Dev servers usually have fairly light security because they are supposed to be isolated from real world connections. So if the bad guys had access to the hashed password list on the dev server, there's a fair chance they also had access to the salt hashes as well. Of course since the report doesn't go into those details, it's all speculation. The point in favor of your contention is that the bad guys posted the salted list, not a decrypted list. If they had the hashes you'd think they'd go for the full lulz and post the decrypted list.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
