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".
>t 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 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.
I shouldn't have to look at the html source of a page to determine the title. (Most mobile browsers don't show the title, and even desktop chrome only shows a little bit of it).
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.
The title is the written on the link you click on on Hacker News. I'd argue that HN is a place to curate direct links to stories and discuss about them, if I want to read techcrunch I can go directly on techcrunch
Yes. They are a well known data leak source. LeakedSource is probably the most realiable one right now. There is always https://haveibeenpwned.com/ but they don't have anywhere near the amount of records places like LeakedSource have. In addition, LeakedSource has access to private databases that aren't public.
Question: From my understanding bcrypt is designed for security even when the hashed data is leaked. Each piece of data is uniquely salted and hashed to perhaps varying degrees of difficulty. So for a thought experiment, let's say a site made the password column of their user database public. Given an entirely public password column, even with associated usernames, would this have any use or decrease the security of those user accounts at all, aside from the obvious that their username is known?
It would allow you to bruteforce the passwords without any sort of rate limiting. So, if you used a dictionary, you probably could get quite a few weak passwords in a short amount of time relative to a system that had proper rate limiting to prevent these kinds of attacks.
Depends what you mean by short amount of time. Depending on the strength selected with bcrypt, it can easily take a second to check a hash. On a 30m password database, this will take a year on one machine to check just who is using "monkey" as a password.
You're massively overestimating the strength of bcrypt here. olcHashcat on a single modern GPU will do several thousand hashes per second, depending on work factor and GPU speed.
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."
The work factor also increases the work the server has to do to handle users logging on, which is a big cost both in UX and hosting fees. In practice, reasonable work factors for bcrypt are between 10 and 12. What application could tolerate a full second of delay (and 100% usage of a server core) just to hash the users password?
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.
I don't think anyone has any expectation that a login should be as fast as any other page load. Same thing for authorising a payment. I don't think a 1 sec delay when authenticating is unreasonable.
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.
> The work factor also increases the work the server has to do to handle users logging on, which is a big cost both in UX and hosting fees. In practice, reasonable work factors for bcrypt are between 10 and 12. What application could tolerate a full second of delay (and 100% usage of a server core) just to hash the users password?
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.
Because something with a cryptographic hash, like sha256, you can do millions (or in some cases billions) of hashes per second on the same GPU.
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.
Additionally, there's a new player in town called Argon2 that attempts to solve the problems with bcrypt and scrypt. It's the most recent winner of the password hashing competition.
bcrypt is limited to 72 characters (admittedly this is not that big a practical limitation), and scrypt is an excellent KDF, but wasn't designed as a password hash, and thus doesn't have great GPU defence. In practice, they're still both great, but that doesn't mean we should stop trying to do even better.
Argon2 looks really interesting, but it is still relatively new.
If someone isn't ready to go with Argon2 and truncating past 72 characters is an issue, Django (and possibly other implementations that I'm not aware of) overcome that by first hashing the password with SHA256 before passing it to bcrypt.
I don't know if it has anything to do with GPUs, I had thought it was due to memory, as referenced on the wiki page for Litecoin: "Litecoin uses scrypt in its proof-of-work algorithm, a sequential memory-hard function requiring asymptotically more memory than an algorithm which is not memory-hard."
When you have a massive leak, it's better to have under 10 angry users about that they have been hacked (increasing at a slow pace) than most of your userbase raging at you and leaving your service.
If you're not trying to crack the 30m passwords, but focused on one, and especially if you might have some other clues about what that password might be, it could take a very short amount of time.
With bcrypt you can set a parameter which determines how slow it is. So if hardware gets faster, you can change the parameter. (brcrypt uses 2^n iterations where n is the parameter.)
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.
It seems like implementing a security strength which is a function of the current practical CPU speed is a recipe which could lead to disaster in the future, mainly because of how reluctant some companies are to change existing systems once they are in place.
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.
Depends on how you design your password system... once upgraded a password system by putting a marker with the pwd for newer encoding... this way it can be upgraded as users login.. after n% of users have rolled to the new system, or x days, you can disable the other accounts and require they reset/recover their password for use.
Chances are that you can't afford the most modern hardware. An attacker at least temporarily can probably afford more than you can. If you configure bcrypt so that an attacker spends 1s, it will be to slow to be practical for you.
Yes, but even if you allow it to only take 1ms per check for an attacker, it's still practical for you and will take an attacker 4 minutes per account to check all of /usr/share/dict/words (to say nothing of the "add a 1 or a ! at the end"), so long as you are using random per-account salt (which bcrypt basically guides you towards).
Make it 15ms for an attacker and it becomes an hour per account just for the dictionary.
True but in reality an attacker won't just use any dictionary. They look at password leaks, figure out what passwords people are actually using and what the most popular ones are.
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.
An i7 laptop. But even if you use an 18 cores server, it doesn't really change the point. It might take a month instead of a year. But it still doesn't scale, even to only check the most common passwords.
How can you say it doesn't scale? You just need to spin up a cluster that is powerful enough to get down to let's say a week. The cost of this would be a joke for a company / institution of a certain size.
It does technically scale, just like everything else :)
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.
1 week only tests 1 password. It would have to run for years to get a decent set of results. I don't see how a company can afford all that hardware and power to do something that is illegal to begin with. How do they monetize it to get a return?
I'm not sure the fastest per core speed for the last 5 years in CPUs is significantly faster.. more cores, more caches for some operations, but not nearly the growth we used to see.
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.
Let's say that were true, so in a year and half you will only have to spend 20 years cracking the passwords? Bcrypt is designed for this exact situation and performs pretty well.
I am not saying bcrypt is bad. But thruth is, we have to be constantly challenging our assumptions about security and avoid feeling like the battle is "won".
Presumably your users don't want to wait 6 minutes to log in, and nor do you want to tie up a full core for 6 minutes running the hash. That's the problem with increasing bcrypt's work factor - you have to deal with the increased difficulty too.
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.
Right, but you would still bypass the rate limiting of the server whether that be login attempts, http requests per second, firewall rules, latency or whatever when checking.
That's another rate limiting that has nothing to do with the hash strength.
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.
wouldn't the slowness of bcrpyt be a hindrance enough? Of course rate limiting is a much greater barrier, but I thought the whole point of using bcrypt is that its naturally slow and prevents checking several passwords in a short time
You can set the work factor (log rounds). Bcrypt is also cool because it doesn't scale well to GPUs, so it's still pretty slow even if you have decent hardware.
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.
The salt is typically stored with the hashed value. Its purpose is simply to prevent you from being able to use a single dictionary attack on all users.
The salt is usually stored with the hash. It prevents using pre-calculated rainbow tables. Without a salt you can check a password guess against all passwords. With a salt you can only test the guess against a single password.
It's an interesting thought, but it would be a catastrophe. Even if you can't brute force strong passwords due to many rounds of hashing, you can still check the hashes/salts against common passwords. You can't do a rainbow table attack, but you can do a dictionary attack.
I suppose the main danger is the possibility that someone might, at some point in the future if processing power should suddenly take a leap forward, come up with a way to crack them.
You can upgrade hashes offline as well. You just hash the existing hash with the new algorithm/configuration and remember algorithm, salt and any other parameters for all previously used algorithms. If you have all that information you can take the same path to verify the password and replace the chained hash with a simple hash that's faster to calculate.
Indeed, though I suppose you've got to hope that the keeper of the passwords gets their hands on a similar level of processing power as the attackers do, with which they can increase the encryption work factor.
Or some curious, thousands-of-computers strong grid-based cracking enterprise. I suppose, even constrained by the current state of tech, cracking bcrypt with some kind of massively parallel dictionary attack isn't entirely unfeasible.
bcrypt and other modern hashing algorithms allow strengthening your hashes (by computing more iterations) at a later date should technological advances make your current number of rounds too weak. This allows you to 'upgrade' your password hashes from 20 rounds to 20,000 without needing the user to re-enter their password. If you publish your hashes at any point, you lose the benefits of this, if your hashes become weakened by technological progress you need to reset your users' passwords.
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?)
You store the user's salt in a database column just like the hash. Optionally, when they change their password, you update the salt.
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.
You can hash a fixed salt + password + some other user info like surname or email address. That way if you have the salt you can't just compute the hash of salt+"123456" to see who had that, you have to compute separately for each user.
Using a site-specific constant combined with the user's e-mail as the salt isn't too horrible.
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.
A site specific constant is often called a "Pepper" as an aside. Just helps people google it if they want more information.
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).
site-specific content (or formulaic derivations based on other columns likely to be in the same DB dump) suffer from internal (or former internal) bad actor problems as well. Disgruntled (or just loose-lipped) ex-employees can leak the formula or constant and you have a false sense of security.
(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.)
Yes absolutely this - I was just trying to explain how salts should implemented - in the real world always use something like bcrypt or scrypt that does all this for you.
OK, I think I got my terminology wrong. But my thinking was that as well as using bcrypt or whatever on the info in the database you can add some random value stored in code rather than in the database so if your database is compromised it's still a job for them to crack it. Not quite sure what you call that.
Does anyone know the significance of the date 9-11-1961? The password list has 10,444 matches for "9-11-1961" and 10,231 for "9111961".
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.
Twitter also does 2-Factor Auth. If you value your Twitter account, in addition to changing your password (which hopefully is unique amongst your accounts), also activate 2FA.
Was just trying to set this up, and not great (IMHO).
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.
Curious, why is SMS-based auth a downside in your opinion? I prefer to use SMS-based 2FA where available, as you can always pop the sim card into whatever device you have on hand and receive the code. As opposed to smartphone app, where you are tied to a particular device being available and in working order.
There have been quite a few cases where malicious actors have been able to convince phone companies to forward sms messages to other numbers via social engineering to defeat this type of 2FA.
Airplanes are a big one for me as a frequent traveler. Every plane has wifi but you can't receive SMS. If my previous cookie expired or the site thinks the plane's IP is new and strange, then I might have no way to sign in from the air.
Try spending a bit of time traveling. I've been on the road for almost a year. My phone number changes every month or two (or more depending on if I'm buying new tourist SIMs everywhere I go).
Nobody else has mentioned this, so maybe I'm an odd-ball, but I don't like giving out my phone number to ad-based services, especially social media sites. What do they do with that information?
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.
While that's annoying, I wouldn't call lit broken. Most 2FA-enabled services I know want a phone number first, including Google (and from what I remember Facebook as well).
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).
By that logic, it is also also broken because if you don't have access to your phone or the Google Authtenticator app or phone OS is malfunctioning, you can't access your account.
"Google Authenticator" style 2fa is an open spec. You can build your own authenticator to your own liking.
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.
But I can back up the secret in multiple places, and as another commenter mentioned, TOTP is an open spec, so I don't have to rely on exactly one sim card being in range of a cell tower. I have options.
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.
It's relevant because it means there are N apps out there instead of the exactly one pair of "my SIM" and "a tower my provider can use to reach my phone."
If you do so, please be sure to check how often you have to top up the number so it isn't "freed".
The prepaid provider I used to use had me top it up every 6 months for at least 5€ ($7 at the time), to keep my number. I can't really blame them, though because they also have to pay for the numbers.
Hardware/Software 2FA tokens are based on a PRNG with a shared seed. If the table with passwords was accessed it's likely the table with 2FA seeds is hacked.
Twitter uses a one-time code sent via sms so I don't think this would be an issue unless the hack is persistent.
> Hardware/Software 2FA tokens are based on a PRNG with a shared seed. If the table with passwords was accessed it's likely the table with 2FA seeds is hacked.
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. :(
I am trying to activate that as we speak, but I never get the SMS. I tried 6 times in the last 3 hours. I guess it's overloaded or broken at least for my phone number (german mobile phone).
I had a terrible time figuring this out too, because the mobile app offers it and provides no feedback as to why it never succeeds. The reason is that Twitter only supports a very limited number of mobile carrier networks. Here's the support page listing them and you can see there are none for Germany: https://support.twitter.com/articles/20170024?lang=de#
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...
I work for a company that utilizes texting to customers, we do this now via email, ie 1233451234@vtext.com for Verizon and there are others for the different carriers. These carriers are beginning to put a halt to this and are starting to require you to sign up and pay them to send SMS messages. Soon my company will not be able to send any SMS without paying the carriers. Perhaps this is the problem?
Unfortunately this only helps protect a twitter account. It doesn't protect against the greater concern, where the password has been cracked and the user has reused the password on other sites.
Like they said in the article, Twitter uses bcrypt to store your password, but many of the passwords in the dump were plain text. This suggests that they were scraped together from external sources (i.e. malware on your machine, re-use of a password from one of the other dumps like LinkedIn). Hence, compromised from outside Twitter.
They mention browser password database in the article. If true at the scale of 32M people that would be an even bigger news. Twitter may just be the beginning.
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.
>They mention browser password database in the article. If true at the scale of 32M people that would be an even bigger news. Twitter may just be the beginning.
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.
They may've checked the password from the breach against your twitter password. If they match, they know that the password breach data could be (and will eventually) be used to access your twitter account.
Bots? Combines with the insane high number of mail.ru it would be my guess that mail.ru has made it easy to creates account in some automatic way and that's what the bots are using, along with a silly password.
I also keep getting these for a relative inactive account. I assumed phishing since the subject of the email was "suspicious sign in detected" but the content made no claim of successful sign in.
Twitter used to support authentication to their API's with a username / password combination. So this leak could come from an app or service that utilized Twitter apis in some fashion and was hacked.
With over 270 million accounts (the largest number I could find) at only roughly 12% of the accounts leaked I'm wondering where the leak occurred? Or possibly the hackers were interrupted mid-download stream?
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)
Does anyone here have a raw download to this data set? I'm a student at a university interested in doing some statistical analysis of passwords for a small project.
If anyone is able to help me, I'd appreciate them emailing me. You can find my email under my account.
>the malware sent every saved username and password from browsers like Chrome and Firefox back to the hackers
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.
Saved user/pass are available to any process running on the machine. You don't have to wait until the user logs in, just access the saved pass DB. (Exception is if you use a password to encrypt the browser saved passes, like Firefox's master password. Then the malware needs to wait until you unlock.)
I should just close and burn all my social/bigco accounts and keep only the ones where an RSA token is available and forget to worry about passwords, shouldn't I?
Why doesn't Twitter have 2FA or U2F? Problem solved, at least in terms of users not losing reputation within their own social space because someone is posting as them.
They do. In fact, I just logged in to change my password and had to go get my phone from another room so I could read the code. The annoying thing is that they don't support Google Authenticator or some other TOTP/HOTP token generator. It sucks trying to log into services that use SMS based 2FA when you are not in an are where you get cell reception.
Thats nothing compared to the amount of fake twitter accounts for paid followers. Probably in the range of 100s of millions of accounts. For the downvoters, or doubters, goto https://www.fiverr.com/ and see if you don't find these services being offered all over the damn place. 1 million followers for 20 bucks.
Yes, I think this is what he means, that this list could have been leaked from some "bot controller" server/network. Or maybe the bot network wants to quit and is selling their assets.
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.
I didn't need another reason to dislike Twitter but this puts another nail in their coffin, for me at least.
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.
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.
The takeaway for me is that (yet) another website I entered personal information has leaked it
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.
Thanks for the explanation, makes sense. Still I wonder how many non-techies will simply read "Twitter hacked" and devalue the Twitter brand in their minds.
It is also important to note that Russian accounts seem to be affected, which might indicate that only Russian browsers have been affected.
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).
> 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.
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).
It is certainly technically true that if you never had a Twitter account, your Twitter password couldn't have been compromised by non-Twitter means, because you wouldn't have a Twitter password.
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!"
Bank accounts add huge amounts of value to my life. If my credit card is stolen and used fraudulently, I'm not going to revert to cash :)
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.
The real source, not this redundant media crap that buried the lede...