Live data from Hacker News

The situation at LastPass may be worse than they are letting on

twitter.com

401–410 of 436 posts

Re: The situation at LastPass may be worse than they are letting on

#401
post #321

Earlier quoted context omitted.

I’d say the things hitting your endpoint are going to be entirely automated scanners that are looking for unauthenticated resources or low hanging common passwords. If you have even a moderately strong password, it’s just noise. I’d be wary about drawing any significant conclusions from logs, because the sophistication of attackers you’ve excluded are quite low. I’d say defense-in-depth is more about nesting strong c…

> I’d say defense-in-depth is more about nesting strong cryptographic primitives, than simply adding layers. I like this insight, thank you. One rebuttal I have: appending those characters to the password would make it a stronger password, but it wouldn’t add another, wholly different, mode to authentication. It would be the same thing, just harder (and I don’t need a longer password as it stands). What if this mode…

Linear/multiplicative stuff is actually quite helpful for discussing the path thing.

Adding a “password” path is actually only increasing your security by a constant factor per character because of the risk of timing attacks (unless you are sure that the path matching algorithm is secure against it now and in the future). Ideally a 2nd layer would guard against it in a multiplicative way (an entirely different with system).

Cryptographically, adding characters to the password rather than to the path is better (because it increases the search space exponentially) than adding characters to the path, which can be brute forced separately per character.

But this assumes a very perfect view of software, where there are no bugs. Once you add a risk model for bugs, then there might be small values of path length where the additional constant factor is better than the multiplicative one that you get from adding characters to your password. So your rebuttal holds, depending on the exact bug risk model you have.

I think nowadays, tailscale/wireguard is really convenient and pretty secure as a 2nd layer. I was averse to self hosting my password manager in the past due to not being comfortable having the consistent time to secure more critical applications, but I might actually move to a world where I host more critical things myself behind a VPN.

Re: The situation at LastPass may be worse than they are letting on

#402

Earlier quoted context omitted.

> KeePass on an airgapped box Sounds inconvenient for password retrieval when not home, how does this work in practice? How about an airgapped phone with GrapheneOS and Keepass?

Sounds like you just solved the inconvenience problem.

How is your setup though? Can you describe it in more detail please? Interested in the perspective of a security professional.

Re: The situation at LastPass may be worse than they are letting on

#403

Earlier quoted context omitted.

> Why would we be critical of LastPass being secretive and/or wrong and then take a tweet at face value? One entity has something to lose, the other doesn't?

That exactly what flat earthers claim. 1. You don't know if this person has nothing to lose 2. Even if they have nothing to lose that doesn't mean they are being honest.

> That exactly what flat earthers claim.

I have no idea what this has to do with this discussion, and this just comes off as an ad hominem attack. Flat earthers claim that there's an economic interest in lying to them? And you think that claim is particularly genuine or even similar to this argument?

> You don't know if this person has nothing to lose

It is possible that they have some competing business and are trying to damage LastPass, but there's absolutely no evidence of that, nor any suggestion other than to double-check your credentials and your expected security if you are a LastPass customer. So, if they do have an interest, they're doing a particularly bad job of acting within it.

> Even if they have nothing to lose that doesn't mean they are being honest.

And we're not going to reach 100% certainty of any fact through discussion on a message board. It is interesting that some people spend a lot of effort trying to ensure this obscurity gets injected into the conversation, and it suggests that their own motivations should be questioned.

All in all, on the balance of apparent probabilities, there's more reason to trust this person than not. You can attempt to assail that logic if you like, but I would appreciate it if you stuck to the facts of the argument instead of kicking up dirt.

Re: The situation at LastPass may be worse than they are letting on

#404
post #273

Earlier quoted context omitted.

> You can see their server and client code here: https://github.com/bitwarden But in the case of the mobile apps, downloaded from their respective platform's app store, how can you guarantee the code you see on github is the exact same code you're running on your device? Admittedly this supply-chain-verification is an issue for all mobile app store apps but seems particularly important with something like a password…

