Live data from Hacker News

What’s in a PR statement: LastPass breach explained

palant.info

151–160 of 292 posts

Re: What’s in a PR statement: LastPass breach explained

#151

Assuming I'm a LastPass user and I have a sufficiently long master password with hardware based 2FA do I have anything to worry about? The one weak link is mobile authentication which bypasses 2FA. I honestly forget how that's configured.

Maybe. Check your account's iterations like this: https://support.lastpass.com/help/how-do-i-change-my-passwor...

If it's 5000, you've got 20 times as much to worry about than if it's 100100.

2FA won't help. That controls access, but not decryption, and they've already got the encrypted data, so they're past needing to get access.

To be safe, start resetting your most high-value passwords immediately. Bank, email accounts, etc. Ideally, reset everything.

Re: What’s in a PR statement: LastPass breach explained

#152

I think we can do better in protecting vaults against offline brute force attacks. As written in the this post, 1Password uses a randomly generated "secret key" together with the user-chosen master password. This "secret key" is not stored on 1Password's servers, instead it should be printed on a piece of paper and stored safely. While this is a good starting point, it significantly reduces usability, since you need…

What does migration look like for a new device? If a phone is lost and it's TPM compromised would that put all future credentials at risk? Most of the derived ideas strike me foolish since they compromise future and past. And they accrue state anyway once one must rotate keys.

You are asking the right & also complicated questions :)

Let me first say that we are just finishing up a version 2 of our whitepaper that can answer all questions regarding the cryptographic architecture including these scenarios. We'll announce that in the next 2-4 weeks when it's ready.

There are different scenarios here:

* If you install heylogin on a new phone, you will get asked to transfer your account to the new one. If you confirm, everything is cleared on the old phone, secrets are regenerated and date is re-encrypted.

