Hacker News new | ask | show | jobs
by Normal_gaussian 1854 days ago
Thats right, we should blame the victim for trusting the tool.

Password managers are increasingly mandated by organisations, and Lastpass is a very common recommendation. Even in the minority of technical users that use this kind of tool I expect small mistakes - like accidentally pasting a password in a URL. A good tool doesn't let you shoot yourself in the foot by escalting that to a non-obvious leak. The password length being wrong is 100% on the tool. Th weak master password and the duplicates are again, things the tool shouldn't do - it claims to give good quality security reports.

With respect to Lastpass specifically, I dislike the tool immensely. Ive had to use it a number of times and have always found its UX significantly buggy - included blatant failures like not saving passwords with no indication; coupled with the acquisition by LogMeIn and I'm incredibly distrustful.

3 comments

There are only three meaningfully "correct" recommendations for password managers as of today, depending on the use case: 1Password, Bitwarden, or KeepassXC.

1Password is fantastic, but expensive and closed source. Bitwarden is open source, but lacks certain auditing, team and sync features useful for enterprise. KeepassXC is excellent and open source, but with zero collaboration features is only suitable for self use.

There's some collaboration features. You can create "keeshares" between multiple separate databases. All the databases can append, update, or read the share.

You can't delete an entry but you can deprecate it and stop updating it (it's not actually feasible to revoke access anyways).

Keeshares seem new, I hadn't heard about them. Seems… interesting. Thanks for pointing them out.
There's also 'pass', created by Jason Donenfield, who also created WireGuard. But I think it's not for laypeople.

https://www.passwordstore.org/

Have you taken a look at saas pass that has 2fa as the default and the password manager identifies sites with 2fa?

disclaimer: was involved on the 2fa part of it.

I used SaaS pass at work for a while, and it made my day a little bit worse every time I had to use its 2FA. The app's login on push notification thing was very slow, and would fail too often (maybe 5-10% of the time). I ended up using the QR code scanning for 2FA more often than not, but even that was slow, not even accounting for for the time it takes a human to unlock their phone and open the app. Doing thing multiple times throughout the workday was a real drag.

It's a shame, because I think the idea of it is nicer and no less secure than Google Auth, but I'd much rather enter 6 numbers than wait for the app.

Disclaimer: This was around a year ago, perhaps it's improved since.

And how did you come up with this list of 'correct' password managers?
Quite simply through experience.
Do you think KeePassXC is better than original KeePass?
Absolutely, xc has been far better maintained in the last few years.
I used LastPass for a few years, but switched to bitwarden over a year ago.

Mainly driven by the combination of price increases, no improvements (and possibly getting worse) at things like the auto-fill buttons conflicting or not working with many apps I was using, the duplicate entries it would create, failure to match Android apps and web logins, and the constant battle to try to get it to work with several internal apps and test systems (same top-level domain, where I have a mix of unique and common logins) while also working on the web generally.

Bitwarden has per-domain selection of match type (full host, base domain, or regex), and a non-interfering UI. I can't think of a single thing LastPass does better.

Most people realize they can hurt themselves if they use a hammer wrong. If someone can be expected to put four years of their life into a degree or prepatory trade training they can be held accountable for not caring enough to spend 10 minutes reading about effective use of their password manager.
That's not the reality though. The current wisdom in security seems to be to follow reality. To eliminate shooting foots by both users and developers. See NaCl crypto library, libsodium, Noise protocol, Signal app, Tarsnap and restic, Brian Warner's magic-wormhole, Signify/Minisign, Filippo Valsorda's 'age', WireGuard.

Are there more?

It's not just security. This applies generally where people will shoot at their own feet. In C++ I can apparently have an atomic integer and increment it:

  std::atomic<int> n = 0;
  n++;
Rust has atomics but they don't work that way.

  let n = std::sync::atomic::AtomicU32::new(0);
  n.fetch_add(1, std::sync::atomic::Ordering::SeqCst);
Hmm. Why doesn't Rust's "AtomicU32" just implement AddAssign? If it implemented the AddAssign trait then you could at least write:

  n += 1
.. and that looks much nicer, it elides all that stuff about memory models, consistency, and... oh...

In the C++ code, the programmer thinks this variable n "is" atomic. It's an atomic integer right? But that's not a thing. C++ is mapping atomic integer operations, which are a thing, onto the type, and not making the integer itself magically atomic, it's just an ordinary (aligned) integer.

So if we tweak both examples to do some slightly trickier arithmetic...

  std::atomic<int> n = 0;
  std::atomic<int> m = 0;
  n++;
  m= m + n;

  use std::sync::atomic::{AtomicU32, Ordering};
  let n = AtomicU32::new(0);
  let m = AtomicU32::new(0);
  n.fetch_add(1, Ordering::SeqCst);
  m.fetch_add(n.load(Ordering::SeqCst), Ordering::SeqCst);
Once again, Rust seems much more verbose, but, wait, actually this isn't the same as the C++. This is probably what the C++ programmer intended but what they actually wrote means this:

  use std::sync::atomic::{AtomicU32, Ordering};
  let n = AtomicU32::new(0);
  let m = AtomicU32::new(0);
  n.fetch_add(1, Ordering::SeqCst);
  m.store(m.load(Ordering::SeqCst) + n.load(Ordering::SeqCst), Ordering::SeqCst);
Well that's just crazy. Now m can change between when we load from it, and when we add n to it, and then we store back this out-dated value. We definitely didn't want that. But it looked sane because C++ fools us into believing "Atomic integers" are a thing, which they actually aren't.