This is one reason why I believe that browser based password managers are flawed. I've written about this in the past (link below). These apps are popular with normal people (due to convenience), but long-term, we should not trust web browsers plugins or add-ons as password managers.
That only makes sense when you ignore the bigger picture. Before browser-based password managers people weren't using password managers at all.
The two most common (and successful) attack vectors have been via password reuse and low password quality. Convenience, context aware, device agnostic, browser based, password managers have been successful in convincing the general public to use a password manager at all.
The use of a password manager allows people to have per-site and higher quality (e.g. long/difficult to remember) passwords. This has had a positive impact on people's security.
KeePass and similar "offline" solutions avoids some specific attack vectors. However, both "offline" solutions and browser-based extensions also share a great deal of vectors. For example if bad-ware has local execution inside the user's context, all bets are off (assuming you're running KeePass and the database is decrypted in memory, which you need to in order to retrieve a password).
It is fine to suggest options people feel are superior, but ultimately the conveniences are a security benefit within themselves because people are actually using and sticking to password managers (thus avoiding password re-use/low quality passwords).
I agree with your assessment of why traditional password managers have flaws, but I disagree with your conclusion.
Security has always been a balance between usability and safety, and when you set security policy, you always do it in the context of who is using it and their needs.
Integrating the password manager into the browser makes a lot of things easier as an end user. If I told my parents/grandparents and non-programmer friends to use something like DBG or Password Safe, they would just go back to guessable and reused passwords. Given the choice, I would rather have them use a browser based password manager.
If we're really talking about how to move the needle on protecting logins, I would rather push FIDO/U2F. Keeping a cryptographic second factor on your keychain, phone, or computer carries more added safety at a lower usability cost.
While in browser password managers have drawbacks, they have the big advantage that they stop fishing / fake domain attacks. I think I'm much mor likely to fall for one of those, than my password manager get hacked.
Also, generating all passwords off one master password deterministicly sounds like an awful, awful idea. If someone manages to get one of my passwords, they can try performing an offline attack against the encoding password. If they succeed, they have everything.
How well does that scale to more than a handful of passwords? I currently have around 400 in my password manager.
Your documentation says:
> If you need to change all of your passwords, change the sentence.
Note that this works the other way, too: unless you are changing all your passwords, you cannot change the sentence.
Since it is extremely unlikely that I'd ever want to change all 400 passwords at once, in effect that means I'm never going to be able to change the sentence.
All password changes, then, will be done by changing the per-site word. The documentation suggests:
> Use a different word for different sites. Be consistent with case (e.g. google, facebook, twitter, etc.)
OK, that's easy for the initial password, but what happens when I want change my Google password and have to change the word? The obvious approach is to change it to "google2", and the next time change it to "google3", and so on.
Am I expected to remember what variation each of my 400 sites is on? That's probably not practical for most of us, so I'm going to have to have that stored somewhere, and am going to need that storage available to me whenever I need to reconstruct a password, so I need it stores some way that syncs across my devices.
Your document lists not having the burden of storage as an advantage of the generated password approach, but I don't see how to deal with remembering the words without having storage. The burden of storing the words, or storing the version suffix of the words, is less than that of storing encrypted passwords because it isn't as bad if they get out, but it is still a burden.
The document says of password manager master passwords:
> This "master password" is a weak point. If the "master password" is exposed, or there is a slight possibility of potential exposure, confidence in the passwords are lost.
Exposure is also pretty big if the sentence for password generation gets exposed. I think most people are going to use words for sites that are simple, like the ones given as examples in the documentation ("google", "facebook", "twitter"). If I'm able to get someone's sentence, there is a good chance I'll be able to guess their words for a lot of major services.
It seems to me that the main security advantage this approach has is that it is not using a browser plugin, so for a remote site to compromise it they are going to have to find a way to spy on the user when they are typing in the master sentence. For something running in the browser to do that, it's going to have to both find a bug in the browser that lets it get past the browser's security, and find some exploit in the OS that lets it once it escapes the browser to get past the operating system's security that protects processes from each other.
Someone1234|6 years ago
The two most common (and successful) attack vectors have been via password reuse and low password quality. Convenience, context aware, device agnostic, browser based, password managers have been successful in convincing the general public to use a password manager at all.
The use of a password manager allows people to have per-site and higher quality (e.g. long/difficult to remember) passwords. This has had a positive impact on people's security.
KeePass and similar "offline" solutions avoids some specific attack vectors. However, both "offline" solutions and browser-based extensions also share a great deal of vectors. For example if bad-ware has local execution inside the user's context, all bets are off (assuming you're running KeePass and the database is decrypted in memory, which you need to in order to retrieve a password).
It is fine to suggest options people feel are superior, but ultimately the conveniences are a security benefit within themselves because people are actually using and sticking to password managers (thus avoiding password re-use/low quality passwords).
munchbunny|6 years ago
Security has always been a balance between usability and safety, and when you set security policy, you always do it in the context of who is using it and their needs.
Integrating the password manager into the browser makes a lot of things easier as an end user. If I told my parents/grandparents and non-programmer friends to use something like DBG or Password Safe, they would just go back to guessable and reused passwords. Given the choice, I would rather have them use a browser based password manager.
If we're really talking about how to move the needle on protecting logins, I would rather push FIDO/U2F. Keeping a cryptographic second factor on your keychain, phone, or computer carries more added safety at a lower usability cost.
CJefferson|6 years ago
Also, generating all passwords off one master password deterministicly sounds like an awful, awful idea. If someone manages to get one of my passwords, they can try performing an offline attack against the encoding password. If they succeed, they have everything.
w8rbt|6 years ago
tzs|6 years ago
Your documentation says:
> If you need to change all of your passwords, change the sentence.
Note that this works the other way, too: unless you are changing all your passwords, you cannot change the sentence.
Since it is extremely unlikely that I'd ever want to change all 400 passwords at once, in effect that means I'm never going to be able to change the sentence.
All password changes, then, will be done by changing the per-site word. The documentation suggests:
> Use a different word for different sites. Be consistent with case (e.g. google, facebook, twitter, etc.)
OK, that's easy for the initial password, but what happens when I want change my Google password and have to change the word? The obvious approach is to change it to "google2", and the next time change it to "google3", and so on.
Am I expected to remember what variation each of my 400 sites is on? That's probably not practical for most of us, so I'm going to have to have that stored somewhere, and am going to need that storage available to me whenever I need to reconstruct a password, so I need it stores some way that syncs across my devices.
Your document lists not having the burden of storage as an advantage of the generated password approach, but I don't see how to deal with remembering the words without having storage. The burden of storing the words, or storing the version suffix of the words, is less than that of storing encrypted passwords because it isn't as bad if they get out, but it is still a burden.
The document says of password manager master passwords:
> This "master password" is a weak point. If the "master password" is exposed, or there is a slight possibility of potential exposure, confidence in the passwords are lost.
Exposure is also pretty big if the sentence for password generation gets exposed. I think most people are going to use words for sites that are simple, like the ones given as examples in the documentation ("google", "facebook", "twitter"). If I'm able to get someone's sentence, there is a good chance I'll be able to guess their words for a lot of major services.
It seems to me that the main security advantage this approach has is that it is not using a browser plugin, so for a remote site to compromise it they are going to have to find a way to spy on the user when they are typing in the master sentence. For something running in the browser to do that, it's going to have to both find a bug in the browser that lets it get past the browser's security, and find some exploit in the OS that lets it once it escapes the browser to get past the operating system's security that protects processes from each other.