How do you deal with sites whose password requirements don't match the output of LessPass? How do you handle the fact that sites want you to change your password? Yes. There's a counter field, but how do you know what site uses what version of the counter? How do you change the master password without having to change all passwords?
Thing is: There's a solution for all these problems: All you have to do is actually generating a random password and store that (in-fact, that's the solution proposed by LessPass to use for these special cases. But if you have storage for the special cases, why not just store the passwords to begin with?)
You don't want to sync it because you don't trust the client-side encryption used in all the managers out there? Use a piece of paper to write the passwords down. Or use a device you constantly carry with you as your password store.
While there are tons of workarounds for the issues of stateful password managers, there are none for the stateless ones (aside of storing the state somewhere, but if you're doing that, why not just store the password?)
The problem with writing passwords down is that I need to fly places and it's not unheard of if you work in financial tech or military tech to have your things riffled through at the boarder. Plus a mugger can say "give me your things!" or "Empty your pockets!" and now he has my credentials.
Passwords are not easy. My current solution for the long tail of things that need passwords is two factor + really strong password I generate then don't save anywhere. If I get signed out I do password reset to my gmail. Gmail is two factor (obviously) with a really strong password and recovery email to an email address nobody knows.
If you used any stateful password manager instead of a piece of paper, then the passwords would be stored in an encrypted fashion. Don't give out your master password and your passwords are useless to an attacker.
If you use a paper based solution, just alter the passwords you write down using some additional information only known to you - maybe some prefix or suffix and the list would be useless for an attacker.
If you think they can force you to divulge the master password or your password scheme if you're using paper (they probably can, see https://xkcd.com/538/), then LessPass won't be of any help to you either.
I think there is where the connected version can play an important role. From my understanding it stores everything but the password, so that can keep track of password rules, counters, etc per site.
I think the biggest issue still is what happens when you change your master password? Because I couldn't find an answer for that.
>aside of storing the state somewhere, but if you're doing that, why not just store the password?
Because even if the state information is compromised, it is useless to the attacker. On the other hand, if a password is leaked that can be used to access the account.
> How do you deal with sites whose password requirements don't match the output of LessPass? How do you handle the fact that sites want you to change your password? Yes. There's a counter field, but how do you know what site uses what version of the counter? How do you change the master password without having to change all passwords?
* you can write specs for domains' specific password requirements so the generator can guarantee it is accepted
* the counters you append to your password when generated are not sensitive so can be saved/synced
* I have not addressed needing to change your master password, but I'd also like to point out using a password hashing scheme doesn't preclude you from having more than one master password, perhaps to segment work passwords from personal ones.
* sometimes domains change as well, so you can log the domains used it generate passwords, which might be sensitive from a Metadata standpoint, but from a hack-your-password sorta way. This also helps when I use it for passwords other than websites (like ssh key passphrases)
> Thing is: There's a solution for all these problems: All you have to do is actually generating a random password and store
I agree that generating random passwords gives a better user experience, which it is much more popular. I prefer holding all of my data even if I could store it remotely encrypted so hashing was the clear choice. I also kept the algorithm simple so that I could implement it from memory on a strange computer if needed. Definitely not for everyone!
> But if you have storage for the special cases, why not just store the passwords to begin with?
1. because compromises do not give up the password
2. because storage then becomes optional, it's still usable if it's not installed on the device you're using, as long as you remember the metadata. (or keep trying different combinations until you get it, there aren't that many different combinations as long as you rarely increment a counter).
#1 is true too for an encrypted password database.
Unless of course by "compromise" you meant the master password being stolen, in which case such a compromise would result in all your passwords being stolen with both types of password managers.
Thing is: There's a solution for all these problems: All you have to do is actually generating a random password and store that (in-fact, that's the solution proposed by LessPass to use for these special cases. But if you have storage for the special cases, why not just store the passwords to begin with?)
You don't want to sync it because you don't trust the client-side encryption used in all the managers out there? Use a piece of paper to write the passwords down. Or use a device you constantly carry with you as your password store.
While there are tons of workarounds for the issues of stateful password managers, there are none for the stateless ones (aside of storing the state somewhere, but if you're doing that, why not just store the password?)