In a perfect scenario you would be able to use a reproducible build [0], for Android you can actually get Bitwarden from F-Droid [1] which uses those reproducible builds. For Google play store, there was also that developers needed to sign their apps before releasing to stores, so you knew that it came from developer, but Google removed that when they introduced app bundles. There is still a way to verify if the buil…

Looking at that, it doesn't seem like you can actually get Bitwarden from F-Droid? That looks like instructions to set up a third-party repository (hosted by Bitwarden)?

The page didn't mention anything about reproducible builds. (Doesn't mean they aren't using it though, but that would be internal.)

Re: The situation at LastPass may be worse than they are letting on

#405
post #398

Earlier quoted context omitted.

Just checked on my own account, which I set up in 2012. Mine was configured with only 500 rounds of KDF - eep.

Eek. It is quite incredible they didn't have any kind of KDF upgrade system built into the login process, under the guise of "log in again please". And presumably no prominent permanent notification of your 500 rounds of KDF (!!) Edit: https://web.archive.org/web/20120320015133/https://helpdesk.... confirms that the default was indeed 500. According to https://www.infosecblog.org/2012/06/lastpass-and-pbkdf2/ , there…

It took rather a long time - a couple of minutes - to re-encrypt all my passwords, which presumably is why they didn't do it on login. But yeah, a notification sure would have been nice!

Re: The situation at LastPass may be worse than they are letting on

#406
post #398

Earlier quoted context omitted.

Eek. It is quite incredible they didn't have any kind of KDF upgrade system built into the login process, under the guise of "log in again please". And presumably no prominent permanent notification of your 500 rounds of KDF (!!) Edit: https://web.archive.org/web/20120320015133/https://helpdesk.... confirms that the default was indeed 500. According to https://www.infosecblog.org/2012/06/lastpass-and-pbkdf2/ , there…

It took rather a long time - a couple of minutes - to re-encrypt all my passwords, which presumably is why they didn't do it on login. But yeah, a notification sure would have been nice!

Interesting - I did the same on a bitwarden install just to test it, and it was instantaneous. From memory, BW has a single account key (encrypted by password) to facilitate this process, as well as a method to re-key the account (which would need to re-encrypt everything).

Wonder if Lastpass encrypted everything with the password-derived key directly, necessitating a full re-keying.

Re: The situation at LastPass may be worse than they are letting on

#407
I’m wondering if leaving the URLs in plaintext was actually a good idea, here’s my reasoning:

With _random_ passwords which most LastPass users probably generated, the attacker has no way of knowing if a key resulted in a successful decryption unless they login to a particular site.

If the URLs were part of the encrypted payload though, a quick string check for “http” or “www” would tell them if a key was correct or not during their brute-force attempts. Maybe a silver lining?

Re: The situation at LastPass may be worse than they are letting on

#408
post #185

Earlier quoted context omitted.

One option is to have two identical security keys. In general, you can't easily read the secrets from an existing key, but you can overwrite/initialize them to get two with identical data.

Most services allow you to enrol two or more security keys, so you wouldn't need to overwrite one.

The problem with that is that it requires to have all these security keys available in order to enrol them, which is not possible if you want to store one of them in a different secure location. If you have two keys in your pocket, that's not much of a backup; having two identical keys means that you can enrol the one in your pocket and if it gets lost, the copy from your safe works.

Re: The situation at LastPass may be worse than they are letting on

#409

Earlier quoted context omitted.

They're not listed, but Chrome and Android can manage passwords

Oh, I see. Well, I don’t use Chrome or Android, so I’ll look at BitWarden.

Does Apple have their own Password sync stuff? I'm assuming they do, but BitWarden is going to be more portable and cross platform.

Re: The situation at LastPass may be worse than they are letting on

#410

Earlier quoted context omitted.

And Bitwarden can be self-hosted for those that are weary about using SaaS password managers.

Nitpick: "weary" == "tired", "wary" == cautious

Thanks for correction.
Post reply on HN