LastPass user vaults stolen in recent hack
blog.lastpass.com
blog.lastpass.com
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
You should absolutely be able to crypto-shred your data from such an important service. This experience sounds awful.
I remember deleting my acct. not sure if I manually deleted entries before though.
That said - if a data breach includes backup access… is your account ever really deleted?
<button class="itemCheckbox" tabindex="17" aria-label="Select"></button>
“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 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].)
[1] https://www.ctrl.blog/entry/keepass-file-conflicts-android.h...
Also make sure to go to Advanced Options, View Deleted Items, and purge them from there.
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.
I hate Lastpass so much.
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…
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.
for (item of document.getElementsByClassName('vault-item-displayname')) { item.click() }
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.
This is literally the best case hack scenario.
Why? Because we already know that encrypting something using their strategy is essentially uncrackable.
AES256 is quantum resistant.
The worst case would be silent exfiltration from the LastPass application via malware to steal user master passwords.
In the security game, the crypto is the strongest part, the crypto-system is the weakest part.
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.
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.
[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]
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.
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.
"It's already out there so we shouldn't bother preventing it from spreading further," is a terrible argument.
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.
"Zero Knowledge" should join "Full Self Driving" in the malicious marketing hall of fame.
That definitely cannot be true since they were storing URLs in vaults unencrypted. Seems like a class action lawsuit waiting to happen.
That's real bad - think blackmail material for important people.
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.
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.
Please Refer back to “If you take the most popular 1M passwords and attack the master password…”
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.
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.
More info at: https://blog.elcomsoft.com/2020/04/breaking-lastpass-instant...
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.
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?
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.
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.
[0] https://blog.korelogic.com/blog/2016/05/19/linkedin_password... [1] https://www.trustedsec.com/blog/introduction-gpu-password-cr...
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.
A good starting place is https://github.com/danielmiessler/SecLists/tree/master/Passw...
> 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.
Afaict They use pbkdf-sha256, with 100k rounds. which is not bad, but i think a memory hard function like argon2 would be much much better.
So its not terrible, but its not amazing either
> 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.
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.
This is why a company’s bug bounty should be the sum of the assets protected by the data they have, for all their customers, minus $1.
Sounds crazy? Don’t store all passwords at the same place.
Early on, they only did 500 rounds of AES which significantly weakens you even with a strong password.
So, I've had to change my master password and now I'm in the process of updating all my passwords :(
By not forcing a re-encryption when they uped the number of rounds, LP has hung all their old time customers out to dry with this leak. It's not ok.
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.
Can someone confirm my understanding that 1Password does in fact encrypt the entire vault, including the URL/domain associated with each login?
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
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.
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.
[1] https://blog.lastpass.com/2015/06/lastpass-security-notice/
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.
This kind of meaningless voodoo is a big red flag for any "security company".
This company is a joke.
Also frustrating that they decided to drop this update on December 22.
And how do they square "Zero-knowledge security" and the diagram in https://www.lastpass.com/security/zero-knowledge-security
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 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 big question with this is of course if 1Password's sausage is made any better.
https://support.1password.com/secret-key/
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.
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."
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.
…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]
> 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
I guess moving off of LastPass is how I'll be spending my Xmas...
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.”
Lastpass, please advise
[1] https://github.com/cfbao/lastpass-vault-parser/blob/master/l...
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 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.
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.
Well...
If they don't know they should say they don't know, if they do know they should absolutely be telling people this!
Either rent some machines from an ex-crypto miner, since AES can be decyphered on GPUs or get some old extremely cheap boxes from the hetzner auction.
https://www.passwordstore.org/ actually.
I don't trust any cloud-hosted password manager.
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.
So your solution is unreasonable for 95% of consumers. Nice.
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 :-)
Online banking
Online shopping
Social media
Airlines, hotels, or other Tavel bookings
Online news sources requiring accounts Eg hacker news, NYT, etc
Medical / pharmacy
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.
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.
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 do online banking on my phone. I use a payment app which requires a pin.
I hate doing tasks on some touch screen.
It is my dream to ditch the phone. I would replace it with a yubikey in a heartbeat
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.
Yeah, yeah, google evil
also- does Google (or other browser devs) release information on how they keep your passwords secure? Is it even E2EE?
chrome://settings/passwords
To your second question, I don't know, but thats only a concern if you export your passwords
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.
In any sane world that would be an unbelievable thing to say, yet entire companies exist with just that intention. Behold the power of marketing.
Nice. Fucking. Job.
From: https://bitwarden.com/help/account-encryption-key/
Seems crazy for anyone to keep using LastPass
>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.
weird term for std::vector<std::string>
https://github.com/cfbao/lastpass-vault-parser/wiki/LastPass...
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 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.
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.
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 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.
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.
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?
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".
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.
[1] https://github.com/cfbao/lastpass-vault-parser/blob/master/l...
Apparently URLs are not encrypted, and they also have non encrypted fields about "password breached" and "password poor quality"
> Too much work. At that point, it’s easier to just hack the LastPass servers.
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.
I just wrote a post on our company blog about the problems of LastPass and how to fix these: https://www.heylogin.com/en-post/lastpass-incident-2022
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.
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.
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.
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.”
- 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.
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.
What's best way? I assumes steps are to: 1. Import lastpass stuff into 1password. Rotate all passwords?
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).
[citation needed]
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.
How is the data encrypted at rest? Who’s master password is used to store that data?
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).
Also, happy and safe 2023!
What happens to your algorithm if the password requirements reject special characters?
I still use a password manager I can reference if my algorithm isn't working for some reason.
I never reuse passwords of course but it's still annoying having to go through everything and change a whole bunch of passwords.
Why the fsck are they storing these unencrypted? This is data mining _and_ phishing gold.
What a clown show.
... But I never trusted a third party to store all my passwords.
That's all I'm gonna say about that.
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).
> you can make it send the master password AND the database to a remote server.
I wish it was easier to completely restrict an executable from ever touching the network. Like, point and click.
Now, there’s ways around that (open the browser and a long hyperlink of secrets), but yeesh, it should be easier to block the direct links.
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.
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.)
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.
This is yet another failure on LastPass' end. The only thing in common is the attacker, that's it.
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.