As Naked Security reader James pointed out to us, this one comes from SourceForge, a popular online repository for software projects.
The good news this time is that SourceForge’s reset is a proactive measure, not a reactive one.
(The bad news is that SourceForge’s official announcement is sadly lacking in detail, which seems like a missed opportunity for education and encouragement about good security practices.)
As the company itself writes on its official blog:
To make sure we’re following current best practices for security, we've made some changes to how we're storing user passwords. As a result, the next time you go to login to your SourceForge.net account, you will be prompted to change your password. Once this is done, your password will be stored more securely. We recommend that you do this at your earliest convenience by visiting the SourceForge website and logging in.
If you’ve read our guidelines on how to store passwords safely, you’ll know that, in fact, you shouldn’t really store passwords at all.
One way to deal with passwords is to store a one-way cryptographic hash of each user’s password – a “fingerprint,” if you like, computed using an algorithm that can churn forwards from the password to the hash, but can’t be run in reverse to go from hash to password.
The idea is that you never need to store the password for later: when the user logs in, you keep the password in memory briefly, churn it through the hashing algorithm, test it against the hash you stored instead, and then obliterate it from memory.
If the computed hash and the stored hash match (and if we assume the hashing algorithm is cryptographically sound, so a crook can’t find some alternative password with the same hash), you can be as good as certain that the user must have fronted up with the right password, even though you never kept, and never will keep, a copy of it.
Now, even if crooks steal your password data, they can’t extract any passwords from it.
They have to use trial and error.
That’s because the only way to use the hash is forwards, so the crooks need to:
- Take the next candidate password from a giant list.
- Compute the hash of that password.
- See if that hash appears anywhere in your database.
- GOTO 1.
There’s no shortcut.
But there are speedups, for example by using a network of computers and splitting the password list amongst them (a botnet comes in handy here), or by building special computers devoted to calculating password hashes super-fast.
→ Because Bitcoin mining is also based on the rapid and repetitive calculation of hashes, specifically SHA256 hashes, speciality Bitcoiners’ hardware can often be used for password cracking instead.
The harder it is to calculate and test each password hash, the longer it takes for the crooks to get anything useful if they steal your data, and the safer we all are.
But you need to strike a balance, so that verifying one password isn’t so slow that users get annoyed logging in, yet isn’t so fast that crooks can plough through trillions of passwords per second.
→ If the crooks have their own offline copy of your database, rate limiting protection (like an ATM that eats your card after three incorrect tries) doesn’t apply. They get to choose their own hardware and software to run the hash-cracking loop shown above.
Attacks, as the adage goes, only ever get faster, so you occasionally need to adjust the computational complexity of your password hashing algorithm.
That’s what SourceForge seems to be doing here.
Of course, you only can re-hash users’ passwords with a stronger algorithm when they next log in, because that’s the only time you get a copy of the actual password in memory.
In theory, if you do this re-hashing before your current crackability factor becomes too easy, you don’t need to force users to change their passwords – you can simply re-hash the old ones, on the assumption that they haven’t yet been cracked.
SourceForge isn’t doing that: it’s forcing a password reset at the same time.
Sadly, it isn’t saying what password storage system it’s changing from, or to.
That means we don’t know whether SourceForge is forcing a reset merely because it seems like a good idea, or because it privately suspects that the old storage method is already dangerously out of date in crackability terms.
We’ll be positive about this, and assume the reason is mostly former, with just a touch of the latter.
After all, a staged reset (where some users have logged in and had their password hashes recalculated, but others haven’t) means that you have to support both the old system and the new one for some time.
So SourceForge’s approach will let them quickly retire the old password storage system altogether, and make a fresh start.
Can’t really complain about that.