* If you are using the team features of heylogin, your admin can disable your old phone (even if it's broken) and you can connect a new one with the help of the admin. The secrets are re-generated and data is re-encrypted. The underlying architecture is a little bit more difficult here and will be explained in the whitepaper.

* You can write down a backup code and use this for recovery (I like this method the least)

* We'll soon have a feature where you can add a security key as another method of accessing your data. This will also help in re-gaining access if the phone is lost.

* We'll also probably have a "social recovery" in the future, similar to the admin recovery flow but for private users.

Internally, we have more ideas to provide transfer & recovery flows. We'll keep on experimenting.

Since secrets are re-generated and data is re-encrypted, even if the old phone is broken, the TMP no longer holds secrets that are usable to decrypt the data.

Does this answer your question?

Re: What’s in a PR statement: LastPass breach explained

#153

Earlier quoted context omitted.

Since i use Google Authenticator for numerous services this is going to happen to me one day. So what I did was set it up on more than one phone.

I would legit pay money for Google to pull that piece of junk from the Play Store, because it's damn malpractice at this point, given there are so many other options that don't straight-up swallow the TOTP keys

Sorry what

Re: What’s in a PR statement: LastPass breach explained

#154

Catastrophic breach after catastrophic breach since 2011. Lastpass has failed their fiduciary duty as a steward of sensitive information and IMO exhibited gross negligence in not encrypting URI data, ostensibly as a trade off for consumer functionality. not to be overly vindictive, as I understand the near impossibility of running a perfectly secure service at absolutely enormous scale…but does anyone else feel LastP…

More interesting to me is that this shouldn't be an issue, they should just lose out to the competition organically. And yet here we are.

Competition is slow to take effect when there is cost of transition.

Re: What’s in a PR statement: LastPass breach explained

#155
A (perhaps) unconventional approach to password management, which I recommend to anyone. If you enjoy complexity, this is too simple for you.

No one can steal something that's not written down

Just like the Navajo code talkers in WW II had a system that was memorized, so even if the Japanese captured another Navajo and tortured him (which they did), he couldn't reveal the code.

Have some hints to yourself, and store the hints. Even if the file is stolen, the hints won't help the thief. Never, never store a "master key" of what all the hints mean. If you forget one, just click the "forgot my password" link.

I'm not going to even hint at the hints :) I use.

Re: What’s in a PR statement: LastPass breach explained

#156

I wasn't quite ready to self promote this but I will go ahead anyway, since people are probably researching alternatives now. I'm working on a comparison of different password managers. https://password-manager.soft-wa.re/ At this point it's mainly a fork&merge of some previous work. If you find any issues with the data please submit a PR. Edit: I am standing on the shoulders of giants. Take a look at the contributor…

[deleted]

Re: What’s in a PR statement: LastPass breach explained

#157
post #39

Earlier quoted context omitted.

Seems like a great product, but something about the URL is reminiscent of those scammy websites that try to trick you into downloading scamware.

I'm admittedly a hammer seeing everything as a nail, but as a designer, I see so many opportunities in FOSS lost to basic, unnecessary branding and usability oversights. Developers shouldn't expect themselves to be able to do good design work any more than designers should expect themselves to be able to make scalable, reliable, maintainable, production-ready code. It's a specialty for a reason! Incorporating designe…

One of the great difficulty of tackling that problem is often FOSS projects are averse to design decisions like that made by someone relatively fresh to the project - even if the problem is incredibly obvious to the designers and not the core development team. You would have to spend a lot of time gaining trust to then be able to present an idea like switching domains.

The duality of putting off design decisions until later, and also feeling like your current design is extremely personal (I've seen some projects where the maintainer immediately disregards a lot of proposals design wise because it's "good enough", as if that person just called their baby ugly), can make trying to make any progress on FOSS project feel horrible.

It's a very interesting problem space I feel. There's so much room for improvement.

Re: What’s in a PR statement: LastPass breach explained

#158
post #108

Earlier quoted context omitted.

More interesting to me is that this shouldn't be an issue, they should just lose out to the competition organically. And yet here we are.

Duopoly. Plus cost of switching away once you sign up. Network effects and monopolistic (anti-competitive) features allow bad companies to survive today. Monopolistic practices are probably a worse problem today than in the 1920s. In the 1920s governments used regulation to break up huge firms and defeat advantages due to cost of capital (hard to start a new railroad in the 20s because the cost of trains and tracks w…

Much of this could be addressed by antitrust enforcement as well as actually having competent lawmakers that understand the products their citizens use overwhelmingly daily. Policymakers barely understand the internet, let alone zero knowledge architecture and encryption

Sundar Pichai being asked about if someone is handpicking search results comes to mind, as an illustration

Re: What’s in a PR statement: LastPass breach explained

#159
post #77

Earlier quoted context omitted.

There is a pretty large gap between "cloud based password storage" and "using the same password for each site". 1Password for /years/ worked with a local vault (and no remote sign-in requirement), and had relatively simple syncing to iOS via wifi (no idea on other OSes, that's what I use). I've shared my password vault between these two places with no issues and it didn't need a cloud account and I wasn't re-using pa…

That's literally the option though if you've managed to convince someone to use a password manager. I convinced a family member and their response to the breach was "okay, who should I use instead? Or do I go back to using one password for everything?"

"okay, who should I use instead? Or do I go back to using one password for everything?"

Given that the "using one password for everything" is such a terrible idea that we can discount as probably worse than storing your passwords in a cloud-based vault then you land on what your family member has given you as the other option "what should I use instead".

Ultimately if* there are no password managers available that will do syncing of locally stored vaults, then there are actually multiple options here:

1. Accept that the convenience (of device sync) here trumps the security issue that storing passwords in a cloud based vault causes.

2. Should there be no options that allow for device sync /and/ local-only vaults then there is another option which is to not do automatic syncing.

Option 2. is somewhat inconvenient (how much depends on who you are and what you do), but it is still an option.

Personally, Option 1. is a line I'm not willing to cross. I see single repositories of 10s to 100s of thousands of peoples passwords as a "password piñata", a massive target for attack and so I'd take the inconvenience over the compromise. That said I'm lucky to have a 1Password 7 still so do have local vaults and sync, but there's not a chance in hell I'm uploading this stuff to a central repo.

* Enpass might do what you want. It was a suggestion in the comment thread here.

Re: What’s in a PR statement: LastPass breach explained

#160

I think we can do better in protecting vaults against offline brute force attacks. As written in the this post, 1Password uses a randomly generated "secret key" together with the user-chosen master password. This "secret key" is not stored on 1Password's servers, instead it should be printed on a piece of paper and stored safely. While this is a good starting point, it significantly reduces usability, since you need…

> since the e2ee does not depend on a user chosen master password. What's the story with "my phone went in the lake" using that setup?

Just wrote a longer answer to the question below, hope that covers your question as well.
Post reply on HN