And *this* is why you properly salt your hashed passwords. I'm talking to you, LinkedIn, MySpace, etc etc.
Dropbox: Leaked DB of 68 million account passwords is real
A leaked database purported to contain login information for 68 million Dropbox accounts is the real deal. The cloud biz confirmed the authenticity of the records to The Register, with independent verification from IT security guru Troy Hunt. The archive, which is being shared online, contains Dropbox user IDs and hashed …
COMMENTS
-
-
Wednesday 31st August 2016 03:52 GMT Destroy All Monsters
But you then also have to go out and tell the world immeditately about the breach.
How LinkedIn’s password sloppiness hurts us all
Examining the breach, LinkedIn didn’t have very much of an insurance policy. It was employing raw SHA1 for password hashing, but perhaps even worse is the fact that the company never even attempted to cash in on it. Back in, 2012 they failed to identify and acknowledge the breach in a timely fashion, and when they eventually did, they apparently only forced a password reset for the accounts belonging to the initial 6.4 million hashes. The evidence suggests that the remaining 165 million accounts were allowed to use those same compromised passwords.
That’s not the way this should work. When you suspect a password database has been compromised, even just in part, you cash in on that insurance policy immediately by activating your incident response team and your public relations team. Companies ideally should notify the general public and users in an expedited manner, forcing a password reset for all users as soon as the breach is contained and the threat has been eradicated. By the time LinkedIn made a statement about the breach, by contrast, I already had 70 percent of the passwords cracked. Every moment LinkedIn hesitated was potentially devastating for its users. And for the love of god, do not try to downplay the incident by saying something stupid like “Most of the passwords on the list appear to remain hashed and hard to decode." Instead, companies should just acknowledge the plain and simple fact that if password hashes have been accessed, users are at real and measurable risk of account takeovers.
-
Wednesday 31st August 2016 12:52 GMT The Man Who Fell To Earth
local encryption
This is why, as Rob Joyce (head of NSA's Tailored Access Operations (TAO) hacking team) said at the Usenix’s Enigma conference in January 2016, you need to think twice before relying on a Cloud provider's security.
Use a wrapper like nCrypted Cloud to transparently locally encrypt/decrypt everything before it goes into your Dropbox/Google Drive/....
-
-
-
Wednesday 31st August 2016 11:59 GMT Ben Tasker
Re: Ummm
> I am also not sure the attacker "would need the salts". Generally they are right next byte to the hash, possibly after or before a separator...
Absolutely correct - with bcrypt the salt is stored within the "hash", along with the cost used and the resulting cipher text. The cost and salt get split out of the stored string when testing a submitted password.
-
-
Wednesday 31st August 2016 10:38 GMT Anonymous Coward
4 years?
I got a mail at the weekend which mentions 2012, but it had no explanation for the delay in sending it.
No news reports seem to have any kind of justification either.
Given that bashing a password database these days can be measured in 'attempts per millisecond,' why has it taken more than 126 billion milliseconds for it to come out?
This is one of the areas where government legislation would be welcome.
- Minimum requirements for password security and data storage, heavy fines for non-compliance.
- Breaches must be reported within hours, rather than days / weeks / years. Massive fines for non-compliance.
- No possibility of just claiming that their systems are safe in their advertising blurb - actual real audits should take place and evidence should be provided on a regular basis to ensure companies are keeping ahead.
I get that it's the way the world works, there will always be hacks and it will always be a challenge to stay ahead, but there is no justification for keeping quiet for so long.
-
Wednesday 31st August 2016 15:49 GMT Seajay#
Re: 4 years?
This is one of the areas where government legislation would be welcome.
Maybe, but I don't think legislating minimum security requirements is the way to go. That will lead to some services saying "Well we meet the government security standards because we're salting our hashes" and stopping there when actually there may be all sorts of application-specific side channels that are much bigger risks.
Equally, how about something like https://mailinator.com/? How would your legal security standards apply to something which was insecure by design?
What you could do I suppose would be to add a requirement to data protection laws that users be informed of any possible loss of their data. That would be genuinely useful and is tech independent so wouldn't immediately become out of date.
-
-
-
Wednesday 31st August 2016 12:02 GMT Ben Tasker
Re: Can someone explain
With bcrypt, the salt is stored in the "hash". The output of bcrypt is essentially a string containing the actual hash - in effect ${cost}${salt}${hash} - so if you've got the bcrypt "hash" you've got everything you need except the real password.
But that's fine, because a salt isn't intended to be secret, it's intended to make it more expensive for an attacker to try and bruteforce hashes
-
-
Wednesday 31st August 2016 12:58 GMT Rgl
What I don't get...
Like, how this is a LinkedIn breach when I'm not on LinkedIn, and according to haveibeenpwned my dropbox account is included in this. It looks more like a Dropbox employee was hacked on the basis of the LinkedIn breach, and that let the hackers far enough into Dropbox's systems in order to download the complete password file. Like the language Dropbox are using seems deliberately vague, as if they're avoiding saying something, that something being "we were hacked as a result of an employee getting hacked via the LinkedIn breach and using the same password for their corporate login". Am I wrong? Or how else have my account details gotten out there? Note, I'm using unique passwords for all important services. It just looks to me like they're trying to say the minimum possible about how complicit they are, yet cover their arses legally.
-
This post has been deleted by its author
-
-
-
Wednesday 31st August 2016 22:43 GMT gmhyman
password change doesn't help if someone's broken in
So - I changed my password, and all my various devices still had access to my dropbox data. Contacted support and got a rather condescending lecture about how their security system was based on "tokens" and not password. This is utter BS - yes, you keep a token (aka cookie) to store credentials, but any decent system can revoke credentials from the server - and that's exactly what should have happened. Bottom line - if the bad guys had already gotten into your dropbox data, they're still there even though you changed your password. It only helps on new connections to dropbox. You can, of course, manually "unlink" each device, but I'd wager a very small percentage of users even know about this. Besides - if I can unlink manually, why didn't dropbox do a full unlink when they forced me to change the password? Obviously they care far more about the "optics" than about real security.
-
Thursday 1st September 2016 17:27 GMT PaulR79
I wondered when this would happen
Like others I received an email telling me that my password hadn't changed in a while and that I should change it. The first thought I had was to look for news of a leak since that seems to be the only time I ever get prompts to 'update' my password. I did change my password but this just confirms what I thought.
-
Friday 2nd September 2016 03:16 GMT Anonymous Coward
woohoo!
haveibeenpwned.com makes me happy deep inside. Previously I had wondered if I'd deleted that LinkedIn account before the breach but now I know that it was definitely compromised. And knowing is half the battle! I must have deleted all the account management messages from that old mailbox because it was no help when I was still trying to find out when and whether etc.
So this time the only question was "did I screw up and reuse a password anywhere, ever" but checking an old Firefox profile shows that I did save the password on linkedin.com, and the password was one of several placeholders I use now and again when I really, really don't care. I guess I just never had much faith in LinkedIn's usefulness... anyway, I certainly reused it many times but always for inconsequential situations and it's stupidly vulnerable to a dictionary attack anyway. So, I don't care. At worst, I later used one of those memorable keyboard patterns and decided not to update the saved login in FF-- a potential unknown but I don't use those on web accounts since forever.
Thanks HIBP