I just went into my old lastpass account to try and wind down the account, delete everything, and then close the account.
No option to "select all" in the list so I resorted to clicking the check box on by one down the page. I accidentally slightly clicked outside a check box... guess what? Everything gets deselected.
Start over.
Ok start again, maybe I want to list in alphabetical order rather than group by category to minimise mistakes. Whoops, selecting that option deselects everything in the list.
300 odd deleted in batches of 30-40.
When a company's whole application is covered in anti-patterns and dark UX to make it as hard as possible to leave then companies like this deserve to die.
Deleting the account is a bit tricky too.
1. Go into account settings in the top right drop down
2. In the Links area click on "My Account" which spawns a new browser window
3. Click the red "Delete or Reset Account", you can't miss all the red buttons
4. You can either reset your account or delete, choose delete
5. A modal will appear telling you stuff, enter your master pw, a reason why your leaving and then click delete
6. You will be asked twice if you really really want to do this
7. Press ok
I also did not have a "Select all" box but was able to check the first entry, scroll down, hold shift, and check the last box which then selected all items in between. So I removed all of 600 of my accounts in about 20 seconds. Hope this helps someone.
Shift+Click to select a range is so second nature by now I don’t think it would have occurred to me to look for (or on the flip side, create) a dedicated “all” button.
Just me of course but I don't think I'd guess that without certain UI cues. With checkboxes for eg I wouldn't even think of shift clicking. Not disagreeing, just thinking aloud :)
For me it’s second nature in desktop applications and file management, but I never assume that the any specific web dev has added it. (And tbh: I have less and less confidence in web code in general.)
Shouldn't be a second nature, that is a good old well known useful pattern like right click for context menu, very essential.
Even if new methods are coined by some local reasons old and generic ones should be remembered to avoid the hopeless chaos the UX partisans push us into nowadays, doing things differently for the sole sake of doing differently.
I don't think that's dark UX, it's just shitty UI design. What bugs me the most about LastPass is how it tries to be so damned helpful and offers to fill in credentials on sites that they clearly don't belong to, or offers to save credentials on a site where I alredy clicked "don't save" 1000 times, no really, I don't want to save my private passwords in my company vault thank you very much, why the f$%& don't you have a "don't bug me again" checkbox in this sh*$$y popup?!
BTW, if you're exporting your data, check that it's all there. I had the unpleasant experience of noticing Lastpass either has a buggy implementation or intentionally giving an incomplete export. I ended up needing to manually copy credentials over one by one.
It is a little weird — I vaguely recall that the sort of “diplomatic” answer about password managers has been for a while something like “well, you should use keepass and just keep things local, but if you want to ease of use, lastpass is not too bad.” So that went right out the window I guess.
I mostly use keepass, but for some accounts I don’t really care about I’ve started using the built in Firefox/iOS stuff. Giving that a second thought about now…
You need to compare the URLs at least for equality in order to resolve conflicts, which is most straightforwardly done server-side. You could maybe do some sort of content-defined encryption to them, but I’m not sure how useful that would be. So storing the URLs in the clear is unfortunate but not inherently dumb.
(As to how KeePass implementations deal with this problem when on top of a single synced file: they mostly don’t, data loss on conflict is not uncommon[1].)
“The threat actor was also able to copy a backup of customer vault data from the encrypted storage container which is stored in a proprietary binary format that contains both unencrypted data, such as website URLs …”
I wasn't commenting on the security implications. My point was that bleeding implementation details like .php in your URLs is silly because that URL might end up being served by a Node app one day.
But on the security point, a URL ending in .php does imply a "we just YOLO'd a bunch of bare scripts into the webroot" application architecture, which is not confidence inspiring as a user and sure looks attractive to pentest.
A URI ending in .php is not cool (never was), and this advice is most important for content (articles etc.), not necessarily for account management pages.
That's how I did the last one hundred or so in the end too. Someone also said shift click works to select everything as well, I tried it but it didn't work for me in Safari.
Just deleting the account won't solve the issue anyway.
I am resetting all the passwords for all my accounts. It's super annoying and it will days for me to reset all the passwords. But thankfully I have MFA for all important stuff.
Wow. This is basically the worst case scenario. Attackers got access to the vaults themselves? While they are encrypted, it all depends on how secure your master password is now. Because the brute-forcing has almost certainly already begun.
I switched away from lastpass to Bitwarden a while ago, and have changed many of my passwords since then. But I’ll probably rotate most of my passwords anyway, out of an abundance of caution.
Just FYI, password rotation is currently considered an anti-pattern. I think we can imagine some kind of future where there's a common password protocol that user-facing services could talk that would allow certain entities with blessed access to rotate passwords without the user ever having to know about it, but in the current world, rotating passwords causes most users to use weaker passwords.
Enforced rotation of passwords on a schedule is no longer recommend, and is advised against. Mandatory immediate expiration/rotation of all credentials that have been (or are suspected to have been) somehow exposed is a requirement of all security protocols. And there is nothing wrong with a user voluntarily rotating their credentials, that does not reduce security (as long as they don't do something silly like use less secure passwords in the interest of making them more memorable).
Umm, not sure you understand. Yes AES256 is good, if you have a great password.
However if you take 1M users, as them to set a 12 character password with A-Z, a-z, and at least one digit you'll find an astounding lack of entropy. I believe this is pretty close to LastPass's master password requirements.
If you take the most popular 1M passwords and attack the master password you'll find that you've cracked them. With a 2 generation old GPU and the default iterations of 5000 (like several people mention on this post) you can try 300,000 passwords a second. So 3+ seconds per vault and you'd crack a decent fraction of them.
First, where do I find the most popular one million 12-character passwords that use A-Z/a-z/0-9?
Second, the top 1M of 6/7/8 character passwords have a statistically higher probably of being the correct password than the top 1M of 62^12 because their distribution function as a percentage of possible instances is narrower. Put another way: the top 7 char password might be used 10 million times, and the 2nd most popular might be 9million, etc. With a 12 char password, the top 1 by nature appears much less frequency because the total possible space is larger and people have to think a little more. Entropy when that has nothing to do with inverse distributions.
Put another way, look at the frequency of the top-1 password as a sum of all instances of all 1M passwords. It is much larger % for smaller passwords than larger. It is much less likely that the top 1M 12-char passwords are as likely to be successful as the top 1M 6/7/8-char passwords.
I just did this for the top 1000 6/7/8 chhar passwords, the top 6 digit password "123456" represents 1.3% of all 1000 6-chars, where as "password" is 0.9% of all 1000 8-char.
> Second, the top 1M of 6/7/8 character passwords have a statistically higher probably of being the correct password than the top 1M of 62^12 because their distribution function as a percentage of possible instances is narrower.
Not how this works. This would only be true if you were picking passwords randomly out of all possible ones and the attacker knew how long the password. For example, "password" is a more common password than "cat" is (both are terrible of course). It doesn't matter that "password" is longer than "cat".
If you knew how many characters long the password was it might be a different story. But you don't have that information. 012345 being a larger percentage of 6 character passwords than "password" of 8 character passwords means nothing if you don't know what length the password is. After all, 100% of passwords "af64nh8" are "af64nh8", but that means nothing unless you know the password you are attacking falls into that class.
There's been tons of dumps posted. Normally I see the download or magnet links on Reddit or HN. Even with hashes people have broken 69% [0] to 85% [1] of the accounts. There's mailing list or forums for various related tools (cracking tools, gpu cracking, have I been pwned, etc.) that discuss these kinds of things, including where to get the passwords and/or hashes.
One of the summaries claimed that 3% of the cracked passwords were 12 characters long (some 1.9M). 48% of the cracked passwords were lower case and numbers.
Often a thread that mentions the compromise/leak also mentions the newest "batch" that includes the new entries. The last one I tracked was RockYou2021.txt, some 100GB, around 10GB compressed. Just use your favorite egrep/perl/python to filter for whatever you want. I checked the a random torrent and found 25 people on it.
I agree on your comments on the distribution, but the average user has shockingly little entropy, and human password entropy doesn't scale with password length. I expect a decent chunk of the passwords are going to be whatever the user's default password was and either repeating or extending it in obvious ways. Even the simplest approach of testing 2 words or 3 words for a total 12-15 characters with the simple 3/E i/one and 7/L replacements would likely. Granted I'm not expecting the same 8 character 69-85% with 12 characters, but I also don't expect much significantly less, and I believe 33M accounts were stolen.
rockyou2021.txt.7z has 8459060239 passwords
rockyou2021.txt.7z has 835365123 that are 12 characters long
pwned-passwords has 847223402 unique password hashes
pwned-passwords has 5579399834 non-unique passwords hashes
I'm amused that each password was reused on average 6.5 times.
I suspect large fraction of the pwned-passwords hashes could be turned into passwords with the rockyou2021 list.
> First, where do I find the most popular one million 12-character passwords that use A-Z/a-z/0-9?
I'm sure it may not be easy to find this database, but it is probably not that difficult if you hang out in the type of circles that the people who cracked that site hang out in.
> Math...
This strikes me as nitpicking when one can access such powerful computing devices as to make the difference practically irrelevant. So make it 10million and wait a few more minutes, who cares?
How is it nitpicking? The distribution tail effectively goes to a frequency of zero. Increasing to 10M doesn't solve the problem because the space is so vast, by the time you get to a fraction that has the similar area under the curve as 1M for 6/7/8 chars, you've lost any compute advantage. We're not talking an order of magnitude, we're talking multiple. As much as I know y'all want to hate on any password manager that isn't your favorite, math doesn't care about what strikes you as nitpicking.
> by the time you get to a fraction that has the similar area under the curve as 1M for 6/7/8 chars,
You are (incorrectly) conflating entropy of a password with its length.
> math doesn't care about what strikes you as nitpicking.
Math actually cares a lot about the nitpicky details. Both in the sense that small things can have big effects, but also in the sense that things which sound big can also be irrelavent.
I don't use a password manager and am not familiar with the math involved; I was going off your 10million number and the post above you's 300,000 iterations/sec.
I'm trying to understand how Top-N frequency distribution flattens and becomes less useful as search space increases. It is a both a statistical and a psychological issue. If you can't help don't comment.
I think you might find that your life goes a little more smoothly if you weren't so abrasive, confrontational and dismissive. As a side affect, people you talk to won't end up feeling like shit because you possibly will treat them less terribly.
(26+10)**12 is 4738381338321616896 combinations. 300,000 attempts per second isn't going to have an easy time cracking that, so I don't see what the problem is with LastPass' requirements.
It is relevant, because it's where LastPass' responsibility ends. It's not their job to prevent people from being stupid and choosing a password like `lovelovel0ve` but rather to define a requirement that allows for sufficient complexity.
I think a reasonable feature for a password manager would be to do NIST recommended checks, such as comparing passwords to databases of known compromised passwords and alerting/recommending rotation or rejection of the password if a match is found (depending on password entry UI).
Obviously you're not going to get a complete db of known hacks, but a db of most common X million passwords, updated every 6 months or so, is pretty good, and is what I would expect a good password manager to do.
LastPass is in the bad situation of needing to provide excellent security in a product that people really aren't willing to pay a lot of money for. Some of the websites that ask for passwords are in a better position to do this, but then you don't get the benefits of a password manager.
Same issue for the the other password managers out there.
Yes, those with pure random passwords are safe. What percent of LastPass users do you think use a very hard to remember completely random 12+ character password?
Personally I use either VaultWardens random password generator, or some variation of the XKCD like 4-6 words out of 100,000 which give me somewhere north of 64-96 bits of entropy. Cracking that @ 300k/sec takes a quite long time. I like the XKCD approach, because it's particularly voice/phone friendly.
However much more common in the real world is to pick an easy to remember password with low entropy, something like PinkFloydRocks, which fail because of lack of a number and change it to P1nkFloydRocks. Or maybe PinkFloydRocks<2 digit birth year>.
Quite a few plaintext passwords have been leaked, some even with helpful popularity tables. I'd place bets that a decent percent of LastPass's vaults would fall to a top 10,000 12 character or longer popular passwords. I suspect someone is testing this right now.
I had a feeling you were speaking from experience with that 300k number. Does that include the cost of password stretching? As others have pointed out in this thread LastPass uses PBKDF2 with 100,000 rounds. Even if you have a supercharged PC with 6x ATI Radeon HD 5870 you're only going to be able to derive 25k AES keys per second tops to even try, since that doesn't include the cost of deciphering. So how do you do it?
No experience, just saw a post on someone attacking LastPass Vaults. It looked to include everything. Apparently they wrote a tool specifically attempting password recovery on LastPass vaults and with a RTX 2070 (2 generation old) managed 309,000 against the 5000 iteration flavor and 15,500 against the 100,100 flavor.
While I agree with your main point, I think confirmation that the URLs weren't encrypted and that they can all be tied to your Lastpass signup information is far from "best case"
> The threat actor was also able to copy a backup of customer vault data from the encrypted storage container which is stored in a proprietary binary format that *contains both unencrypted data, such as website URLs,* as well as fully-encrypted sensitive fields such as website usernames and passwords, secure notes, and form-filled data
That's real bad - think blackmail material for important people.
I missed that part. What is the problem about URL exposure?
EDIT: all three replies to this comment are about sex-shaming people via their email address, ip, home address. hardly pearl clutching. go to DefCon some day, you'll see how that information is basically for sale legally, let alone on the darkweb.
i don't have a horse in this race because i use my own password storage software but the amount of FUD in this thread is cray cray.
Since they're tied to people's account details, address and similar, I'd imagine quite aggressive blackmail opportunities going forward if the data gets to the hands of criminals.
Think postal letter named and addressed, giving your email, and the adult (or other embarrassing) sites you were a member of listed on the letter, along with details of a bank account to make immediate payment to...
Also, you may be able to identify people working for certain high profile orgs (defence contractors, etc) and target them further if you can gleam from URLs they have access to internal systems by specific URL.
Agreed. Also what's being overlooked by others is the inability (using dumps of "users of site X") is the ability to globally intersect that with another site.
The ability to quickly find users who have an account in (list of embarrassing sites) intersected with (list of internal gov and mil sites, and large defence companies) is hugely powerful to some adversaries, and data leaks/dumps only give half of this equation.
I might be misunderstanding, but if the url was adobe.com, then it would be possible to find the corresponding password from that adobe breach for the same email address (not trivial, but if someone moves in the right circles I assume they could get a whole host of the big breaches in a searchable format).
A subset of users might have reused the breached password(s) for their lastpass master password.
Not sure if you could also feed the breached passwords into the brute force tool to give it a headstart, in case they did a slight variation on a breached password for the lastpass master password.
With a list of names, billing addresses, email addresses, telephone numbers, IP addresses (sounds like it's a list since the user first started to use LP) along with URLs having a 99.9% probability of the individual having an account at the URL... that can be pretty much catastrophic. Create a list of OnlyFans subscribers, or if there is a subdomain used for OF creators you can compile a list of them. Any service that uses unique subdomains (like the users username) means you can connect usernames with individuals and so on.
Some URLs will be for internal corporate networks, things that should be protected by VPN but aren't, or publicly-accessible projects with poor security.
It would be really interesting to crawl through this data and filter out all the boring usual stuff, and see what else shakes out.
It's also somewhat helpful for spear-phishing or other social engineering. If you know which services a particular person is using, it's easier to fool them into giving up access to one or more of them.
Probably that now it is known that people with a lastpass account of email address X also have an account at login.furriesindiapers.com or something really insane like dailywire.com
Any information that helps an attacker craft a more targeted attack is useful to the attacker. With URL exposure the attackers now have a comprehensive list of services that a person depends on and where further data about them is stored.
> that contains both unencrypted data, such as website URLs, as well as fully-encrypted sensitive fields such as website usernames and passwords, secure notes, and form-filled data.
I wonder what other data is unencrypted . They need to be more specific on what that means. Were there certain fields that a person can set in the vault that were not encrypted?
There is a notes field (this is different from the “secure notes” feature) for each password entry that you could use to write remarks. I don’t know if that would be encrypted.
That doesn't require it to be stored in the clear on the server. Extensions/apps could keep a domain list (don't see why they need full URLs) in memory after lock.
Are domains truly the only scope that matters? What if a platform site allowed hosting user web apps (which could themselves offer authentication) all on the same domain, each in their own directory/path. As long as the app was careful to set the path attribute of the session cookie appropriately, the app could be pretty well-contained. Then a password manager just decides that a password field anywhere on the whole domain is a good place to autofill your password for one of the apps on that domain? That's pretty scary!
The context here is with a locked vault so no data to auto-fill with. It's most likely purpose was to indicate "LP has the login info for this site but the vault is locked". An indicator like that can be coarse and simply use a root domain and ignore subdomains and paths, better to have some false positives than leak data in the clear.
[We might be wrong about the locked-vault but might have data scenario, but that kind of seems the only legit reason to store that stuff in the clear, so if that wasn't the reason, LP's negligence is even worse]
I agree this isn’t the worst-case as you mentioned above. However, it is far from the best case scenario which is closer to “only fake testing vault data was exposed”.
The vault leak is acceptable in terms of Lastpass’s formal threat model but could still result in real user pain e.g. targeted spear phishing using plaintext fields like URLs, or compromise for users with weak passwords.
Welp, looks like they were able to copy vaults to crack and, worse yet, they have the unencrypted URLs to choose what to target.
> The threat actor was also able to copy a backup of customer vault data from the encrypted storage container which is stored in a proprietary binary format that contains both unencrypted data, such as website URLs, as well as fully-encrypted sensitive fields such as website usernames and passwords, secure notes, and form-filled data. These encrypted fields remain secured with 256-bit AES encryption and can only be decrypted with a unique encryption key derived from each user’s master password using our Zero Knowledge architecture. As a reminder, the master password is never known to LastPass and is not stored or maintained by LastPass. The encryption and decryption of data is performed only on the local LastPass client. For more information about our Zero Knowledge architecture and encryption algorithms, please see here.
Hm, with all that talk about "zero knowledge architecture", I thought your vault file would be encrypted "in one piece", not just the passwords. If they have the URLs in clear text, that's not really zero knowledge, now is it? And why do they need the URLs anyway, when I can share the passwords just fine from my local PC? Statistics?!
Honestly, URLs are a potentially massive threat vector themselves.
Are the urls associated with individual users either directly or in a bucketed fashion? Seems like no to the former but the release leaves a lot to be desired.
LastPass is an enormous target, obviously. And, I guess, the inevitable has happened: Encrypted trove of passwords is "out there".
Let's assume one's master password is strong. And that LastPass knows how to encrypt data. We're really down to whether 256-bit AES can be brute forced, right? And I guess understanding phishing attacks.
I mean, yes, wouldn't it be great of LastPass took the measures with its development environment years ago? So put another way: Lack of operational excellence hopefully is made for in strong encryption. I hope.
contains both unencrypted data, such as website URLs,
No I think this is the worst that could have happened short of loosing the clear-text passwords. Noone is going to stop the attackers from looking for high-value login URLs and than spear-phish the password for the offline vault.
Forcing a password reset onto customers is not going to help LastPass here.
'form-filled data' includes 'Payment cards' section I believe, which should then make securing your cards an even larger priority than having to change your passwords
No, as stated, they don't encrypt the URL. This is likely so that, regardless of what you have entered for your "when is master password required" settings, the browser plugin can highlight when it knows that you've entered a password for a site.
To further increase the security of your master password, LastPass utilizes a stronger-than-typical implementation of 100,100 iterations of the Password-Based Key Derivation Function (PBKDF2), a password-strengthening algorithm that makes it difficult to guess your master password. You can check the current number of PBKDF2 iterations for your LastPass account here.
I just checked my account and it says 5000 not 100,100 -- there's no way I would go in and change that setting, so this is pretty disingenuous. They must have changed defaults at some point
I do think the default a long time ago used to be very low. I know I went in at account creation and set it to something way higher than it's default at the time.
Looking now though, it says 100100 for me. But i also know i changed my master password at some point, so maybe i got reset to the current default.
According to [1], there were 5,000 client-side rounds of SHA256 in key derivation in June 2015.
It does sound like a missed opportunity to have an at-login upgrade mechanism to upgrade KDF rounds that can be carried out seamlessly or near-seamlessly during the login process. Or at least actively nudging users to change password and thus raise their KDF rounds that way through the default.
One would think that the UI where one routinely enters their master password could silently double as a start using the new default UI, as the change-password UI seemingly does.
If it’s a tradeoff between login speed and security, it seems reasonable to allow users to chose where they want to land between the two, at least within reasonable parameters.
That’s an engineering decision but it shouldn’t be directly exposed in the UI because people don’t understand the trade offs or update it as hardware improves. It’d be better as a time-based setting which changes periodically as attack capacity increases, and perhaps a UI toggle like “faster on ancient hardware, less secure” and “more secure”. You could even automatically improve that over time (“you haven’t used a slow device in 6 months. Want to update to our recommended secure level?”).
Decryption is done on user device so default iteration is set not to be too slow on slower devices. If your all devices are fast enough, It's good to configure it.
It's fine that you want extremely secure iteration counts like 99999999999999999999, but you should wait 9999 seconds to unlock. Every product should have just right default value. LastPass default iteration value was maybe fine in 2008 but computer power is improving.
From what I understand, yes. PBKDF2 is the algorithm that goes from password->key. This key is then used to encrypt the vault. Guessing the key itself is impossibly difficult. Attackers will instead try to guess the password, run their guess through several thousand rounds of PBKDF2, and attempt to use those keys to decrypt the vault.
The algorithm is designed to be run in iterations to be tunable. more rounds takes a lot longer. this makes for both a slower login, but also slower brute-force attempts for the attacker. The attacker can likely still generate guesses in parallel, but each individual password guess will take considerably longer against more iterations.
Lastpass changed the old default for a good reason. I'm surprised they didn't update all accounts to at least the new default.
It means the master password can be brute-forced about 20 times faster, so about effectively a loss of about 5 bits of security, compared to an account where the number of iterations is actually 100K.
I have an older account, it was 500 when I went to check. I'm livid that LP didn't do a reup on the encryption when they moved to 100k cycles. They've basically hosed every customer that's been with them for a while.
mine was set to 500 (not 5000) as well. I'd moved on from lastpass earlier this year but didn't delete my account... though I suppose in that case I'd wonder if I'd deleted in time, or if they really deleted all my info.
Also frustrating that they decided to drop this update on December 22.
with URLs and last-accessed times being plaintext? I suppose "items in your vault" is doing a lot of work there if they don't count urls as "in" the vault.
I'd like to point out to users who have 2FA on their LP access and think they are safer, that does not protect the vault in a compromise like this, it only enhances the security of delivering the vault, the attackers here already have the vaults. Vaults are only protected by password.
When I worked at LogMeIn (previous owners of LastPass), I relocated to Budapest and worked in the same building as LastPass' engineering (I was in another division though). Getting a sneak peek of how the sausage is made gave me the hibbie jibbies and I switched to 1Password there and then. It appears like I dodged a bullet.
They haven’t had the history of security problems that LastPass has had, and they’ve taken steps to handle this kind of situation by including an extra per-user key to stymie password guessing if someone does get the vaults:
I stopped using them when they switched to subscription-only but I think it’s in their favor that they have planned for a nightmare scenario rather than assuming it won’t happen.
Yeah I thought the same. I don't think 1Password is immune to security issues. However, after seeing several things I did not like in LastPass development, I decided 1Password was the safer bet. Knock on wood, they claim they've never been hacked and I hope it stays that way.
Moving from one cloud based password manager to another is hardly a solution. Use password managers which locally store the file and then sync them with gdrive/Dropbox. You can also add another layer of encryption to the file to be extra safe.
I cannot talk about specifics obviously since I was an employee. I can only say I did not see the sw engineering and infrastructure rigour I'd expect from a service that is managing very sensitive information.
Sounds about right. Awhile back I noticed the LastPass password generator was not in fact outputting a random password but that at least a few characters of the password followed a predictable pattern.
I reported it and it was fixed, but it's beyond me how a supposedly security focused company can let such a severe bug in such an important yet simple feature get to production.
> “The threat actor was also able to copy a backup of customer vault data from the encrypted storage container which is stored in a proprietary binary format that contains both _unencrypted data, such as website URLs_ …”
Other threads here have discussed the potential for this collection of sign-up information and URLs to be used for blackmail and to discover hidden services.
There is another major problem: mapping these URLs to existing breach dumps. The attacker now has a list of email addresses and associated URLs. From existing breach dumps (haveibeenpwned.com), they can now try all known passwords associated with these email addresses on all of these URLs. Many passwords stored in LastPass are repeat passwords, and they will gain access to many services without any brute force needed.
There will be a class action lawsuit for this gross negligence in security and false and misleading documentation and marketing materials.
My hope is that LastPass is forced to liquidate all assets and distribute them to their former customers, in addition to being liable for damages and wasted time related to migration to another password managememt solution, not to mention suffering related to any potential blackmail or disclosure of proprietary information.
> "...The announcement doesn’t get to the part about the vaults being copied until /five paragraphs/ in. And while some of the information is bolded, I think it’s fair to expect that such a major announcement would be at the very top."
Why do people use password managers that store all the data on their own servers? Having a centralized database filled with full login information for hundreds of thousands of accounts across all your users (and accounts users clearly care about, mind you, otherwise they wouldn't go out of their way to use a password manager) makes for such an obvious jackpot attack vector that causes situations like this.
I've used Enpass for years now which lets you sync your password database to DropBox, Google Drive, iCloud, etc. So I still have to protect whichever cloud storage account I'm syncing with, but at least it's not an obvious place to find passwords for thousands of users. And if someone did have access to my Google or Apple account, they could reset a lot of my logins anyway.
And I know this isn't technically as safe as the self-hosted options, but it offers the same convenience as LastPass without the obvious painting-a-target-on-your-own-back by handing all your passwords over to The Passwords Store.
> Why do people use password managers that store all the data on their own servers?
> sync your password database to DropBox, Google Drive, iCloud, etc.
So instead of storing it all on one service, store it on one out of three others?
Yes, you can set up your own hosting etc., but 1., will your average user do that, and 2., will they be able to maintain an adequate security posture of their self-hosted server?
Besides centralization being, as always, hard to avoid in practice, having a password-specific storage service also has several advantages over a generic "bucket of data" cloud drive.
For example, I'd expect a (competent) provider to invest some resources into
- Server-side deletion when I change my master password (cloud storage often keeps file versioning around for extended periods of time)
- Access logging, i.e. making sure that it is architecturally very hard to download my encrypted vault from an unknown device without triggering some sort of after-the-fact notification to me
- Limiting API and service attack surfaces, i.e. not offering their storage as part of a suite with other services that have different threat models, such as photo and video storage (accessible to backend batch jobs to rescale/reencode the media for multi-device viewing etc.), data sharing and others
Just chiming in to say I've been satisfied as an Enpass user as well. Felt like a good middle-ground to me and I bought the app before the restructured their pricing model so I was grandfathered in.
For me, the usability of a password manager depends on convenient, secure password sharing that only seems possible with a hosted option of some sort. Granted, one or more of those options might be self-hostable, but that brings other complexities.
Completely against slowness, memory hogging, and discspace wasting.
…Okay, not /completely/. I merely whinge about it too much, and occasionally stumble upon some tiny gloriously responsive app that does what I need.
[Flame=ON]
But mostly I whinge. Like "Excel 2010 is so _fast_. Sure, newer versions do /some/ things faster, but even their startup time is so slow that I often consider whether it's even worth opening them to Do A Thing or worth closing them when I'll then have to wait for them to open again later.".
Hiding Electron's nature behind more hamsters (faster hardware) and bigger cages (memory+storage) doesn't seem to work for me.
[Flame=OFF]
Are URLs the only thing that's unencrypted? That's bad enough, but what about other fields? I know I've accidentally saved passwords in the username field before, stored sensitive info in the note field as well.
I guess moving off of LastPass is how I'll be spending my Xmas...
The only data I want my password manager to store is a single encrypted blob, and whatever information they need to store so I can safely decrypt it with my master password on my own device.
I don't think the other fields would be unencrypted. url makes some sense for an extension that doesn't need to unlock the vault to know if there is a password available for a site. it's not the end of the world but it certainly isn't a great look. look at bitwarden. the hn famous security guy tpatek or however you spell his handle recommended that a while ago and it's open source and pretty good. the ui kinda is not amazing but i guess that's alright. (it's 2022 almost 2023 how are they not letting you sort by recently created/used/etc?)
The notice uses language that implies that other fields were unencrypted too:
contains both unencrypted data, such as website URLs, as well as fully-encrypted sensitive fields such as website usernames and passwords, secure notes, and form-filled data
“Such as website URLs” reads like it’s giving one example among multiple other fields that are unencrypted.
Now I wonder if the notes are not in fact encrypted either since if the user wanted those to be secure too, they would’ve written them in a “secure note.”
If notes are unencrypted then I'm absolutely fucked. I really hope this isn't the case. I assumed they were, I thought I read they were even. But now I can't find anything confirming this.
A description of Lastpass's vault structure[1] suggests that notes inside entries were encrypted (index 4). I have no additional information about the veracity of that description though.
I agree the verbiage does make is seem that way but also the language could just be imprecise so we'd need a formal statement from them on it to know either way.
That use case seems to indeed be why they have implemented it that way, but I'd consider this a very poor risk-reward trade-off:
Lastpass isn't exactly (or at least was, when I last used it) perfect at figuring out which part of a URL is the generic part (used for identifying a login site), and which part is e.g. a session token or worse, a deep link that lets me access my account without any further authentication.
The biggest bummer is that it was said back in August that some shitty info was obtained by the hackers... few months later... sorry something else was also obtained. This is the worst. They should've scrubbed everything clean the dev had access to.
As a client, when your instincts kicked in alerting you that your passwords are in danger, you might've been patting yourself in the back saying to yourself: ok, my passes are safe, phew.
Unless I missed it they have left out the critical information about the timing of when the password database backup was taken. This makes enormous difference ... it could be that the attackers have had months to brute force this already if it occurred shortly after the August incident vs if it happened yesterday it is very unlikely they have brute forced many accounts.
If they don't know they should say they don't know, if they do know they should absolutely be telling people this!
I am also looking for this information. I largely switched away from lastpass over the last 12 months, and only a few low-value credentials remain in it. But if this is an old backup, then it is more concerning for me.
No need to brute force - if users re-used their master password, it will potentially cross-reference with the correct email and password combo from any number of previous data breaches and pwnage across the net.
They're still subject to economic considerations (assuming a non-state actor). If the expected value on a cracked account is less than the expected cost to crack it, a rational actor won't bother. That they may use cracked AWS accounts, or botnets, to perform this cracking does not change these economic considerations.
I have a gmail account tied to my phone (Android) and I've logged into that once and it just stays logged in. I don't use that account for anything else.
I don't really do anything else on my phone that requires a login.
Considering they answered a question, and weren't trying to provide a solution to 100% of consumers I don't see how its a problem warranting your response.
But likely 100% of the 1 user they were trying to support.
And given the varied needs of people, a suggestion that is reasonable to 5% of them is not bad going. And even 0.001% of them is infinity more than all the alternatives you've suggested in this thread thus far :-)
Correct. I do all of those things, but on my computer. Aside from not really trusting my phone, I find having a full sized screen and a real keyboard makes things immensely easier.
I use my phone mainly for text/SMS, and navigation/maps while driving, maybe watching YouTube if I need to kill some time. I don't really do social media at all.
As someone who finally moved to a bank that actually has web access/ phone app in 2020, its perfectly possible to live without using your phone for anything on that list. Hell I didn't start using my phone for medical/banking/travel stuff until 2020 and onward.
It's inconvenient, but possible. I'm in my 30's and I just largely avoided needing any of that because I live in a rural area and don't travel much. Of course I don't miss my old local bank at all.
Not OP but an interesting discussion to me as I also do not sign into much on my phone. To your specific points, and with the context that I have a working laptop and am home at some point every day:
Online banking - Discover has functional FaceID but every other bank/card app would reset my login on a regular basis and without MFA I don't trust short passwords. So the passwords are a pain to type and I only login to pay off cards once a month... I do it from my computer
Online shopping - Mobile UIs for this space suck, I'm never in a rush to buy anything, and I prefer uBlock Origin being active, so I use my computer.
Social media - Again prefer to have various add ons and a desktop experience, really just don't need this in my life more than a laptop at home allows.
Airlines, hotels, or other Tavel bookings - in my experience I've been able to get tickets into my digital wallet from emails and otherwise these apps are whatever. I traveled for 2 years and had various apps I barely used on my work phone, never bothered with personal phone.
Online news sources requiring accounts Eg hacker news, NYT, etc - just don't need in my pocket. I'll quick scroll certain places if it's been a while or I'm exceptionally bored but there's no need to be signed in.
Medical / pharmacy - I have my card in my wallet and calling for robot help is sufficient outside of that. Something in this space and others is if the call robot can't help then generally neither can the app/website and the best bet is a human which generally requires putting in the time with the robot first anyway.
I don't log into anything from my phone. Why would you? How is that unusual? It was within living memory that phones were only used to make phone calls. These days they're most useful for 2FA which is my only use case for having one. But hopefully if more services start supporting products like Yubikey, I'll be able to ditch the phone altogether.
Android app that integrates with OpenKeychain and a Yubikey. The Yubikey works with both NFC and USB. The same Yubikey works for SSH to sync passwords with the git server.
That’s a good solution. No third party managing your passwords, no Internet access needed, no apps from random developers, a short bash script with standard GPG, allows 2FA.
I've tried a lot the password safes/vaults, and none of them work nearly as well as Chrome/Googles password manager
You can even use it on iOS, and even use it by default. Even apples Keychain password manager works pretty well if you're all in on apple ecosystem. Only reason I see why you would not use it is if you're not using Chrome or Safari, which is most people.
The risk there is more you accidentally make a bad comment on YouTube and Google bans your account, I think. I have no idea if I'd still be able to access my passwords if that happens. At least, personally I feel Google deciding to disallow me from logging in is more likely than Google losing my passwords.
Is there a local UI to view/export your passwords? The only one I'm aware of is https://passwords.google.com but it's been a long time since I've used a builtin browser password manager.
also- does Google (or other browser devs) release information on how they keep your passwords secure? Is it even E2EE?
I think there are two options in Chrome's password manager. One is to decrypt with the computer's password. The other is to use your Google account authentication for decryption.
After years (a decade+?) of holding out on password managers I finally gave bitwarden a shot (based on recommendations here), and was able to import ~900 logins from google chrome.
Their UI in the chrome extension (brave browser actually) for changing/editing logins could use a little work, but overall I'm pretty happy with it. I even bit the bullet and now have passwords I don't actually know involved in everyday life. Irritatingly, uploading a video from GeForce's live capture to youtube - despite logging in with 2fa - caused a security freakout at google and now I was forced to change my gmail password.
But I digress, bitwarden even integrates with iOS's login management as another option to Apple's, though irritatingly not on OS X.
The amazing thing about this is, if at my company we had a project to migrate that much data, it’d take a month. There would be multiple layers of security to move through. How’d these ‘actors’ sneak in and get it all? I think they’ve had access longer than LP is letting on…
Why in God's name would they store the URLs unencrypted? Even if they don't crack the account password, you've just given the attackers a lovely dossier of every place I've ever visited frequently enough to make an account. And this is far worse than simply doing reverse-lookups of my email address across site breaches, since I use multiple email addresses and alias-only logins.
LastPass storing the URLs unencrypted is so mind boggling. What could possibly be the justification for that? Also -- LastPass is being intentionally unclear when they write
>stored in a proprietary binary format that contains both unencrypted data, *such as* website URLs,
What do you mean such as?? What else is unencrypted? Now is not the time for tip-toeing around this kind of stuff.
> LastPass storing the URLs unencrypted is so mind boggling. What could possibly be the justification for that?
I've never used LastPass, but if the URLs would be encrypted then checking "is there a password for news.ycombinator.com?" would require unlocking the vault, right?
So then you'd at least have to enter your password once on (browser) startup so it can load the list and keep that in memory, and you won't be able to automatically sync things either.
That's true when it's on the users device, but archived on their servers there's no need for any of the data to be unencrypted. Best case scenario it will never have to be accessed. Even encrypted with their keys would've been a better solution.
I use pass and this attack vector is why I don't sync even in a private git repo like many suggest. I do sync but only encrypted tar files, and even then some sensitve sites are aliases instead of URLs.
Sure it makes life a little more difficult but for some things convenience should be the last priority.
> So then you'd at least have to enter your password once on (browser) startup so it can load the list and keep that in memory, and you won't be able to automatically sync things either.
Correct. However this is how it ought to be. If someone acquires my laptop, I dont want logging into my accounts to be as easy as opening the browser
I created a temporary account to check whether anything of this has changed since 2018, but no, the format is still entirely the same. The fields have slightly different names, but that might be because of the way I got the vault file (looked at network responses during login). There are also four fields not listed in the above link ("Form Fields", "?", "??", and "???"), but those might be an artifact of the process of reading the file.
In particular all timestamps (creation, last modification, last access) are unencrypted, as are information about whether you want to auto-logon or auto-fill, whether the password was auto-generated and whether the password has been breached.
Field 6 "sharedfromaid": "aid of the sharer's Site/Secure Note" is unencrypted. The hackers will be able to infer relationships between Lastpass users.
Field 10: "genpw": "Is an auto-saved generated password". Good for deciding whether to brute force or not.
Yikes. I can't imagine why anyone would trust Lastpass after this.
Not to mention some of the saved URLs may include sensitive information in the URL query string, including things like email address, physical address, etc...
Each unique Bitwarden account has an encryption key derived from your Master Password, according to the methods defined in Encryption. This encryption key is used to encrypt all Vault data.
If you're a LastPass user, you need to be alarmed (and maybe even a little intimidated) by the recent security breach update revealing that threat actor was able to access and copy a BACKUP OF CUSTOMER VAULT DATA, including fully-encrypted sensitive fields like website usernames and passwords, secure notes, and form-filled data.
Didn’t everyone anticipate this? It’s still not a problem if you used a good passphrase, and haven’t reused it anywhere else.
It’s not ideal, but losing the encrypted blob isn’t that big of a deal if all the other parts were working correctly.
Lastpass claims user local decryption so they never had your key.
This isn’t that much different than logging in on a foreign computer, or storing your keepass on Dropbox, or losing a USB with the encrypted blob on it.
I’m not defending them, just being practical that this still won’t effect most users.
“all the other parts are working correctly”, is IMHO the issue here, because LastPass doesn’t consider the URL to be sensitive material.
What I think that means is in this breach the bad actor has your account information like emails and IP addresses used to access the vault, but can WITHOUT any brute force also determine every site the vault has an entry to access.
The consequences of that could be severe for some. Did you tell your wife about that account on Hinge or Grindr? Perhaps you live somewhere where being out isn’t an option and could get you killed? Do you have an account on some site or other which primarily exists to leak to journalists?
I did anticipate this... BUT and this is a big BUT... I didn't expect ANY of my stuff to be unencrypted! They keep saying that THEY CAN NOT read ANYTHING in my vault. Now the update says some of my stuff wasn't encrypted. This is way beyond acceptable. I know URLs aren't the worst thing in the world to expose. But the fact that ANY part of my vault is open is wrong.
I found a third-party description[1], which someone in another forum linked to as evidence that notes inside items are encrypted. None of the other unencrypted fields feel as high-value as the URL field, although some of them are clearly valuable, such as whether the password was autogenerated, whether or not there are attachments, and last password change timestamp, which is convenient for comparing against known breaches.
That said, I have no information as to the veracity of that description, except that others seem to be using the library it belongs to.
If you read any topic on password managers on HN, there is very little technical discussion, its emotional and grandstanding. A majority of the comments tell people why their password manager sucks and your scheme is the best. It's any tech religious war basically, with more sides. But yes, that's the point: the devs start with the presumption that the blob will eventually be stolen and how to protect that. That's the initial value proposition. (Storing URLs in plaintext was dumb, but any browser extension knows every URL you visit, same with your ISP, so there's that.)
Choice of password storage and deployment seems to be an intensely-personal one that seems less attached to absolute security; it's based on how much one is really willing to trust others, how much one wants to hear about security, how exhausted one is hearing about security... and a lot of confusion because, technical-minded or not, there are a more variables than I think any one human can account for.
It's stressful.
I gave up on making recommendations long ago. Because of stuff like this (the latest lastpass breach), I can't in good-faith recommend cloud-based password storage, but because I know most people aren't as willing to invest a ton of time, I also can't in good-faith recommend "keepass database on cloud storage using an innocuous .png keyfile stored elsewhere that you have to wget on every new device".
This is a wake up to call to not build your security model on a user chosen master password!
Since the vaults have been stolen, an offline brute force attack can be executed. This attack is no longer slowed down by online protection mechanisms, such as blocking IP addresses. Rather, security now depends solely on the cryptography and thus on the master password chosen by the user.
In the end, it is a single factor that separates the attacker from the encrypted data. If less IT-savvy employees are not adequately trained and supported in choosing the master password, the result is fatal. The extent of this will become clear in the coming months when the attacker has cracked the first master passwords and compromises accounts.
At heylogin, we believe that this security model of traditional password managers has come to an end. That's why we built a new solution that uses the secure element of smartphones to implement end-to-end encryption that is 2-factor secure by default and works without a master password.If our users' encrypted databases were stolen, the attacker would not be able to perform a brute force attack.
They talk about how the federated version is safer due to the long random master password, but...
Federated LastPass is tied to your company's SSO, which means your real master password is technically a login.microsoftonline.com (or equivalent) cookie stored in plain text on your hard drive that is valid for 8+ hours. One bad "pip install" typo and your teams' passwords are toast. That was true even before the breach.
I used to have a local only manager but then, obviously, syncing becomes a problem. And then it becomes a choice between syncing an encrypted blob using your own solution (potentially not very secure) vs using a provider who still treats your data as an encrypted blob with no access to the data and tries to do it securely. I think the provider is still more secure (again assuming the 1password access model not talking about LastPass-like providers) plus much more convenient. So if not 1password what would be a recommendation assuming syncing is required?
I switched to 1password after this breach was first announced, but I find it a lot more annoying to use (and I found Bitwarden even worse). Granted, nowhere near as annoying as the breach. Lastpass got in my way a lot less frequently though.
I’m on day two of converting from LastPass to another service (Keeper in my case.) Canceled auto-renewal, deleted the account, and exported/imported within a half-hour. That part was painless.
Resetting passwords, however, is something that’s going to take days. Too, you need to track what’s been changed or not, what’s no longer needed and so on.
Further if you’re being prudent you need to notify corporate partners of any credentials they own that may need to change. It’s an enormous waste of time.
The lesson: choose your vendors carefully. Take the extra time to make sure you never need to go through this.
Looks like I'm out $36. My LastPass subscription auto-renewed TODAY. But I obviously can't trust it, so I'm in the process of changing passwords and emptying my vault :(
Many of the URLs I have stored in LastPass included query parameters, no idea which ones are sensitive or specific to me, but my email, tokens, plenty of plaintext as part of form submissions, etc.
I spent time last night updating passwords, adding MFA to some of my lesser used financial accounts, and (importantly) replacing the URLs with simple top level domains.
From what I can tell from reading about this, it seems like people are mainly worried about brute-force password-guessing attacks. Lots of people pick lousy master passwords so there is the possibility of some real damage being done.
What I am trying to suss out is how worried I should be. My master password is a ~20-character mixed-case nonsense passphrase with spelling errors and digits thrown in. Am I being clueless about the threat level if I conclude that there’s a vanishingly small chance my stuff will get decrypted?
Ironically, “switch away from LastPass” was on my to-do list for the holiday week anyway, but now, just to be on the safe side, I guess it will be that plus “change all the passwords on accounts I care about.”
I'm pretty disappointed with how this has been handled. Mainly in two ways:
- The scale of the breach (leaking of PII and encrypted vaults, that URLs are not encrypted) has only come almost 4 months after the initial investigation. When was such a breach suspected in the first place? I would expect extremely timely reponses for this stuff.
- They suggest no recommended actions? Surely rotating credentials should be advised? Feels like they are putting business before security.
It's not just the leak that makes me lose complete faith in Lastpass. It's how they've handled the leak.
> It's not just the leak that makes me lose complete faith in Lastpass. It's how they've handled the leak.
Absolutely. I'm switching to 1Password, and though the critics are correct that it isn't a great solution (being practically the same solution), at least they haven't stabbed me in the back or weasel worded me...yet. I was a premium subscriber for the 2FA, for all the good that did me.
I'm no cryptoanalyst, but it seems to me that 1password's addition of the Secret Key, and encrypting all vault data, put them in a much better position than LastPass was.
AES256 is still secure, assuming the encryption key has ~256 bits of entropy (32 random bytes). Assuming your master password is reasonably complex, hopefully the encryption key derived from your password has enough entropy.
Despite this, I recommend rotating all passwords (if you don't have the time, prioritize rotating passwords on important accounts / putting MFA on them). For all we know, lastpass might have had a full compromise (i.e. access to unencrypted vaults from malicious source code commits).
Switched to Bitwarden a couple years ago. It works well for me. Mostly use the Chrome extension and I don't host it myself. Works pretty well with my iPhone as well. and I'm using the free tier.
Every time you use lastpass to autofill a form. The log your ip adresses, a timestamp and the site you were logging into. Kinda sounds like the attacker got this data.
To add more data to the other comments, some federal agencies started pushing employees to use lastpass for work-related accounts a couple of years ago.
I was and am continuing to be a LastPass user. I’ll probably start looking into migrating but not with any great hurry because I never trusted any password manager that much to begin with - never stored my primary account passwords or financial account passwords with them for this reason. Password fatigue is real but not all passwords are the same so why treat them as such?
Does Lastpass have a requirement on the length of the master password?
Documentation says they recommend 12 characters as minimum, which seems short. Wondering if its enforced or if it's possible to have "password123" as master password?
Also, sounds like URL leaked in clear text - so targeted attacks will be very likely. This is quite bad with long running implications.
Maybe now I can convince my employer to move away Lastpass. I hated it on sight because of the GUI. Look at this thing, it's like Attack of the Fifty Foot Whitespace:
I wonder why people moved away from a (local) KeePass database that is optionally synced through GDrive, OneDrive or NextCloud between their devices. That works perfectly fine and relies only on your KeePass master PW strength, not on some 3rd parties' security
If you want be into control, host your password database on your device only. Use applications like Keepass(XC) and Keepassium. Optionally sync via a generic cloud provider which is protected by a strong password and two factor authentication.
I use Strongbox, a standalone database password manager. My wife and I share a database in iCloud. The database supports concurrent access/syncing and works quite well to share passwords between us.
I trust in crypto to keep me safe. My key is derived from a pass phrase + HMAC-SHA1 digest of a shared secret stored in write only memory (Yubikey, Secure Enclave). My wife’s phone has the same. Our shared mac also has the same.
I could probably host my database on a public AWS bucket and still be safe (120 bits of entropy in the password).
You need a separate database for that. But on those SaaS services those separate folders are also not necessarily safe of encrypted with the same master key.
I use a secret algorithm + common salt that I can perform mentally to derive more-or-less unique passwords from service provider names. I don't trust any password manager, and this gives me the convenience of knowing my password across devices.
Not the person you were asking but I have a mental algorithm I use that produces unique salt for each website. When I run into issues about special characters not being accepted, I replace them with the number equivalent. For example 5 instead of %. It can be a pain to forget but there aren't many sites I use that are like that.
I still use a password manager I can reference if my algorithm isn't working for some reason.
Is it easier to guess the master keyword if some of the encrypted passwords are known to the attacker? Because on dozens of (previously hacked?) "unimportant" sites I still used a very week common password.
I quit Lastpass about a year ago and at this point I really hope they actually deleted all my credentials and not just pretended to and hid it somewhere else.
I think if you’re moving between password managers, probably best to assume they did retain a backup, that said backup was leaked, and given LastPass does NOT encrypt all aspects of the vault, that you need to go ahead and roll almost all the stored credentials.
Similar to “not your keys, not your crypto” is there not an analogy to be made for passwords? Genuinely interested in the reasoning of people who store their passwords in a cloud service they don’t control.
It's your keys. The master password is yours only. Plaintext passwords don't exist in remote services; basically they're a specialized version of a storage system (Dropbox?Google Drive? S3?) optimized for password entry sharing between devices, versioning, etc.
But there's actually a lot of surface attack area for those open source tools as well. If you're able to sneak into the supply chain and replace the _client_ with a modified, malicious version, you can make it send the master password AND the database to a remote server. No need to compromise the server. This is true for most commercial password managers as well: but I'd expect the security to be tighter there. No random maintainer should get access to the release page.
My idea was like this:
* Use KeepassX built from source
* Use Dropbox to sync the kdb files (always encrypted)
* Use a firewall to prevent any network connection to keepassx; this way even a compromised client cannot connect and send the data somewhere else.
* When updating KeepassX, always build from an older git commit; I assumed that in ~15-20 days if there's a fuckup on git source, it will be announced.
BUT: it was hard. Bitwarden just works better. I still build it from source on desktop computers, though, and take a look at the website before updating, just to stay sure. (And I think IOS app process will make it harder to submit malware there anyway).
>If you're able to sneak into the supply chain and replace the _client_ with a modified, malicious version, you can make it send the master password AND the database to a remote server
I've heard about this as a possibility for as long as I can remember, but while this remains a possibility, major online providers get hacked every year or so.
Major providers are more valuable targets because the potential loot is bigger.
I wonder if major providers are also more likely to detect intrusions. This is the part that concerns me about non-cloud alternatives. For example, if KeePass got compromised, how long would it take for us to learn about it?
(Although I don’t have much faith left in LastPass, and I don’t have strong reasons to think that 1Password is better since as an outsider to their operations I know just about as much about either.)
By that logic you also wouldn't know if your keys/password database stored by Lastpass/others (in the browser extension or app) is stolen, it's all just local data.
@dang, could the title be updated to indicate that this is another update to the existing blog post? Currently reads like it's a new incident, not the aug2022 incident.
It absolutely is a new incident. LastPass is in PR damage control mode and trying to make it seem like accessing those backups was inevitable after their source code theft, but it's not the fucking case.
This is yet another failure on LastPass' end. The only thing in common is the attacker, that's it.
They updated the fifth paragraph down to mention that encrypted passwords and unencrypted metadata has been stolen - in my mind that practically qualifies as a new incident
tbh even "Notice of Recent Security Incident [updated]" instead of "LastPass User Vaults stolen in recent hack" or something feels like PR damage control in favor to LastPass
I agree that corporate press releases usually bury the lede and, in the case of negative stories, are often outright misleading. For that reason we often change them (https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...). I've used your suggestion above. Thanks!
If anyone suggests a better title (i.e. more accurate and neutral), we can change it again, and if there's a better third-party article that covers whatever the latest news on this is, we could switch to it.
I use a password database (a file, local) which is unlocked with a passphrase/word. It takes about five seconds to unlock. This works for me since I almost only use accounts on laptops/desktops.
I'm sorry but if you were using this why are your passwords in the cloud? Doesn't that whole concept set off like thousands of alarm bells in your mind about how it could go wrong?
I know it's convenient or whatever, device synchronization or whatnot but compromising security for convenience is a thing I thought we might have been aware of avoiding at this point.
No option to "select all" in the list so I resorted to clicking the check box on by one down the page. I accidentally slightly clicked outside a check box... guess what? Everything gets deselected.
Start over.
Ok start again, maybe I want to list in alphabetical order rather than group by category to minimise mistakes. Whoops, selecting that option deselects everything in the list.
300 odd deleted in batches of 30-40.
When a company's whole application is covered in anti-patterns and dark UX to make it as hard as possible to leave then companies like this deserve to die.
Deleting the account is a bit tricky too.
1. Go into account settings in the top right drop down 2. In the Links area click on "My Account" which spawns a new browser window 3. Click the red "Delete or Reset Account", you can't miss all the red buttons 4. You can either reset your account or delete, choose delete 5. A modal will appear telling you stuff, enter your master pw, a reason why your leaving and then click delete 6. You will be asked twice if you really really want to do this 7. Press ok