Feeds

back to article 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 …

COMMENTS

This topic is closed for new posts.
Anonymous Coward

Crap.

I only signed up briefly, discovered how crap Formspring was, nothing like what was promoted, asked for my account to be deleted. Seems they never bothered...

0
0
Silver badge
Facepalm

Development and live should never be connected

1
0
Anonymous Coward

awwwww....

...but it's so convenient!!! And so much fun, knowing one wrong move will cause chaos! Adrenaline is good.

3
0

"Development and live should never be connected"

Reading between the lines it looks like they might have dumped a copy of the live database onto a development server - I've seen it done.

0
0
Anonymous Coward

I don't know, it sounds like they might have had a development server with web access that used the production DB server

Terrible security managment.

0
0
Anonymous Coward

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......

0
0
Silver badge

Re: Development and live should never be connected

You forgot the WTF?!?!?!?!!! title.

I are only helpdesk and even I knowed that.

0
0
Silver badge

@Lord Voldemortgage

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.

0
0
Bronze badge

Upgrading from salted SHA256?

Really? That sounds pretty paranoid. Those hashes are only going to be voulnerable to dictionary attacks on any weak passwords that people used. But weak passwords are perfectly attackable anyway, without having access to the hashed passwords.

0
2
Anonymous Coward

Re: Upgrading from salted SHA256?

But online dictionary attacks are noisy and can be tracked or rate limited, once you have the hash you are only limited by your hardware.

0
0
Bronze badge
FAIL

Re: Upgrading from salted SHA256?

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.

1
0
Facepalm

Re: Upgrading from salted SHA256?

"The problem comes if a user had used the same password on more important sites and accounts."

...which is about 99% of users; and thus the real problem with these hacks.

0
1
Silver badge

Re: which is about 99% of users

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.

0
0
Gold badge

Re: but who the hell cares

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.

0
0

Site & User salts

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.

0
0
Silver badge

Re: Site & User salts

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.

0
0

Re: Site & User salts

"there's a fair chance they also had access to the salt hashes as well" - exactly. Which is why you should have an *additional* sitewide salt that is not in the database. See the other password leak story from today.

0
0
Coat

Wayhey!

Is the salt good enough to go on my chips?

1
1

A first?

Is this the first big password leak that was actually hashed somewhat properly?

0
0
This topic is closed for new posts.