Passwords for 32M Twitter accounts may have been hacked and leaked
techcrunch.com
techcrunch.com
The real source, not this redundant media crap that buried the lede...
No, let's not. First of all, leakedsource has already been submitted separately, but has fewer upvotes. Presumably people prefer the techcrunch version.
It's not really surprising, as leakedsource's article is poorly laid out. It doesn't even have a title (they've put "Preface" as a title, but that's the heading of the first section). Then there's the banner adverts at the top.
>The real source, not this redundant media crap that buried the lede...
The techcrunch article has responses from twitter and others, along with some analysis, so it's not "redundant media crap".
The title of the page is "LeakedSource Analysis of Twitter.com Leak". I know it's the title because it's in the title tags. The appearance of banner ads is a strange criticism when comparing to a techcrunch page, which is essentially one huge ad for other tech tabloid crap.
The techcrunch article is poorly written; it implies the data may not be genuine because some guy has not confirmed that twitter has been 'breached', while at other points seems to acknowledge the most likely source for this data is malware on users' computers. Which is it?
The statements from Twitter are boilerplate garbage, unworthy of being reproduced in whole or in part.
You're right about the adverts. It's more of a design thing than anything else. The site looks like it was designed in the 90s.
As for statements from twitter and others, they are very important, as they give credibility and background to the story. Most people here don't have time to do their own analysis and research on a story.
Is that site legit ?
Right, but therein lies the strength of bcrypt. You can set it so it will be several thousand per second, or several seconds per thousand. This comment seems a little like saying "I can run faster than a car, depending on how hard you press the accellertor."
Also, a few thousand hashes per second (and that's on a GPU, and bcrypt is decidedly GPU unfriendly due to memory allocation patterns) won't allow you to do much more than a dictionary / rule + dictionary attack, so in the short term you're only going to get weak passwords.
To me the risk with using bcrypt is DOS. If you have a high work factor, all an attacker has to do is to run a lot of logon (no need to be successful, they just need to relate to real users) to sink your servers.
Is there a way client side processing power could be leveraged to help calculate the final hash value so that the computational cost could be practically increased?
I'm aware that having the client calculate and send the final hash value by themselves is a bad idea though.
Password hashes, like bcrypt, PBKDF2 and scrypt, are massively slower. That doesn't mean they're uncrackable, it just means they are expensive to crack, so a strong password in a well implemented password hash will take a long time (and cost a lot of money) to crack, by which time the user has hopefully noticed and had time to change their password.
Argon2 looks really interesting, but it is still relatively new.
Last time I heard of scrypt, it was being used in Litecoin, a fork of bitcoin, because it was preventing GPU based crackers.
On what hardware?
So it doesn't matter on what hardware, if you want bcrypt to take 1 second on modern hardware (for any value of "modern"), you can.
The concept actually makes sense, but it kind of assumes that the strength of the security will be increased at the same rate of which technology progresses, which I don’t think will always be the case. This is especially true when you consider potential “bursts” in computation speed progression.
That being said, I’m not implying that I have a better idea. Running algorithms that take 30 seconds to execute isn’t going to work for logging into your Twitter account either.
Make it 15ms for an attacker and it becomes an hour per account just for the dictionary.
You also can't assume that all accounts are equally valueable. An attacker might very well prioritize some of them.
This doesn't render all of this useless but I think you shouldn't consider even best solutions out there to be anything else than a temporary barrier. It's a good one and you probably will have enough time to change your password after a leak but you really do need to change your password within a week or so.
But I think the parent's point was that this compute time only lets you check one password against one account. All you can do, after this compute time, is state that "'monkey' is/ is not the correct password for @iagooar's account".
Those results can't be used to check other accounts (because they're salted) so this approach doesn't really scale well at all. It might, for a huge adversary (state-scale) allow a single password to be cracked in a reasonable timeframe, iff it's relatively simple password.
An evildoer would use stolen credentials, stolen credit cards, or stolen hardware (botnets).
It's hard to get specific numbers about a trend that just changed. But the double every 18 months is now clearly wrong.
We've got a couple of approximately 27 months doubling, but that is past too. My bet is that we won't get a fixed number ever again.
So maybe that's the way for computers to become much faster, making everything around the CPU go faster. Integrate the RAM and the GPU on the chip. Superfast SSDs. Etc.
107 kHashes/second/machine for bcrypt in default settings (which probably many sites will use).
If they did indeed use a work factor of 5 then this analysis is pretty much meaningless for bcrypt. The default is 10 and I usually use 12 myself.
If you're doing salting properly (a unique CSPRNG-generated salt for every user) then 3600 attempts per hour really isn't enough to get anything except the lowest of low-hanging fruit.
Good password hashing functions have internal rate limits that reduce the likelihood of anyone being able to break the hashes easily because they will be expensive even when fully implemented in hardware.
For how long are they resilient it's another question but bcrypt is pretty good, it's quite slow, and is expensive to implement in ASIC/FPGA.
The rounds are a trade off between how long your users will wait to login and how strong the hashes will be. The current recommendation is between 8 and 12 depending where you look. The best practice is to just check on the system you are running, I usually aim for the number of rounds nearest a half a second.
A large percentage of passwords are on the top-10000 password list, and for such passwords it is easy to reverse the hash using brute force
Yes:
http://www.pxdojo.net/2015/08/what-i-learned-from-cracking-4...
Now, this assumes typical storage, that "leaking the password column" means leaking hashed password+salt. Without the salt, things would go slower - but it's sort of an artificial constraint - what you're talking about, is leaking the stuff the server needs to have to check a valid password. And that generally means the hash and the salt.
More generally, there's an upper bound on how difficult it can be made for the server to verify a password; conceptually this is: ((the amount of time a user is willing to wait to be logged in) - overhead) / (resources available on the server for checking the password)
Ok. You don't actually divide the time by the resources, but the point is that if you have 10.000 (valid) logins a minute, you probably can't dedicate 4 high-end GPUs on max throttle for 1 second to check every login attempt.
But an attacker might have those kind of resources. Which means, there's a very real practical limit to how hard it can be made to validate a password guess (a cracking attempt) -- and it will be some small fraction of the time your server takes to validate a login.
Which means that no "easy" passwords (eg: dictionary words) are ever "safe" passwords (safe against an off-line attack).
My guesstimate (mostly pulled out of thin air, and late night napkin "calculations") are that for any password to be "secure" it would need ~64 bits of entropy. Maybe that's a high estimate, given a solid work factor, but I don't think so.
The problem is, that 64 bits is actually quite a lot of information to memorize. In short: you'll likely only remember one or two such passwords. Use them to lock your password manager, and have machine generated random passwords for the rest (because what you don't want is to ever re-use passwords, as passwords are generally always susceptible to sniffing, shoulder-surfing, being filmed, keylogged or otherwise captured in plain text).
For a little more about some of my thoughts on generating passwords that are secure, friendly to current systems ("password rules"), friendly to humans (feasible to remember and type from memory without visual feedback), see these comments: https://news.ycombinator.com/item?id=11772700
(I keep coming back to this idea, but so far I've concluded that 64, 96 and 128 bits is rather a lot to type in, almost no matter how it's encoded. So I'm not sure how useful such a system will end up being. But maybe I'll finally just prototype it, and ask for help in testing it (the "security" part is intentionally trivial, but the usability part is the interesting bit -- will it actually help us in using secure, machine generated passwords, or will we still have trouble remembering them?)
There has to be a reference point, no?
If you accept the premise of a secure hash, then there's no predictable effect on the output when you change hash('mypass') to hash('onetimesalt' + 'mypass'). Knowing that the user's salt is 'onetimesalt' does not get the attacker any closer to figuring out which password was used with that salt. Therefore there is no harm to storing the salt unencrypted in the database.
The advantage of doing this is that an attacker can't just make a single hashing run against common passwords using a single serverwide salt - they actually have to check the password list using every single user's salt. So if you have a million users (caveat: and your attacker is just scanning them all rather than going after a specific user), you've increased the complexity of an attack by a factor of a million.
Each record should have a unique, random salt. You then store salt:hash(salt+password).
There are numerous guides on how to do this properly, for example https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet
The owasp link you provided explains the two goals of using a salt:
1) Not being able to tell two passwords are identical based on the resulting hash. The e-mail is unique per user, so even if a bunch of users have "password" as their password, the hashes will all be different. Yes, if a user changes their password from "password" to "password" then the hash remains the same, but this is a very minor problem.
2) Prevent rainbow attacks. The constant part of the salt is enough to demand a site-specific rainbow table, and the e-mail takes this even further to a site + e-mail combo. Thus rainbow attacks would only have value in targeted attacks against a known site constant & e-mail combo. Once a good table is complete, it won't matter if the user changes their password.
Using a unique random salt would solve these two issues, however they can also be solved by adding a simple timestamp of the password's initial hashing time to the salt.
Several implementations utilise a Salt + Papper (unique per user value and single per site value). A Pepper is particularly useful when it is NOT stored in the database (e.g. stored in an environmental variable or even code). That way if someone steals your database via SQL Injection or a database backup file, they'd have to break the Pepper to recover passwords.
Peppers only make sense when they're almost "free" to implement. A slow hashing scheme is the most important thing, then unique salting, and finally a pepper last (since a pepper adds the least security wise).
(I'm not arguing it's "too horrible", but I am saying that it's worse than other schemes that aren't significantly more burdensome.)
From Wikipedia, I see that Hurricane Carla hit Texas that day but that doesn't seem noteworthy enough to warrant two instances of the date in the top 20, It would be surprising if it was only due to date of birth too, given I can't spot any other date-like entries.
"cepetsugih" and "exigent" seem like odd ones too
28 of the top 44 Twitter leak passwords don't appear in the RockYou top 100[0].
It suggests that they're bots - but then how does malware capture credentials for a bot?
"There are two types of companies, those that have been hacked, and those that don’t yet know they have been hacked."
The feature is called "Login Verification", I think, and it's only SMS based, no Google Authenticator / Authy style one-time password... Also, it was saying I needed to verify my email address before that feature can be used, but there was no option to verify the email address that is used since I've registered almost a decade ago... Had to change my email (used the username+somestring@gmail.com trick to reuse my address, as one email can be used with only one twitter account...) then change it back.
If I go 40 miles south I'm in ( the Republic of ) Ireland and can't receive SMS.
It feels like data collection veiled in security. Giving out more personal information is the exact opposite of everything I've learned about privacy and security.
If you're worried about your privacy, which is understandable, buy a prepaid sim card, a cheap phone and use it only for your 2FA accounts. Not sure about the US, but in my country prepaid GSM sim cards are cheap and you don't have to give away your ID to buy one (though this may change soon).
It's vulnerable to social engineering of your cell provider's customer support line, for one. It's happened before [1].
[1] http://gizmodo.com/how-hackers-reportedly-side-stepped-gmail...
So no, "by that logic" doesn't apply. You can choose to use something else than a phone to auth, but if it's SMS based well... I just came back from a week in France where I had zero cell connectivity. Had I been using any kind of SMS based 2fa, I would have lost access to those accounts with no forewarning.
My bank requires SMS confirmation every time I send money online, and when I was in the US for 10 days, even with my SIM, I couldn't get SMS's, and thus couldn't do banking. This is extremely annoying.
All I'm really saying is that limited options does not mean "broken". It just means limited options.
The post also gives a justification for using symmetric encryption, it lets the tokens users enter be shorter.
Twitter uses a one-time code sent via sms so I don't think this would be an issue unless the hack is persistent.
Oh, damn. Thanks for pointing this out. I'd never looked into the details of HOTP or TOTP -- I assumed they were using public-key crypto rather than just a hash of shared values. That sucks. :(
The article says data may have come from user input, so yeah, 2FA would actually help there and wouldn't "leak".
All I can suggest is to keep trying every few months. I have been trying for years. My carrier still isn't listed but it finally started working about two weeks ago for me (I'm not in Germany though). Now I have to hope it keeps working with my still unlisted carrier or I risk getting locked out of my account. At least the bad guys are locked out too...
Your account may have been compromised by a website
or service not associated with Twitter.
Maybe the malware authors are processing and leaking the data per-website for monetization purposes?
Another way would be that only a specific twitter app has been targeted by the malware.
No, it's not news at all. Anyone who's been running spyeye, zeus, whatever for a while ends up with a similar amount of logs. They don't tend to get posted publicly, but are regularly sold on various forums.
32M simultaneous installs would be a lot, 32M lifetime installs isn't.
edit That number is actually active users and I do apologize the number of registered accounts is estimated to be over 645 million! edit2 Actually 4.9% of the estimated accounts were "leaked" (if this is an actual twitter leak since still no official word)
If anyone is able to help me, I'd appreciate them emailing me. You can find my email under my account.
It would be a huge help!
I wonder how you protect against that apart from the thing banks do where they say enter the third and six character? Even with those if the malware monitored a few of them it could probably figure your info.
The buried lede for me here is that MySpace has 360+ million accounts. I thought it was DOA.
This would be coherent with Twitter denying a breach, these would be accounts hacked at some point of the past (and some purposefully generated) and added to the bot network database.
It seems the two platforms I derive the least amount of value from (Twitter and Linked In) are the most vulnerable to hackers and leaked passwords.
I was caught up in the Linked In password debacle recently and now have my e-mail address in the haveIbeenpwned.com database - thanks Linked In. I wonder if I'll get caught up in this mess too.
I only keep my Twitter and Linked In accounts to avoid FOMO (Fear of Missing Out) but this is making me want to shut it all down and erase every trace of personal information I have on both sites.
Twitter didn't get hacked. Browser malware screen-scraped the passwords.
Do you think a typical end user is going to care the technicalities of how their password might have been leaked? I certainly don't.
The takeaway for me is that (yet) another website I entered personal information has leaked it - regardless of how this happened it further damages the trust I have for Twitter.
Had I never used Twitter all of this would be a non-event.
Please do tell me if you think I'm being illogical - I'm all ears.
Well, I think it's quite difficult to argue that. If you had a keylogger installed on your machine – apparently the case here – in what way did the website leak your personal information? Wasn't it the browser's fault?
I do think it's pretty illogical to complain about Twitter being vulnerable, if this leak was caused by screen-scraping malware in a browser. It's not something that Twitter can really defend against, beyond measures like 2FA.
Furthermore, if your browser is infected, a lot worse things can happen then having your Twitter account compromised (e.g. access to your PayPal, bank and even your personal files).
I..I don't think you did. Twitter wasn't hacked. It was most likely a totally unrelated piece of malware. Users that were infected most likely have all their passwords handed over to this hacker (which means there will be more leaks to come).
I mean if anything, this is a good case against using the Firefox/Chrome password storage mechanism (which is most likely where these leaked passwords came from).
But that is about as useful as saying, "If I never had a bank account, then these scammers wouldn't have been able to convince me to give them access to the bank account. Now I have another reason to dislike banks!"
Twitter, and Linked In too, have not added any value. And so when they start to become the cause of security concerns I'm going to use them as an excuse to shut my accounts on them.
It gets worse though, because I would bet that most people who do close their accounts on Twitter/Facebook/Linked In et al walk away thinking all of their data has been magically erased. I suspect that this is not the case, so the mere fact that you ever had an account on these platforms leaves you vulnerable to their security risks ad infinitum. That wouldn't be true of a bank.