There has been a significant data breach with 5.4 million Twitter accounts:
While some of the information obtained in the data breach is publicly available, linking phone numbers to email addresses are key for more sophisticated and successful phishing attacks.
And if it is a mobile phone number particularly, a key for other types of attack i.e. not just phishing.
I wonder why only 5.4 million users. With apologies to Elon Musk, is that the number of real Twitter users? i.e. excluding bots, sock puppets, ⊠
I suspect there could be substantially more. It is only 5.4 million based on the number for sale.
A hacker may chose to sell smaller bundles of data at $30K rather than all the data for $30K.
This website contains some basic information of âwhat to doâ if you are a Twitter user:
Thatâs one possibility, a definite possibility. Another possibility is that the scraping / underlying vulnerability was fairly slow and thatâs all they managed to scrape before the vulnerability got patched. Thereâs not enough information to know for sure. (I mean you can scrape / exploit as hard and fast as you like but that may increase the chances of detection. A sudden spike of activity, particularly from a limited IP address range, is the sort of thing that raises red flags.)
Where offered, use two-factor authentication (2FA).
Two-edged sword though.
While this is good advice where it really matters (e.g. where money is involved!), it actually increases your security risk and increases your privacy risk in the general case. That is, in the situation that 2FA is implemented via a mobile phone number, the mobile phone number is stored by the random web site and thereby made available for hackers to take (and made available to the random web site to spam you etc.).
2FA via mobile phone number or via mobile phone app should be used judiciously.
If you choose to put personal information like your email address and / or phone number on public social media sites like Twitter, then that is your choice.
If you make it public then anyone can view and harvest that information. The breach here was that some users put those details on the site, but as private. A bug allowed viewing anyway.
Reported to, and fixed by Twitter last January.
Not a Twitter breach but the ABC is reporting:
If you use LastPass to remember your passwords for you, heads up â the tech company has suffered a âsecurity incidentâ.
The company says it detected some âunusual activityâ two weeks ago, which led it to find an unauthorised party gained access to parts of its development area and took parts of its source code.
The company has assured customers that their personal data and encrypted passwords werenât accessed and services are operating as normal, but LastPass is investigating further security measures to prevent future breaches.
This could be quite serious. A software supply chain breach could make irrelevant their assurance that sensitive data was not accessed.
For a business that is security software, they seem very inept.
From ITnews.
LastPass is an attractive target, and has been compromised a number of times in its lifetime, including a 2011 incident that saw some usersâ email addresses and their salted password hashes transferred from a company database.
In 2015, LastPass again suffered a data breach, that resulted in user account data being compromised.
And this is why I still use a password manager that doesnât require a login to a website and all passes are stored on my computer, not someplace else.
I will never use a pass manager that demands my personal details and stores my stuff somewhere on the internet. It has never made any sense to me.
I agree 100%. For my needs.
The reason that someone might want such a product is access from multiple places i.e. a single, centralised, online site that stores and maintains all their passwords and it can be accessed from any device that can supply the master password, at any time, from anywhere.
It does make the site an attractive target and if it is compromised in any way then you just got nuked, with all of your passwords stolen in one attack, which is exceedingly inconvenient, if not worse.
Iâm not justifying use of an online password manager or recommending it (quite the opposite), just explaining it.
The central site can mitigate a compromise by ensuring that passwords are encrypted and decrypted only on the client device - so what is stored on the central server is as meaningless to the operator of the site as it is to an intruder on that site, as it is to you (without using the master password).
However if the software is a blackbox then you are not likely to know how it is implemented and whether it is secure. So you are taking a lot on trust.
The other reason may be that it provides a backup of the details. Storing locally runs the risk of the data being corrupted or lost.
You are, and there are many password manager offered by relatively unknown companies.
It is important to understand how any password manager stores the data and how it is retrieved. High end/end-to-end encryption is important no matter where it is storedâŠand decryption occurs on the device and not in the âcloudâ before data is sent.
I agree. One would expect a company offering Password Managers has the upmost security.
oh yes. I forgot that not so minor detail, so in that respect, I do use an external source for storing the passwords so I can do exactly that. The database is stored, encrypted, on Dropbox. Used to also have an iCloud option but they dropped that.
And yet that appears not to have been the case? Not only in the present incident but @GregR also mentioned two earlier incidents. So while your expectations are very reasonable, the company does not appear to be meeting your expectations. 
The original ABC article said, in respect of the present incident, that an unauthorised party gained access to the âdevelopment areaâ. Was that read-only access? or read-write access?
In the wider context of IT security, it has been recognised in recent years that the software supply chain is an extremely effective point at which to intrude. Successful alteration of the software at the software supplier, which may be a small and obscure company, has the potential then to spread to a great many other companies, some big, some small, and to spread quite quickly through the automated software update mechanism.
The only official company statement that I could find is here: Notice of Recent Security Incident - The LastPass Blog and it makes no mention, confirm or deny, regarding software supply chain compromise. The only additional piece of information is:
gained access [âŠ] through a single compromised developer account
which would certainly raise questions about whether that developer had read-write access (I would expect so), whether they already had additional controls in place to prevent any source compromise (I would hope so) and/or whether they had to disinfect the source area.
It also raises questions as to whether developers are required to use 2FA. For their line of business, I think it would be justified.
My understanding is that LastPass never actually has your sensitive data. When it stores âpasswordsâ it in fact stores hashes. These are single direction i.e. you cannot work out what has been hashed from the hash, but can access the hashed data using the original key that was used to hash. LastPass states that the master password provides the key to your online password vault, and so if you lose that password you simply have to create new accounts for everything.
Of course, as LastPass is a paid subscription product the company still has all sorts of its customersâ personal details, so LastPass account data (e.g. name, email, credit card) would still be accessible to the company and to anyone who gains access to its records.
It would probably be possible to gain access to individual password vaults after hacking into the LastPass website, through a man-in-the-middle attack - but this would likely require state resources and would need long term penetration of the companyâs systems. It would be much easier to phish individuals and get a keylogger onto the targetâs device so you can get their master password from the user.
The big problem is not that your master password or your individual login / password combinations could be revealed, but that the service you rely on to manage your logins could become compromised.
If the system fails, your logins fail.
And in all probability you have no idea what your passwords are if using a cloud based repository password manager that generates passwords for you.
I donât think thatâs correct. The test of the matter is I suppose whether, having stored a password in LastPass, you can retrieve the plaintext password.
I think the reference to âhashâ is talking only about the master password i.e. the password that authenticates you to them, not talking about any of the actual stored passwords (which authenticate you to a myriad of other web sites etc.). Storing a (salted) hash of the master password on the server is completely standard for any best practice authentication password.
The article that you link to also explicitly talks about 256-bit AES encryption. I think it makes clear that stored passwords are stored encrypted. So not one-way (single direction) but instead reversible - but only reversible on the client.
That is more complicated than it needs to be, well sort of.
If a development account is penetrated (as appears to have been the case in this incident) and the intruder is able to modify the source code, build a new binary, and push it out to production (perhaps there are inadequate controls) then every customer will potentially have the bad software installed on his or her computer sooner or later.
This is basically how a software supply chain compromise works and is by no means unique as a possibility to this company.
The bad software is then able to carry out a range of nefarious activities e.g. exfiltrate any decrypted stored password, perhaps exfiltrate all stored passwords in plaintext, perhaps exfiltrate the entire encrypted password store along with sufficient information to decrypt it offline.
All the while still carrying out its normal function, so not obviously alerting the customer that something is wrong.
An encrypted password store is not a lot of data, depending of course on how many passwords you are storing, so it could be exfiltrated in the noise without attracting attention. Itâs not like trying to exfiltrate a stolen 1 GB database without attracting attention.
Good point. Just another reason to avoid online password stores.
Possibly that can be partially mitigated if each client caches locally a copy of the encrypted data, in part or in full.
(Because the password store is encrypted on the client, the possibility exists for the password store also to be signed on the client. That means that even if the server is totally compromised, it cannot serve out altered or erased or corrupted information - or more specifically it can do so, but any such data will immediately be detected by the client as bad, and rejected.)
