[Update 30 January 2019 – I made an Ionic mobile app that does just this. 🙂 Read all about it!]
If there’s one thing two decades on the internet has taught me, it’s that techies enjoy binary battles between opposing and equivalent technologies.
iOS vs Android. Vi vs Emacs. Tabs vs spaces. Didactic and fundamentalist exposition is kind of the norm when it comes to these discussions.
One topic I had not expected to see alongside these traditional battlegrounds is the nature of the tool one uses to manage distinct passwords across web sites. Until now.
I’ve recently found myself discussing why I dislike centralised password managers a couple of times, and then – being linked from a deterministic password extension(!) – reading this post on the flaws of deterministic password tools.
While the post highlights some trade-offs that potential new users should definitely consider, I wanted to sum up why none of them are a big deal for my use case, and why I still consider the alternative drastically worse.
The trade-offs
Password policies
Some sites will always disallow passwords of the default format you choose. Yes, this is annoying. But in 2017, it’s also not that common. Perhaps 10% of sites I use these days will disallow my strong generated passwords due to length or symbols, and they don’t tend to be the ones where I consider security the most critical (with the slightly outrageous exceptions of two UK banks).
In most cases there’s an easy fallback. Tweak the generated password as required by the overly specific rules. If the site isn’t a critical one, saving the password with a browser sync account is fine – if they get hacked it’s still unique. And if the sync account ever breaks, it’s pretty rare for sites to lack a reset function. Not ideal, but hardly a deal breaker.
Replacing compromised passwords
Again, I’ll agree the user experience here isn’t optimal, but I also don’t think it’s a big deal. You can apply a workaround like the above, or if the leaked credential was for a site you consider very important and therefore don’t want to use browser sync, keep a note locally of the one-off tweak to the input for password generation. And perhaps reconsider your choice of provider for this security-critical service.
Existing secrets can’t be imported
This is mostly a matter of opinion on the appropriate scope of these tools, but I don’t really see this as a problem. Before I used a password manager at all, I mostly shared a few passwords across many sites.
If I’d had a convenient way to keep using them, I would have unique-ified fewer of my important credentials and consequently remained more vulnerable to attacks on leaked databases. If anything, the absence of this feature has made me safer!
I would consider tools like Keybase for other encrypted or signed secret sharing use cases, which I consider to be outside the natural scope of a browser-centric password manager.
A leaked master password is really bad
Of course this is completely true, and rotation for all sites would be a nightmare. However I would argue that in practice an attacker who manages to get you to share this by accident is probably quite on the ball. In the event that you inadvertently sent them your LastPass master password, their bot would probably have a copy of your data within a second or so – they’re unlikely to be waiting around long enough for you to realise what happened and re-encrypt your vault.
So I’d argue that in practical terms, this is a nil-nil draw and is the major drawback of all types of password manager. If your main secret is leaked you’re in huge trouble.
It would be enough to make me consider all types of manager to be terrible options, if it wasn’t for the absence of any better alternative.
Why accept a trade-off?
So I believe the user experience trade-offs are relatively small for me, but still, why would you accept them? Well…
The incentive to attack centralised password managers
There is one huge drawback to a centralised service as I see it. While we can all agree that security by obscurity isn’t security etc., there is inevitably an increase in risk when you use a popular service that is such a valuable target for attacks. Arguably the most valuable out there. Dozens of important credentials for millions of users, all reversibly encrypted in one convenient place.
These commercial services need to support different devices and browsers, which typically means numerous different software products in the wild, each with the power to unlock all of a user’s secrets. Each has a distinct codebase and the potential to carry its own critical security holes. The chances of there being no way into these systems are vanishingly small.
This is not a hypothetical threat. LastPass has had a pretty bad run of attacks against it – some are summarised on Wikipedia. They’ve paid out for 172 reports on their bug bounty programme – and while of course running such a programme is to be commended, the two most serious breaches in the last two years should definitely at least merit discussion of the strength of a centralised approach.
While 1Password seems to have a better track record, not appearing to have been directly in a public attack but only vulnerable as a side effect of an Apple exploit, the 25 payouts to date on their bounty are a reminder that no software is bug-free. The generous offers to white-hat security researchers is an absolute necessity for these companies rather than a ‘nice to have’, given how incredibly lucrative a target their tools are to nefarious attackers.
While acknowledging these issues and running bounty programmes is crucial, it does also raise questions around whether the risks inherent in these services are worth it. Yes, these companies invest much more in security than you do individually. But you have two major strengths:
- You are probably not, on your own, a massively valuable target.
- If you’re handling your local security competently, you likely don’t expose lots of services on the public internet that potentially have access to all your secrets.
I find the comments in the other post about marketing the security of deterministic managers a bit strange. Not that it’s super relevant to their security policies, but in practice the current landscape consists mostly of presumably quite profitable paid subscription non-deterministic services, and a handful of free or donation-ware single-purpose, single-platform deterministic ones. If anybody has sales teams and an incentive to exaggerate the safety of their approach, it seems odd to assume it’s the PasswordMakers of the world and not LastPass and 1Password.
Finally, I should add that this post led me to read several others on Tony Arcieri’s blog, which I found thoughtful and interesting and almost invariably agreed with. I think the lesson here is that over-generalising is never helpful and that the best choice of password tool for you depends greatly on your appetite for risk, level of technical know-how, and attention to your local system’s security.
Comments on “In defence of deterministic password managers”