Live data from Hacker News

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

twitter.com

321–330 of 436 posts

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

#321

Earlier quoted context omitted.

Do you expose your server to the internet or is it ok to sync devices only when you’re at home? Is every device a replica, if you lose your server can you redeploy it from the data on your device?

Not the parent, but I have been hosting a Vaultwarden instance on the public internet for about two years now. After learning about certificate transparency logs, I moved the app from a raw subdomain behind a secret URL path. Think “hello.domain.com/correcthorsebatterystaple”. Is it security by obscurity? You bet. Does it work? Yes. I regularly evaluate the JSON logs emitted by Caddy in a pandas script and so far, no…

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 cryptographic primitives, than simply adding layers. What you’re trading off for is complexity and convenience vs security. In the URL case, a password is more secure (and treated as such) and lots of care is usually taken to make sure the hashing scheme is timing resistant etc. I don’t know if Caddy makes equivalent guarantees, but I’d be very surprised if path matching was not just a string match/regex/trie. In terms of time to crack, just prepending these characters to the password would give you more protection, because that then has to go through a resource intensive hashing process.

An example of defense-in-depth would be to host at home only. Here, it’s because you’re nesting actual isolation (which is a good security primitive by itself), with a strong password. This gives you protection even if your threat model is “caddy is borked and is letting anyone do anything”.

Now in reality, you can do just about anything and it’ll work (because in the grand scheme, you’re probably not a high value enough target for any high cost attacks). If you secretly happen to be, then you can afford an actual security audit, rather than relying on random info from HN :)

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

#322

Is there any reason to use these cloud based solutions when open source alternatives like KeepassXC is available?

Is there any reason to give someone else your password to store when you can just remember it or write it down somewhere safe?

I have >200 unique randomly generated passwords in my Keepass file for various accounts (granted, a lot of them are throwaway accounts). No way I could ever remember those passwords, so any attempt at using that approach would necessitate less secure passwords.

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

#323
post #321

Earlier quoted context omitted.

Not the parent, but I have been hosting a Vaultwarden instance on the public internet for about two years now. After learning about certificate transparency logs, I moved the app from a raw subdomain behind a secret URL path. Think “hello.domain.com/correcthorsebatterystaple”. Is it security by obscurity? You bet. Does it work? Yes. I regularly evaluate the JSON logs emitted by Caddy in a pandas script and so far, no…

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 is flawed in itself? That’s when a wholly different one is desirable.

In that spirit, I had also thought about just slamming http basic auth in front of everything. Even if that basic auth uses weak credentials, it adds to security in a multiplicative/exponential way (multiple passwords/systems), over just a linear one (single but long password). I suppose that’s also what you mean by layering.

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

#324

Earlier quoted context omitted.

It’s basically what modern ddos protection does - the WASM computational calculation is a digital dew can.

Wait, so you're telling me that Cloudflare interstitial is running some PoW check on my client? I always thought that was just a way to let the user know they're being rate limited on Cloudflare's end.

I haven't heard of Cloudflare doing that, but it's the concept behind mCaptcha: https://mcaptcha.org/

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

#325
post #257

Earlier quoted context omitted.

It seems like a reasonably well written anecdote by someone who has some idea what they're talking about. It could obviously be false, but the consequences if he's right are potentially serious for a lot of HN users who might use LastPass. The consequences if he's wrong are a little extra reputational damage for LastPass, but that seems like a worthwhile tradeoff here. Not everything posted on HN has to be verified t…

Someone who has any idea what they're talking about in this case would have used a hardware wallet.

> The losses are not significant.

That together with others here claiming they have a LOT, makes me think they might have hot, cold, soft and hardware wallets.

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

#326
post #311

Earlier quoted context omitted.

I definitely feel the opposing law works. When I see a project with a massive disclaimer about "this crypto is not audited, I'm a noob never deploy this anywhere" I'm likely to see better crypto than most of the commercial products I work with, including ones with sales people that talk about unbreakable crypto.

> When I see a project with a massive disclaimer about "this crypto is not audited, I'm a noob never deploy this anywhere" I'm likely to see better crypto than most of the commercial products I work with, including ones with sales people that talk about unbreakable crypto. I'm working on an opensource project for Linux users that needs crypto. Needless to say, I'm not an expert in that domain. I was planning to ask e…

Use available and widely used libraries for the low level crypto parts (e.g. don't code RSA or key generation on your own). Apart from that, get audits if you have the means but I guess using libraries like openssl should be enough for most open source projects.

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

#327

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.

They are just being secretive about their business the same way you ask them to be secretive about your passwords.

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

#328
post #273

Earlier quoted context omitted.

> is their actually a technical reason to believe they are better than Lastpass or any of their competition (have they like open sourced all their stuff?). You can see their server and client code here: https://github.com/bitwarden I choose to use their clients unmodified, along with an instance of the server formerly known as "bitwarden_rs" running in my basement as the sync backend. https://github.com/dani-garcia/v…

> 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 build is the same as developer provided, but automatic protections that were there are now gone [2]

[0] https://en.wikipedia.org/wiki/Reproducible_builds [1] https://mobileapp.bitwarden.com/fdroid/ [2] https://arstechnica.com/gadgets/2021/07/google-play-dumps-ap...

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

#329
post #210

The inference that the LastPass leak is responsible is being made purely on the basis that this particular person can't identify any other way the security of their wallet was broken. That seems a very weak basis (essentially, absence of evidence equating to evidence of absence) to make what is really a very strong assertion.

Indeed, the votes on this tweet make me skeptical of HN community's basic critical thinking skillz.

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

#330

Earlier quoted context omitted.

The average user that LastPass caters to thinks that a "backup" is the reason they were late for work in the morning. LastPass doesn't want to be in a position where they're telling their users, "Sorry you're SOL," if their device breaks and they don't have a second copy of their locally-stored encryption key.

[edit] I guess that's true. I'm not sure who their users are, but obviously not people overly concerned about security. [/edit] Just because I think it's funny - every time I visit my dad (who's in his 80s) he regales me with his startup ideas. "Why don't you build something that I can put on my glasses so when I lose them I can find them? Whoever invents that would be a billionaire." I say, "Yeah dad, they have that…

Companies. It is to convenient to use a shared password manager to share passwords within a group of people or some such.

Also techies have been telling non-techies "use a password manager!" for years, and people fail to evaluate one solution or the other.

My brother in law (a non technical person) was telling my wife last year how good LastPass was for him!

Post reply on HN