> If you had a legacy 5000 rounds or 10000 rounds, the # of rounds can't just be increased server side. Changing that would mean a new key is derived. So older users likely still have a pretty low number of pbkdf2 rounds which makes them more vulnerable to brute forcing
Kind of unclear but i think this implies that lastpass doesn't do some and reencrypt on login. Are they saying its just people who havent unlocked there vault in a decade, or are they saying all old users have this? If the latter this is really poor design.
> Lots of vault entries may be encrypted with ECB mode AES-256.
Wtf wtf wtf. This would be considered wildly insecure even by the standards of the 80s
I just checked my old account and it was configured to be 5000. I changed it and re-encrypts the data and uploads it, and then forces you to login again, presumably to do server side part.
Seems weird that they would have the number of rounds fixed from the time of account creation though. Surely it would be possible to increase the number of rounds over time.
Edit: I should add that I have logged into this account within the past year or two. So if they're supposed to increase over time, it ain't worked.
It's also not really an obscure issue. For example, the owasp password cheatsheet talks about the need to increase the work factor over time - https://cheatsheetseries.owasp.org/cheatsheets/Password_Stor... . I would hope that password manager software would at least know the things that end up on "cheatsheets"
100% agreed. Paying for a major brand password manager, you should assume that you are paying for them to always keep the security totally up-to-date with best practices. The idea that you are somehow responsible for finding an obscure setting not just in "Account settings" but in a separate "Advanced settings" that defaults to hidden, and knowing the appropriate number to set it to, boggles the mind.
“Yes,” said Arthur, “yes I did. It was on display in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying ‘Beware of the Leopard.’”
There’s an entire novella of Arthur just finding this notice, right? It could be serialized into three one hour episodes of Dent, queuing & requeuing and just talking to others inqueue.
Keep in mind that this is a trade-off, it requires more computational power AND battery, so giving users access to the leavers makes sense (e.g. power users with nice equipment can pump up the number).
That being said I do agree that it is up to the vendor to set AND enforce a new higher minimum. If someone logs in with 5K rounds, it should be changed to the new default (100k).
On a related note Bitwarden also allows users to configure this. I recently increased mine to 150K rounds.
I think it should allow you to change the schedule on which it increases the rounds, not set the actual number. It should tell you how many rounds it currently is at and how it will increase but the setting most people will want is High Security, Very High Security, Ludicrous Security.
Because changing the number of rounds requires reencryption and it doesn't sound like they had a workflow for prompting batch reencryption other than through the setting.
Ideally they'd manage that number and prompt the user to change it over time.
Because different hardware will have significant impact on this number. You need to figure out your tolerance. Maybe your tolerance is higher than they expect - cool, bump it up. I did that many many years ago, thankfully.
Yeah I was a daily user until about a month or two ago. Didn't even know about this setting, and I still haven't figured out how to change it in the mobile app. But mine is definitely set to 5k. Still in the process of changing all my passwords...
This is pretty wild. When you rotate your master password and it re-encrypts everything, that's a perfect opportunity to use a new iteration count. If they didn't want change the value for user's who were at an old default value, they at least could have nagged "your account is using an old/low value for an encryption setting, click here to use the latest recommended default"
Of course, changing it now won't do any good with regard to previous leaks.
They could have changed the setting any time the user logged in. I pointed out that they used too few rounds over a decade ago, I believe. To their credit, they increased the limit to 256K in response (it was much lower before).
> Seems weird that they would have the number of rounds fixed from the time of account creation though. Surely it would be possible to increase the number of rounds over time.
Well, No. In metacode, pbkdf2 works something like:
Point being, you can only change the number of rounds if you re-encrypt the vault, and you can only do that, if the users participates by giving their password to first un-encrypt it during that process. So it cannot be done silently in the background.
Agreed, it requires user-participation. However, LastPass could be proactive about this, perhaps including the number of rounds in its security check. It could tell you that your legacy account should be updated and guide you through it. That would be helpful. I have the standard 100,100 iterations, but had no idea that this was a feature I had to keep track of.
There is no "big difference" here, and it could be done trivially during login. The fact that it would be done client side instead of server side is a very minor implementation detail.
You don't need to re-encrypt the entire vault, just whatever you're using the PBKDF2-derived key to hide. In most situations, you'd use it to encrypt another, separate key. In that case, it can be readily upgraded at any time, including during login.
Conceptually, it's not very different from how password hashes are updated, just that you need to re-wrap some other key as well simultaneously. Since the rest of the vault is unaffected, it's OK if the transaction fails: the old parameters will work with the old wrapped key, so all you need to do is ensure that the transaction is atomic. (Usually don't even have to do anything to ensure that if you just use the same database table/object.)
The original vault format seems pretty badly designed (unencrypted URLs, low-ish number of rounds even for the time, and of course ECB). With this shoddy design, it's hard to expect the developer to be smart enough to add an intermediate random key.
And it's probably a good thing the original design didn't have that — I'm pretty sure Crypto.getRandomValues() wasn't available on all browsers yet when LastPass was first release it's JavaScript version (not sure when that was — I've never been a LastPass user).
Of course, the format itself can also be (and should have been!) transparently upgraded. Interrupting legacy users just once for a 20-30 second upgrade of their entire vault is a no-brainer. The fact that LastPass hasn't proactively upgraded old vaults on login during all these years reflects very badly on their security.
I'm aware you can't do it silently in the background. But they can prompt the user to input their password. And you're already prompted when signing in on different devices or at regular intervals when the vault locks. Seems fairly easy to me from a UX point of view.
> Point being, you can only change the number of rounds if you re-encrypt the vault, and you can only do that, if the users participates by giving their password to first un-encrypt it during that process. So it cannot be done silently in the background.
I think there might be a way to update it without having to wait for the user to supply the master password, at least if their web login works like most, although it would require some additions to the database and their server side vault storage.
According to the documentation I found the master password you create when you make your account is the master for both logging in to your account and for encrypting your vault.
To handle its use as a login password they probably have a table somewhere that contains:
email, salt1, hash1(master_password,salt1)
I'll assume that they want to update both the login password hashing difficulty and the vault decryption difficulty.
To handle updating login hashing they could change that table to contain for accounts that have logged in or been created after the difficulty change:
email, salt2, hash2(master_password, salt2), NULL
and for accounts created before the change that have not yet logged in:
For the vault storage, they'd have to change it so that instead of just singly encrypted vaults, Encrypt(vault, derived_pass), it can also store doubly encrypted vaults, Encrypt(Encrypt(vault, derived_pass), derived_pass2).
When they do the change, they would change existing vaults to double encrypted, with derived_pass2 = hash1(master_password, salt1).
When someone logs in for the first time after the change, they supply master_password. The server would see from the login hash table that salt1 is not NULL meaning they are an un-upgraded account. It could then compute
and see if that matches the hash in the login hash table. If it does the login is successful, and it can (a) generate a new salt and update the login hash table to contain:
and (b) use hash1(master_password, salt1) to remove the double encryption from the vault, use master_password to decrypt the vault, and then re-encrypt with a new derived password with the new upgraded work factor.
NOTE: the above is based on documentation of theirs that says you use the master password for logging in to your account. However other documentation of theirs says that the master password is never sent to their servers.
My account is very old, but this was hidden behind advanced settings.
And I have used this account daily since I created it. Not having this increase from their end seems very unprofessional.
I have a really old account (pretty sure I started using it ~2010) and I use lastpass essentially daily. I've never looked at that setting and I see that mine is set to 100,100. So it's migrated sometime. But I do also have some vague memory of a lastpass incident years ago where there was a prompt that they wanted to re-encrypt everything preemptively.
> Wtf wtf wtf. This would be considered wildly insecure even by the standards of the 80s
You aren't wrong, if true that's certainly a mistake on their part. Practically speaking though as long as the passwords are randomly generated it probably doesn't matter, i.e. if you think about what the IV and chaining are doing in CBC. ECB is just as good for encrypting a random stream of bits; CBC just makes sure the bits are random before passing them into the cipher. Of course the optics are still terrible.
1. In real life, passwords aren't random. Password manager users are probably less likely than average to make this blunder, but I'd still be willing to bet _the majority_ of lastpass's customers do.
2. Even if you personally have all random passwords, would you really want to use a product made by people who made this level of a noob mistake? I used to pay for LastPass premium, now my account is deleted, my passwords are changed, and my money goes to Bitwarden instead - and every time I hear about Lastpass I don't regret this decision.
I suspect that even non-random passwords here are fine, again practically speaking (edit: and given certain assumptions, to be clear, like no reuse), but haven't sat down and proved it.
Obviously this isn't an endorsement of LastPass. Everything about their protocols is disappointing. Even if the encryption issues turn out to be of the well-that-was-a-dumb-choice-but-you-don't-need-to-panic variety, it's because they got lucky, not because they were good.
> and given certain assumptions, to be clear, like no reuse
Maybe I wasn't obvious enough, but this is the problematic assumption. When I say "non-random password", that's what I mean: a reused password.
Almost everyone I know reuses passwords (sometimes with a slight variation, but 90% of the password the same), and my day job is a software engineer. I'd be willing to be at least half of Lastpass's users have at least 1 reused password.
Reuse of what? If you're assuming the attacker already has a valid password, the list of URLs they use it also irrelevant, as is the password vault. Just do what real attackers do and hit every single known login page on the Internet with it.
If the attacker doesn't have the valid password, the knowledge that two different sites share the same password isn't exactly game-changing. And if the attacker does have the password, they'll figure out where it works regardless of access to LastPass db.
It's not nothing, and it's weird to be strident about it, but the obvious problem here is the offline cracking of the vault passwords; this isn't worth arguing about.
> It's not nothing, and it's weird to be strident about it
To an outsider, hearing people talk about how LastPass used Very Bad ECB mode makes it sound like a fuckup with immediate and dramatic effect on the security of their passwords, that isn't exactly true.
Nobody should have been using LastPass, but we can still be realistic about the threats facing those who did.
> but the obvious problem here is the offline cracking of the vault passwords; this isn't worth arguing about.
Of course not, but that's a completely separate issue from their choice of AES mode.
Knowing you reused the same password between your Amazon and $CompromisedWebsite accounts (but nowhere else, maybe you set them up the same day) gives attackers a significant advantage over having to try every password they have on every website.
I don't think this is a significant advantage, the cost of an incorrect password attempt is essentially zero. Trying "every password they have on every website" for an individual will still be a very small set of passwords to try.
I could see password reuse being used as a reason for trying brute force/dictionary attacks. E.g. You see that a user has used the same password on Coinbase as X, which could indicate that the user isn't using randomly generated passwords and therefore be potentially vulnerable to such attacks.
Attackers generally aren't targeting a specific individual, they got a dump of X million passwords from some compromised website. Being able to connect those directly to working accounts rather than having to burn IPs and get them rate limited and/or banned trying duds _is_ valuable information.
If you have some attacker after specifically you, yes this information is of less use to them, because they will have tried every password of yours they have on every website already hoping you reuse passwords.
That was a hasty edit on my way out the door this morning. Reusing a password doesn't make it easier to decrypt here, it just helps with some secondary tasks, like validating decryption output (since ECB isn't authenticated). This is rather indirect, though -- not a great example. A better example would've been the password fitting in a single block (<= 16 characters).
The reason I suspect even non-random passwords might be mostly fine[1] is because there's no oracle and passwords are generally short. There's not much there for someone to hang their hat on. It's only a hunch, though; if tptacek for example says something different, I'd believe him.
1. Meaning: No need to cancel Christmas. You can deal with it later. Not meaning: ECB is as strong as CBC or whatever.
The whole point of a password manager is so you don't have to remember passwords. Why wouldn't you use unique random passwords? It even generates them for you.
this would bite me in the worst possible moment when i need to login to somewhere and i lost my phone/battery dead/company hacked/etc.
i have been using keepass(xc) since it's been around and i dont use random passwords. every year i create a formula that creates all my passwords and i put these in the vault. it also enforces password rotation. losing the vault i can still come up with any of my psswords just by remembering the formula.
for company server services it's a different story, i generate wholly random strong passwords and store them in the offline vault.
At least in my case, the first time I used a password manager it learned my existing ones from my browser, and many of those were non-random. From that point forward I used generated passwords, but I'm sure I still have hundreds of legacy ones that I didn't bother to go and change because the sites didn't matter that much to me.
It’d be nice if, when I logged in to a site, my browser would casually mention if the pw is reused, or not. Now-a-days, I just habitually check my pw on login to make sure it’s random. For the SO & kiddos, I manually reset all the financial & identity defining pws (Google, Amazon, FB).
If you create some new account on mobile, the workflow is messy. If you are on schedule like ordering a ticket, you just quickly try to get the job done.
You need to know the specific order how to create the password for a new site. Otherwise it was just easier to plow through with your favourite memorised combination.
At least I found it hard to do with Lastpass on mobile. Now I’ve tested it with Bitwarden and 1Password 8, they seem to do a better job with it.
Also it’s not clear that the same AES key is used for all secrets. If it’s URL- or tag-derived using the master password then it’s only bad for long secrets (more than 32 bytes) that aren’t random data.
I think the main thing is there are no benefits to ecb here (other than laziness), it would be trivial to do it properly, and is suggestive of thei general practises.
Also, I've just learned that the quintessential file has been recently replaced. I understand the need for a higher resolution file, but I'm still a bit sad.
... actually that might be a "feature" for them, they do have duplicate password report, I had assumed that's just based off decrypted ones on client side but they might be just using ECB for that
ECB mode somehow still gets used, Zoom also did it. I think this is a result of many developers not knowing much about encryption and then selecting the simplest option from their language's standard library.
Zoom at least has the excuse that its more convinent if you are possibly dropping frames and need random access decryption (still really not acceptable). LastPass does not even have that.
CTR with no authentication is strictly better than EBC with no authentication in that case. Similarly, CTR-then-MAC (with MACs being e.g. per packet) is strictly better than EBC-then-MAC.
Missing (or duplicating) a block in the CTR (counter) block cipher mode messes up the alignment of the count. Then everything after that comes out as random garbage.
As long as you simply transmit the count in the packet this is not an issue. You mostly have to do that anyway, because packets can be reordered and you want to stitch them together in order (with holes).
Missing or duplicating a block anywhere in a ciphertext should completely prevent decryption; that's how authenticated encryption works. The idea that some cipher modes are more or less resilient to corruption is, for the most part, a discredited 1990s idea.
In this setup we want to be able to decode a cipherstream with holes into a plainstream with holes. This is very much possible with CTR-MAC, as long as MAC is done on some finitely-sized segments.
How is AES ECB even possible? You would have to actively choose to do that. It's more effort than something like libsodium.
Have they not heard of the first rule of crypto being "You probably aren't qualified to do it, use libsodium or TLS or SSH" yet? Why are they messing with cipher modes themselves?
Their encryption code predates libsodium, and ECB was (on many platforms still is) the default mode --- also, the only mode that doesn't require confusing extra parameters.
b) Browser extensions used to be completely different. You needed to call out to native code to do tons of stuff because the JS apis were extremely limited and slow. So it was either "roll crypto in JS" or "make users install a binary", the latter stopped being possible over something like a decade ago.
>Wtf wtf wtf. This would be considered wildly insecure even by the standards of the 80s
For this particular use-case? Hardly.
Since an attacker can easily use any login form of their choice as an oracle for password reuse, ECB mode can't really introduce significant issues here.
These vaults conveniently come with unencrypted URLs of the login forms associated with each password. An attacker who discovers the plaintext of one password can trivially attempt to reuse that against all of the forms.
Incorrect password attempts are essentially free, so ECB revealing reuse does not meaningfully help the attacker.
But for the attacker to try one of my passwords in a login form, they do need to have that password cracked already, which means that they already have my master password. But if they have that, they can decrypt all of my passwords, and the login forms are of no use.
No, not at all. The point is that while ECB is a silly choice, it does not make it easier for the attacker to crack your vault. It does allow the attacker to see if you're reusing passwords, but does not reveal to the attacker what those passwords are.
On the other hand, If the attacker were to discover one of your passwords from another source, they'd be able to confirm reuse anyway by simply attempting to use that password on other websites.
This is such a non-issue. You build in flags in the clients that are server activated "needs-reencrypt". After login (local client) flag is read from server and logic begins. You notify the user their vault needs stronger encryption. They can choose to continue and enter password, skip for now or ignore for 1 month (or something more reasonable).
The point is you explain why you do this. Start the message with "We care about your encryption" and go from there to explain that they need you to upgrade because the don't know your master key, they need your help to do it.
Adding this kind of behavior should be their core business. Apparently it's not.
You can, I was working on solution to have hashing 2 times - new, and later old algo. Salt can be either reused or you'll have to use 2 salts for each algo.
Yeah I don't know how "old" it has to qualify for the iteration upgrade but I've heard of some people still having it as 5k iters even with an active account
Off on a tangent here, but I downvoted this comment because it doesn't really add anything. On what basis can you confirm it? Do you work there? Do you have deep expertise in the domain?
A straightforward reading of their comment is that they can confirm because they have an active account with 5000 iterations. That would certainly explain the frown.
It's not like you need to work at LastPass or have deep expertise in the domain to look at your own account.
You shouldn’t use a weak password in your password manager, and rely on KDF. Even if the server is not hacked, the company could snapshot vaults and crack them offline.
Why would the company want to crack your vault..? If they want your logins they can just push an update on the client app that skips encryption altogether.
Because a company is not a single entity, rather hundreds or thousands of peoples. Some of them may wish to get your passwords, for instance, a disgruntled employee who might want to publish large number of passwords online (or provide access to attackers).
Yes, they might also use other techniques as well, for example, push a bad update if they have such privileged access. However, that’s relevant more in targeted attacks; you can’t really push a bad update to everyone before getting caught quickly. Also, often several people have to sign the code (in the case of non-JavaScript code), and there is log trail.
While I agree with you that users should have a strong master password, the vendor is in a really privileged position and could do much more than just attempting to crack vaults offline.
Why bother with cracking the vault when you can just modify the javascript sent to report back the master password? Especially if you only do targeted attacks, and/or heavily obfuscate the phoning home, the chances of getting away with it is probably pretty high.
That's why I hang onto 1Password - at least on macOS and Safari, the browser extension just calls the native client - the actual UI (where you enter your master password and then select which credential to auto-fill) is managed by a separate process. The worst a compromised browser can do is prompt the UI to display and provide a suggested domain to pre-select.
Unfortunately I believe that’s Safari-only and even then they seem to be aiming to move away from it - all non-Safari extensions are a “fat” client called 1Password X where the entire logic (and thus the sensitive data) is within the browser.
Interesting. Something that is off putting regarding lastpass is the complete lack of a native client, it strikes me as pure laziness & complacency. Maybe lastpass does in fact run natively, outside of the broswer, but requiring a web browser is ridiculous. I'm aware there's a native app for windows, but it's horrific.
We may not be seeing the whole picture yet, but very concerning that the dev environment had access to Production database backups stored in a manner that was easily decrypt-able :/ The whole point of a Dev environment in a security focused company is that you reduce the surface area for access and failure.
Re: dev environment containing database backups, here’s the full text on that point from the blog:
> some source code and technical information were stolen from our development environment and used to target another employee, obtaining credentials and keys which were used to access and decrypt some storage volumes within the cloud-based storage service.
It sounds like they didn’t literally have backups in the dev environment (which would be absolutely terrible if they did).
I’m guessing they learned enough about the architecture from the dev environment to social engineer their way into getting someone to give them credentials to production.
> dev environment had access to Production database backups stored in a manner that was easily decrypt-able
Say what you like about old dinosaur companies like banks, but when I worked in the IT department for a bank back in the early 2000s developers absolutely couldn't touch production systems, data or backups. Ever. They always has to go through ops even during major incidents.
Of course banks aren't immune to fuckups, but at least on paper they tend to have sound security policies.
Startups are great at moving fast because there are no guardrails. Like lemmings, corps, banks and government entities externalize their risk to the third party because they recognize the name and logo. "Should we go with SecureCompany(tm)?". "Yeah, everybody uses them".
It's great for startups. Without red tape and heavy policy your lean team can create products that the hamstrung bigcorp could only dream of (just don't look under the UI!). They slowly build their customer base, and when they're ready to IPO, they run through some security and process certification theatre, and the investors and a handful of executives can make billions.
Overall, both sides seem to be happy with the situation. Bigcorp gets to cut tech staff and outsource, and they have a convenient finger to point when the regulator asks questions. The SaaS apologises and maybe loses a customer or two, but based on stock prices after major issues like this in the past, nothing bad really happens.
How many programmers work on last pass? From a solo coder with no specific interest in cryptography I wouldn't find this kind of flaw odd.
From a large development team whose sole product centers around encryption? It seems strange to get it this wrong. What leads to that might make a good business case study.
It's not a large development team. I moved away from them years ago because support for FIDO keys for example was always "coming soon" and still isn't there. They've been coasting for years and this breach doesn't surprise me at all.
Yes but they don't support the WebAuthn/FIDO2 standard. The Yubikey option they have is less secure because I think it's OTP under the hood, so it doesn't protect against phishing.
Interesting, my intuition is exactly the opposite of yours: I'd expect a solo coder to get it right more than a large organisation full of people with different incentives and priorities.
Exactly, these flaws feel like the kind of thing that pops up due to a conflict between product UX people and security people. Surely they had at least 1 engineer who was aware that unencrypted website URLs, EBC Mode, and not upgrading work factors was a bad idea. They just likely lost out to some product owner who thought displaying favicons, detecting reused passwords on the server, and not bother the user to upgrade on login were more important than security.
At big companies, too often do the people in charge of the product seem to forget what core product really is.
I suspect most of the work of a password manager goes into the other features. At one point (not sure if they still do), Lastpass had a feature that could auto-rotate passwords for you for select sites. From watching it attempt it once or twice, it looked like it was done with scripted screen-scraping which must have been tedious to develop and maintain. Also providing form filling functionality seems like it took a lot of work.
Not encrypting the URLs is just such a baffling choice, i honestly don't understand how that ever happened.
Also, as far as i can tell with some very basic maths based on running hashcat on my 3070, if you have a big long password on your vault, even with very few rounds of pbkdf, your actual passwords should be safe.
I think 1Password's use of an extra "secret key" would be a huge save in a situation like this, where every encryption key is automatically very long
Citation needed on "biggest". 1Password appears to have comparable revenue to LastPass, but it is hard to pin down clear sources. Since you seem to have sources, it would be nice to see them. Number of users is even harder to pin down since you never know what a company counts as a "user". Someone who forgot to delete their account from years ago could easily be counted if the company is looking to inflate user counts.
Even if they were 100x the size of the next competitor, they would not get a free pass for the obvious technical failures of their implementation, which have nothing to do with the number of users. The entire vault should be encrypted, end to end. The number of PBKDF2 "rounds" should automatically have increased, even for old users. These are huge oversights that fundamentally undermine their credibility.
As far as coverups at other companies go, that would be some coverup to avoid any whistleblowers leaking things. Unless it was very recent, this is very unlikely. People take cybersecurity seriously, and counting on every employee to participate in a coverup of a serious breach is unlikely to go well.
I am also annoyed by the switch to a SaaS-model, but I don‘t think this hurt security in any way, and for most people (i.e. those that used to sync their vault via cloud storage) probably improved it quite a bit.
If you store the secret key locally and only locally, the threat model should be the same as before.
That extra key is something I love about 1Password's security. It ensures that even people who pick poor master passwords are well protected. And even though I have a strong master password, the key is a good extra comfort for me.
The secret key bothers me. A lot. Where do you store this mission critical piece of data? This is a value you cannot memorize (unless you are Rain Man) and it can be used to gain access to your account. The whole point of a password manager was to avoid this kind of vulnerability. Gives me the willies. It's basically a return to post-it notes.
It used to bother me too, but I‘ve since come around:
It‘s a strictly additional barrier to the passphrase. Bitwarden and LastPass don‘t use one, so if you are fine with that security level, you could publish it on your blog, GitHub profile, or Wikipedia talk page and would literally not be less secure than those two.
It really only is defense in depth, but in a breach like this is where it could shine. A parallel brute force attack becomes infeasible if attackers need to also compromise cloud or local storage, or even trivially correlate semi-publicly but unstructuredly posted secret keys to accounts/vaults.
1pw really doesn't play nice with yubikeys. LP has no issues (i think it doesn't use WebAuth, which 1P does). 1P UI is nicer. LP is a bit clunky. Not being able to add notes/docs to 1P in the extension kinda stinks ... why can't they just open the vault like LP does. They seem to be very similar: they both crap all over login forms! I like the secret key thing now: it basically forces people to have big passwords. But I find it annoying because my passphrase is enormous to begin with, I don't want to have to fuss with managing another key. I think they are neck-and-neck from my security posture view.
Admittedly, I’m not very knowledgeable with this type of stuff, but would they have chosen to do this so that the browser extension can still show the user when a login is available without the user having to authenticate (they then authenticate to get the login details)
This is likely the reason. Other providers like BitWarden caches the urls for certain time on client side. Even if you lock vault, extension can suggest that here is available login for certain period.
Locally caching this data seems like a much more reasonable way to implement this and would have completely prevented this data leak without any impact to usability.
People are joking about obvious bad choices like Excel, but I am really not sure what is really safe anymore. For example, I am using Dashlane, should I change it? If so, how?
I have two OSes on my laptops and both iOS and Android, so I can probably manage except maybe on my office laptop. My parents are a part of my family plan and I don't see them being able to use it.
Separate your work and personal data, including passwords. That way if you ever leave the job it's and simple as leaving the password manager entity and not having to clean out your personal bank of passwords.
Keepass is FOSS and there are compatible clients for basically every OS you might think of, including IOS, Android, OSX, Windows, and Linux. It does not include multi-device sync, but it works nicely with other solutions that provide that function. So drop in your preferred file sync solution (ideally, cloud-free) and you're all set.
I don't understand why tech savvy people are doubting the security of a pw manager with a strong master pw; this wasn't a failure caused by a flaw in the concept of a pw manager itself, but by a company's shitty implementation and design (I mean c'mon, certain fields were encrypted but others weren't, and they didn't make it super obvious?).
People are...very confused if their reaction to this is "cloud password manager bad". If only well-encrypted data were leaked, it really wouldn't be a big deal.
A properly designed online password manager is an extremely safe choice.
Exactly... of the relatively tech savvy people I know who use this incident as some sort of vindication for their choice to not use a pw manager, are the same people who either store passwords in plaintext electronically, or write them down but use passwords that have a weak keyspace and are under 10 chars. I'm pretty sure I read an article from a month ago wherein 4 rtx4090s could chew through the hashes of 8 char passwords with a strong keyspace in a few days or hours.
To add to my comment, if one's response is to point out it's difficult to trust the company's opsec, handling of your data etc then use something like bitwarden. If a fully open src online pw manager doesn't calm your nerves, self host it.
1Password does encrypt URLs. It also requires an extra Secret Key [0] in addition to your password. This makes it much, much harder to use the data even if encrypted vaults were stolen.
They also have a development team that's very active. Lastpass had been coasting for years.
Look, I hate the "new" 1Password as much or more than most, but to say they're coasting is disingenuous; just last week they published their "op" plugin system allowing running "gh" and "glab" and a bunch of other common commands as subprocess of their "op" binary to inject the api tokens. I think the SSH Agent behavior is also post-money
They've also listen to our bitching about requiring the master password every 2 weeks even with biometrics turned on, and rolled that back to a configurable setting
In my opinion, 1password is definitely more secure. 1password generates a key when registering which you cannot restore. So not only an attacker need to know your password, they also have to know the generated sequence. This is helpful for people who tend to use easy to break passwords.
1pasaword is not perfect, but it’s far better than lastpass
Keepass is fantastic but it is unsuitable for many things, such as multi-user/teams. The browser integration is also very much not something I trust, unlike 1Password's.
1Password has a fantastic track record.
Yes, tomorrow, their incentives might change. But the data is copied and available locally; if they start fucking with user data, we will see it coming.
Security is a lot about trust and trade-offs. This includes trusting someone who has shown themselves to be trustworthy, even if they might not be trustworthy tomorrow.
Well - guess I have no trust, when it comes to uploading my passwords to someone's else server.
I remember too many SaaS companies with awesome reputation, that over time became sketchy (including Last Pass).
As for the teams - you shouldn't have shared accounts. Making introducing them convinient is bad idea. Where I work, we're audited for that and honestly it's very small issue if you give it a few minutes of thought.
Lastpass was always sketchy, as long as I have known them. I can back this up with proof, it’s not their first leak and I’ve personally talked about how you shouldn’t use them as early as 2012…
Re teams, just because you shouldn’t have shared accounts doesn’t mean you can’t have shared secrets which end up in a password manager. Or more generally, the ability to have managed employee vaults. And regardless, shared accounts do happen, because some providers just suck. Making them as secure as possible is more important.
Maybe, but we'll never know because you've just traded one cloud solution for another. You cannot audit their code and by handing over all your passwords, you've just made your entire digital life dependant upon their continued financial success.
I cannot fathom why anyone would look at the situation today and decide that the solution is more of the same.
Get an offline password manager and keep your valuables out of the cloud. I like Keepass, but there are plenty of FOSS solutions out there that allow you to actually own your data.
I understand that the security of customer data is the focus, but is it yet known how access was gained?
I ask because I presume LastPass put a heavy emphasis on security, yet this still happened. Is there a 0-day still out there in the hands of very malicious actors and not yet patched?
How was the initial (src + docs) breach performed? How do they escalate that into a successful social engineering attack, particularly since the breach was known of?
Did the targeted employee have unfettered access to all this customer data?
Will be interesting to know the fuller story. I'm guessing that's only a matter of time.
Just exported my vault, and will see if there's anything relevant in there (I haven't used LP in 7 years, but I probably have some unimportant-ish passwords in there from back then)
Until now, I had forgotten that they still had my data :/
One key feature of 1Password is the use of a secret key in addition to a master password.
See page 10 [1] which explains how the secret key provides extra entropy (which makes it much harder to brute force a user who choses a weak password). Also see Story 1 on page 11 [1].
Why do people use AES-ECB? I keep seeing this when even the Wikipedia entries explain very well what’s wrong with it. It’s not like AES-CTR or even a decent block chained mode like CBC is hard to use.
Cryptographic libraries shouldn’t even expose it except in a subpackage or namespace called “hazmat.”
It is (or was) the default mode, and, unlike CTR, you don't need anything more than a key to use it; no nonces, no IVs, no parameters. Put yourself in the shoes of someone who doesn't know much about cryptography, and it's a natural choice.
Hmm... so poor defaults strike again. Makes sense if you know nothing that simple AES-ECB seems to work and has the simplest API of any of the modes.
But then I'd have to say... why is a company doing a secure password saver not employing anyone who knows the very basics of how to use cryptography? :)
> why is a company doing a secure password saver not employing anyone who knows the very basics of how to use cryptography?
Because that isn't important for success. Perception is reality. Very few people can tell the difference between good and bad crypto work. So instead of wasting money on that, invest it into something that is understood by more of your customers. It's a sad reality.
Their payouts for reported bugs under bug bounty program have been very low, for a service used at the scale of Lastpass I believe this is just not ideal.
$5000? I think it should be in at least the same order of magnitude what the black market would pay for a leak.
Most people wouldn’t sell data for $40,000 if the bug bounty was $35,000. But that lastpass leak is worth many tens of thousands more than the $5000 (average payout of $450) offered.
I deleted my account over 12 months ago. I never assume that my data was deleted and changed my important (not all) passwords when I did so. I'm now going to go through every password in my current password manager that's older than the LastPass deletion date and scrutinize them again.
Yes, it would be good for LastPass to let us know the answer to this very simple question. Not to mention, why haven’t they already notified everyone whose data was taken in the breach?
I had a last pass account three years ago but shut it down. I used the remove account options on their website if I recall. I wonder if they kept my vault sitting around on their servers or if it was truly removed.
I had a lastpass account years ago, but cleaned my database and changed passwords to all my accounts after the first breach. Is there a chance Lastpass keeps old copies of my database archived somewhere?
Can someone knowledgeable explain how the number of iterations affects account security for this breach?
OK higher is better sure, but is moving from 5K iterations to 100K per the recommendation a similar precaution to adding 1,2,3 digits to the master password?
Number of iterations is directly proportional to the time and cost of cracking the master password. For the old vaults it's 20 times faster/cheaper to crack the master password by brute force.
The best precaution is to never use LastPass. If you used LastPass, the safe course of action is to change all your passwords that were in LastPass, and use a better password manager this time.
PBKDF isn't really considered best practise at all, really. Current best practice is to use a memory hard function like argon2, which makes GPUs ineffective at bruteforcing.
Adding a digit to a password can depend. Adding a 1 to the end of a password is such a well known thing that its basically useless because that's the first thing people try as its so common. Ultimately though, you are basically correct in a bruteforce scenario. However most password attacks involve a bit of knowledge about what the person likely choose, so the effect depends on what that knowledge is.
Keep in mind if you have a strong password (say 16 character randomly generated, never reused elsewhere) its not going to matter how many iterations as it will never be bruteforced even if the worst possible hash was used. This sort of thing protects people who use weak or maybe mid-tier passwords.
Makes me think if survivorship bias (or similar) applies here. While it's not fun to see LP having a lot of incidents in its history, maybe those could be viewed as something that has made LP stronger over the years?
I'd be more worried about a password manager that has never seen any security incidents - is it because there really aren't any, or that they haven't been caugh? Surely a security incident on a password manager serves as a major motivation to harden shit up?
They didn't fix known weaknesses (unencrypted urls, no auto upgrade of the key cipher) after those previous incidents. At some point one has to come to the opposite conclusion...
I hope LastPass wil burn. What a shitty software, besides these Security notifications, which Geels like is the 3th or 4th this year. Their software sucks to use.
We work in Salesforce so lots of logins with login.sf.com. i have to always.
1 search credentials in plugin
2. Search credentials again to copy OTP.
Most my colleagues miss setting the seed of OTP correctly cause it feels like you are done when entering but you still have to save it at the bottom.
Lots of times it asks to overwrite (update) client X credentials with client Y
In our admin cobsole, half of the usernames are not visible, just white space, so when i Need changes i need to click around and find that setting page, which is poor UI but then gamle on every whitespace to give the right permissions to user X.
Moving to BW is high on my list for 6 months plus. But too busy, will make time to my now. Bye. Don't comment a lot but truly LP is one of the only pieces of software I really hate.
I somehow sadly signed up for LastPass only about a month ago, after (briefly) reviewing options.
I have a rather long pass phrase. That should theoretically mean that even with my vault, brute-forcing this is out of the question and everything is still business as usual?
If that's the case I'll sleep easier at night than the thought of trying to move everything yet again to another password manager and handle (what are strong) password resets at places like Google .... shudder.
If you signed up only a month ago, that means your pbkdf2 iterations were set to a non-trivial value (presumably the default 100100, but you can verify this in advanced settings). This insulates you very well against brute forcing.
Urls and some other fields are stored plaintext.
So yes, you’re safe from bruteforcing passwords. But still lost privacy / doxxing / spear fishing info.
I’m pretty sure any info this person has from 7+ years ago can be anecdotal at best; who knows what’s changed, what he’s forgotten, what he’s misunderstood, etc…
233 comments
[ 3.2 ms ] story [ 262 ms ] threadKind of unclear but i think this implies that lastpass doesn't do some and reencrypt on login. Are they saying its just people who havent unlocked there vault in a decade, or are they saying all old users have this? If the latter this is really poor design.
> Lots of vault entries may be encrypted with ECB mode AES-256.
Wtf wtf wtf. This would be considered wildly insecure even by the standards of the 80s
Seems weird that they would have the number of rounds fixed from the time of account creation though. Surely it would be possible to increase the number of rounds over time.
Edit: I should add that I have logged into this account within the past year or two. So if they're supposed to increase over time, it ain't worked.
“Yes,” said Arthur, “yes I did. It was on display in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying ‘Beware of the Leopard.’”
Keep in mind that this is a trade-off, it requires more computational power AND battery, so giving users access to the leavers makes sense (e.g. power users with nice equipment can pump up the number).
That being said I do agree that it is up to the vendor to set AND enforce a new higher minimum. If someone logs in with 5K rounds, it should be changed to the new default (100k).
On a related note Bitwarden also allows users to configure this. I recently increased mine to 150K rounds.
99.9%+ of people aren’t that technical person. Safe defaults need to be used and kept up to date for them.
Ideally they'd manage that number and prompt the user to change it over time.
Of course, changing it now won't do any good with regard to previous leaks.
Old accounts that haven't been touched in years, sure. But active accounts being used daily? This is really unfathomable.
Well, No. In metacode, pbkdf2 works something like:
(See Wikipedia for more details https://en.wikipedia.org/wiki/PBKDF2)Point being, you can only change the number of rounds if you re-encrypt the vault, and you can only do that, if the users participates by giving their password to first un-encrypt it during that process. So it cannot be done silently in the background.
I've done this with normal login for several (legacy) systems I've worked on, migrating users from md5 or sha1 to better algorithms.
LastPass NEVER gets your master key server side. All encryption is done locally.
Also, hashing a password is extremely quick. To unencrypt the full vault and re-encrypt it does take an amount of focused time.
Might not be able to be done “silently” in the background, but obviously LP should have been forcing an upgrade on login.
The entire vault should not be encrypted directly with the user's password. That would go against standard best practices.
See this comment written hours before yours, right under the comment you replied to: https://news.ycombinator.com/item?id=34127993
There is no "big difference" here, and it could be done trivially during login. The fact that it would be done client side instead of server side is a very minor implementation detail.
Conceptually, it's not very different from how password hashes are updated, just that you need to re-wrap some other key as well simultaneously. Since the rest of the vault is unaffected, it's OK if the transaction fails: the old parameters will work with the old wrapped key, so all you need to do is ensure that the transaction is atomic. (Usually don't even have to do anything to ensure that if you just use the same database table/object.)
And it's probably a good thing the original design didn't have that — I'm pretty sure Crypto.getRandomValues() wasn't available on all browsers yet when LastPass was first release it's JavaScript version (not sure when that was — I've never been a LastPass user).
Of course, the format itself can also be (and should have been!) transparently upgraded. Interrupting legacy users just once for a 20-30 second upgrade of their entire vault is a no-brainer. The fact that LastPass hasn't proactively upgraded old vaults on login during all these years reflects very badly on their security.
I think there might be a way to update it without having to wait for the user to supply the master password, at least if their web login works like most, although it would require some additions to the database and their server side vault storage.
According to the documentation I found the master password you create when you make your account is the master for both logging in to your account and for encrypting your vault.
To handle its use as a login password they probably have a table somewhere that contains:
I'll assume that they want to update both the login password hashing difficulty and the vault decryption difficulty.To handle updating login hashing they could change that table to contain for accounts that have logged in or been created after the difficulty change:
and for accounts created before the change that have not yet logged in: For the vault storage, they'd have to change it so that instead of just singly encrypted vaults, Encrypt(vault, derived_pass), it can also store doubly encrypted vaults, Encrypt(Encrypt(vault, derived_pass), derived_pass2).When they do the change, they would change existing vaults to double encrypted, with derived_pass2 = hash1(master_password, salt1).
When someone logs in for the first time after the change, they supply master_password. The server would see from the login hash table that salt1 is not NULL meaning they are an un-upgraded account. It could then compute
and see if that matches the hash in the login hash table. If it does the login is successful, and it can (a) generate a new salt and update the login hash table to contain: and (b) use hash1(master_password, salt1) to remove the double encryption from the vault, use master_password to decrypt the vault, and then re-encrypt with a new derived password with the new upgraded work factor.NOTE: the above is based on documentation of theirs that says you use the master password for logging in to your account. However other documentation of theirs says that the master password is never sent to their servers.
My account is very old, but this was hidden behind advanced settings. And I have used this account daily since I created it. Not having this increase from their end seems very unprofessional.
You aren't wrong, if true that's certainly a mistake on their part. Practically speaking though as long as the passwords are randomly generated it probably doesn't matter, i.e. if you think about what the IV and chaining are doing in CBC. ECB is just as good for encrypting a random stream of bits; CBC just makes sure the bits are random before passing them into the cipher. Of course the optics are still terrible.
1. In real life, passwords aren't random. Password manager users are probably less likely than average to make this blunder, but I'd still be willing to bet _the majority_ of lastpass's customers do.
2. Even if you personally have all random passwords, would you really want to use a product made by people who made this level of a noob mistake? I used to pay for LastPass premium, now my account is deleted, my passwords are changed, and my money goes to Bitwarden instead - and every time I hear about Lastpass I don't regret this decision.
Obviously this isn't an endorsement of LastPass. Everything about their protocols is disappointing. Even if the encryption issues turn out to be of the well-that-was-a-dumb-choice-but-you-don't-need-to-panic variety, it's because they got lucky, not because they were good.
Maybe I wasn't obvious enough, but this is the problematic assumption. When I say "non-random password", that's what I mean: a reused password.
Almost everyone I know reuses passwords (sometimes with a slight variation, but 90% of the password the same), and my day job is a software engineer. I'd be willing to be at least half of Lastpass's users have at least 1 reused password.
If the attacker doesn't have the valid password, the knowledge that two different sites share the same password isn't exactly game-changing. And if the attacker does have the password, they'll figure out where it works regardless of access to LastPass db.
To an outsider, hearing people talk about how LastPass used Very Bad ECB mode makes it sound like a fuckup with immediate and dramatic effect on the security of their passwords, that isn't exactly true.
Nobody should have been using LastPass, but we can still be realistic about the threats facing those who did.
> but the obvious problem here is the offline cracking of the vault passwords; this isn't worth arguing about.
Of course not, but that's a completely separate issue from their choice of AES mode.
Kind of a long shot though.
If you have some attacker after specifically you, yes this information is of less use to them, because they will have tried every password of yours they have on every website already hoping you reuse passwords.
The reason I suspect even non-random passwords might be mostly fine[1] is because there's no oracle and passwords are generally short. There's not much there for someone to hang their hat on. It's only a hunch, though; if tptacek for example says something different, I'd believe him.
1. Meaning: No need to cancel Christmas. You can deal with it later. Not meaning: ECB is as strong as CBC or whatever.
i have been using keepass(xc) since it's been around and i dont use random passwords. every year i create a formula that creates all my passwords and i put these in the vault. it also enforces password rotation. losing the vault i can still come up with any of my psswords just by remembering the formula.
for company server services it's a different story, i generate wholly random strong passwords and store them in the offline vault.
edit: typos
You need to know the specific order how to create the password for a new site. Otherwise it was just easier to plow through with your favourite memorised combination.
At least I found it hard to do with Lastpass on mobile. Now I’ve tested it with Bitwarden and 1Password 8, they seem to do a better job with it.
This allows an attacker to detect repeating plain text segments, e.g. reused passwords.
The Wikipedia article on block cypher modes illustrates this problem rather well [1].
[1]: https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation...
Also, I've just learned that the quintessential file has been recently replaced. I understand the need for a higher resolution file, but I'm still a bit sad.
This is hardly a problem, any login form will also allow an attacker to do this.
https://doc.libsodium.org/
http://noiseprotocol.org/
CTR is not a very robust block cipher mode...
Have they not heard of the first rule of crypto being "You probably aren't qualified to do it, use libsodium or TLS or SSH" yet? Why are they messing with cipher modes themselves?
a) LastPass is extremely old
b) Browser extensions used to be completely different. You needed to call out to native code to do tons of stuff because the JS apis were extremely limited and slow. So it was either "roll crypto in JS" or "make users install a binary", the latter stopped being possible over something like a decade ago.
For this particular use-case? Hardly.
Since an attacker can easily use any login form of their choice as an oracle for password reuse, ECB mode can't really introduce significant issues here.
If the attacker has an encrypted vault, what is the login form there for them to use and detect password reuse?
Incorrect password attempts are essentially free, so ECB revealing reuse does not meaningfully help the attacker.
But for the attacker to try one of my passwords in a login form, they do need to have that password cracked already, which means that they already have my master password. But if they have that, they can decrypt all of my passwords, and the login forms are of no use.
Am I misunderstanding something here?
No, not at all. The point is that while ECB is a silly choice, it does not make it easier for the attacker to crack your vault. It does allow the attacker to see if you're reusing passwords, but does not reveal to the attacker what those passwords are.
On the other hand, If the attacker were to discover one of your passwords from another source, they'd be able to confirm reuse anyway by simply attempting to use that password on other websites.
The point is you explain why you do this. Start the message with "We care about your encryption" and go from there to explain that they need you to upgrade because the don't know your master key, they need your help to do it.
Adding this kind of behavior should be their core business. Apparently it's not.
Edit: because I was (until very recently) a daily active user and had niter=5k. Didn't even know about this setting until the hack.
It's not like you need to work at LastPass or have deep expertise in the domain to look at your own account.
I can confirm because I am one such person. Honestly thought that would come across from context but I'll edit to clarify.
KDF is not a substitute for a good password.
Yes, they might also use other techniques as well, for example, push a bad update if they have such privileged access. However, that’s relevant more in targeted attacks; you can’t really push a bad update to everyone before getting caught quickly. Also, often several people have to sign the code (in the case of non-JavaScript code), and there is log trail.
Why bother with cracking the vault when you can just modify the javascript sent to report back the master password? Especially if you only do targeted attacks, and/or heavily obfuscate the phoning home, the chances of getting away with it is probably pretty high.
The worst part was the reward. $1000 is a sick joke.
Unfortunately I believe that’s Safari-only and even then they seem to be aiming to move away from it - all non-Safari extensions are a “fat” client called 1Password X where the entire logic (and thus the sensitive data) is within the browser.
We may not be seeing the whole picture yet, but very concerning that the dev environment had access to Production database backups stored in a manner that was easily decrypt-able :/ The whole point of a Dev environment in a security focused company is that you reduce the surface area for access and failure.
> some source code and technical information were stolen from our development environment and used to target another employee, obtaining credentials and keys which were used to access and decrypt some storage volumes within the cloud-based storage service.
It sounds like they didn’t literally have backups in the dev environment (which would be absolutely terrible if they did).
I’m guessing they learned enough about the architecture from the dev environment to social engineer their way into getting someone to give them credentials to production.
> dev environment had access to Production database backups stored in a manner that was easily decrypt-able
Say what you like about old dinosaur companies like banks, but when I worked in the IT department for a bank back in the early 2000s developers absolutely couldn't touch production systems, data or backups. Ever. They always has to go through ops even during major incidents.
Of course banks aren't immune to fuckups, but at least on paper they tend to have sound security policies.
Startups are great at moving fast because there are no guardrails. Like lemmings, corps, banks and government entities externalize their risk to the third party because they recognize the name and logo. "Should we go with SecureCompany(tm)?". "Yeah, everybody uses them".
It's great for startups. Without red tape and heavy policy your lean team can create products that the hamstrung bigcorp could only dream of (just don't look under the UI!). They slowly build their customer base, and when they're ready to IPO, they run through some security and process certification theatre, and the investors and a handful of executives can make billions.
Overall, both sides seem to be happy with the situation. Bigcorp gets to cut tech staff and outsource, and they have a convenient finger to point when the regulator asks questions. The SaaS apologises and maybe loses a customer or two, but based on stock prices after major issues like this in the past, nothing bad really happens.
From a large development team whose sole product centers around encryption? It seems strange to get it this wrong. What leads to that might make a good business case study.
They have been coasting for years. There are some serious bugs they never addressed.
I wish I could export my "password history" in some way
At big companies, too often do the people in charge of the product seem to forget what core product really is.
Also, as far as i can tell with some very basic maths based on running hashcat on my 3070, if you have a big long password on your vault, even with very few rounds of pbkdf, your actual passwords should be safe.
I think 1Password's use of an extra "secret key" would be a huge save in a situation like this, where every encryption key is automatically very long
This seems like business and product getting in the way of good decisions. Again.
Even if they were 100x the size of the next competitor, they would not get a free pass for the obvious technical failures of their implementation, which have nothing to do with the number of users. The entire vault should be encrypted, end to end. The number of PBKDF2 "rounds" should automatically have increased, even for old users. These are huge oversights that fundamentally undermine their credibility.
As far as coverups at other companies go, that would be some coverup to avoid any whistleblowers leaking things. Unless it was very recent, this is very unlikely. People take cybersecurity seriously, and counting on every employee to participate in a coverup of a serious breach is unlikely to go well.
If you store the secret key locally and only locally, the threat model should be the same as before.
Some suggestions: https://blog.1password.com/where-to-store-your-emergency-kit...
Even if you write it down on a post-it note, you now need a physical attack to access it on top of whatever attack you needed for the master password.
The key is 38 characters long, which is certainly within the range of human memory, if you're inclined to memorize it.
It‘s a strictly additional barrier to the passphrase. Bitwarden and LastPass don‘t use one, so if you are fine with that security level, you could publish it on your blog, GitHub profile, or Wikipedia talk page and would literally not be less secure than those two.
It really only is defense in depth, but in a breach like this is where it could shine. A parallel brute force attack becomes infeasible if attackers need to also compromise cloud or local storage, or even trivially correlate semi-publicly but unstructuredly posted secret keys to accounts/vaults.
Thanks, folks, I should have jsut RTFA'd I misunderstood secret key as a failsafe, it is not:
https://support.1password.com/secret-key-security/
I installed both LastPass and 1Password and they make my homegrown key storage system feel so awkward by comparison.
That's obviously a design choice in order to extract data that can be monetized.
A properly designed online password manager is an extremely safe choice.
Just sayin'.
They also have a development team that's very active. Lastpass had been coasting for years.
[0] https://support.1password.com/secret-key-security/
They've also listen to our bitching about requiring the master password every 2 weeks even with biometrics turned on, and rolled that back to a configurable setting
1pasaword is not perfect, but it’s far better than lastpass
Get something that writes data in open format and does not interfere with how you store it. Eg. Keepass with some privacy focused file storage.
1Password has a fantastic track record.
Yes, tomorrow, their incentives might change. But the data is copied and available locally; if they start fucking with user data, we will see it coming.
Security is a lot about trust and trade-offs. This includes trusting someone who has shown themselves to be trustworthy, even if they might not be trustworthy tomorrow.
I remember too many SaaS companies with awesome reputation, that over time became sketchy (including Last Pass).
As for the teams - you shouldn't have shared accounts. Making introducing them convinient is bad idea. Where I work, we're audited for that and honestly it's very small issue if you give it a few minutes of thought.
Re teams, just because you shouldn’t have shared accounts doesn’t mean you can’t have shared secrets which end up in a password manager. Or more generally, the ability to have managed employee vaults. And regardless, shared accounts do happen, because some providers just suck. Making them as secure as possible is more important.
I cannot fathom why anyone would look at the situation today and decide that the solution is more of the same.
Get an offline password manager and keep your valuables out of the cloud. I like Keepass, but there are plenty of FOSS solutions out there that allow you to actually own your data.
May they say "F this, I quit" and we hire them.
I ask because I presume LastPass put a heavy emphasis on security, yet this still happened. Is there a 0-day still out there in the hands of very malicious actors and not yet patched?
> some source code and technical information were stolen from our development environment and used to target another employee
How was the initial (src + docs) breach performed? How do they escalate that into a successful social engineering attack, particularly since the breach was known of?
Did the targeted employee have unfettered access to all this customer data?
Will be interesting to know the fuller story. I'm guessing that's only a matter of time.
Just exported my vault, and will see if there's anything relevant in there (I haven't used LP in 7 years, but I probably have some unimportant-ish passwords in there from back then)
Until now, I had forgotten that they still had my data :/
I don’t know if he ever got into the details of why (maybe he couldn’t for contract reasons or something), but his judgement on it looks accurate.
I’d be curious what his thoughts are, or if the risks he was talking about back then we’re unrelated.
They do what any reasonable security company does, and call in vendors who have negative incentive to lie: https://support.1password.com/security-assessments/
I was especially impressed by the Cure53 ones, where they were provided access to the source code: https://bucket.agilebits.com/security/Cure53-1PW18-report.pd...
See page 10 [1] which explains how the secret key provides extra entropy (which makes it much harder to brute force a user who choses a weak password). Also see Story 1 on page 11 [1].
[1] https://1passwordstatic.com/files/security/1password-white-p...
Cryptographic libraries shouldn’t even expose it except in a subpackage or namespace called “hazmat.”
But then I'd have to say... why is a company doing a secure password saver not employing anyone who knows the very basics of how to use cryptography? :)
Because that isn't important for success. Perception is reality. Very few people can tell the difference between good and bad crypto work. So instead of wasting money on that, invest it into something that is understood by more of your customers. It's a sad reality.
- https://dropbox.tech/security/how-dropbox-securely-stores-yo...
- https://en.wikipedia.org/wiki/Pepper_(cryptography)
Their payouts for reported bugs under bug bounty program have been very low, for a service used at the scale of Lastpass I believe this is just not ideal.
> Points – $5,000 per vulnerability
- https://bugcrowd.com/lastpass
Most people wouldn’t sell data for $40,000 if the bug bounty was $35,000. But that lastpass leak is worth many tens of thousands more than the $5000 (average payout of $450) offered.
OK higher is better sure, but is moving from 5K iterations to 100K per the recommendation a similar precaution to adding 1,2,3 digits to the master password?
The best precaution is to never use LastPass. If you used LastPass, the safe course of action is to change all your passwords that were in LastPass, and use a better password manager this time.
I'm not sure to whom the rest of your response is addressed, this was a technical question.
Adding a digit to a password can depend. Adding a 1 to the end of a password is such a well known thing that its basically useless because that's the first thing people try as its so common. Ultimately though, you are basically correct in a bruteforce scenario. However most password attacks involve a bit of knowledge about what the person likely choose, so the effect depends on what that knowledge is.
Keep in mind if you have a strong password (say 16 character randomly generated, never reused elsewhere) its not going to matter how many iterations as it will never be bruteforced even if the worst possible hash was used. This sort of thing protects people who use weak or maybe mid-tier passwords.
I'd be more worried about a password manager that has never seen any security incidents - is it because there really aren't any, or that they haven't been caugh? Surely a security incident on a password manager serves as a major motivation to harden shit up?
It's owned by a Private Equity firm, which means cutting all costs and selling hard until there's no money left to squeeze out of the corpse.
We work in Salesforce so lots of logins with login.sf.com. i have to always. 1 search credentials in plugin 2. Search credentials again to copy OTP.
Most my colleagues miss setting the seed of OTP correctly cause it feels like you are done when entering but you still have to save it at the bottom.
Lots of times it asks to overwrite (update) client X credentials with client Y
In our admin cobsole, half of the usernames are not visible, just white space, so when i Need changes i need to click around and find that setting page, which is poor UI but then gamle on every whitespace to give the right permissions to user X.
Moving to BW is high on my list for 6 months plus. But too busy, will make time to my now. Bye. Don't comment a lot but truly LP is one of the only pieces of software I really hate.
I have a rather long pass phrase. That should theoretically mean that even with my vault, brute-forcing this is out of the question and everything is still business as usual?
If that's the case I'll sleep easier at night than the thought of trying to move everything yet again to another password manager and handle (what are strong) password resets at places like Google .... shudder.