Hi everyone,

I just came across this project called LessPass, which doesn’t require a database as a back-end and can compute passwords on the fly instead of storing them. The idea really intrigued me, and I wanted to know from the community about the experience of using it - did you run into any troubles with it? How does it compare to more traditional password managers (which would need me to think of a back-up strategy)?

Is it possible to back up your passwords from LessPass? Can you use your own passwords when you prefer to? How are the client programs?

Thanks!

  • narc0tic_bird@lemm.eeEnglish
    25·
    11 months ago

    It’s a cool concept that quickly falls apart in my opinion:

    1. It’s not really stateless as soon as a website has certain password requirements. You probably don’t want to remember the configuration of all passwords in your head.
    2. If the password for a website gets compromised, you have to set the “counter” + 1. Again, not stateless.
    3. If you have multiple accounts per website, you’ll have to store the site differently (for example including www, not including www) or interlace the counter (odd/even) between the two. This gets more and more messy the more accounts you add, and again, it’s not stateless.
    4. The master password is the only thing an attacker needs (plus the state mentioned above, but it’s easy to brute force a simple counter). With most other password managers, the attacker needs access to the vault/database and potentially a keyfile, secret and/or some form of second factor.
    5. Changing your master password because it got compromised or ideally before it gets compromised changes the passwords for all websites.
    6. You still have to remember your username or login email, so that’s again not stateless if you’re saving it in some sort of LessPass client.

    I could probably list a lot of other reasons why it’s not a good idea to use it. There are probably some edge cases where it’s good, for demonstration purposes or training sessions where the participants all need unique (temporary) logins for several services.

    • ThetaDev@lemm.eeEnglish
      4·
      11 months ago

      You also cannot use it to store secret information like bank account/credit card details, API keys, etc.

    • jeffhykin@lemm.eeEnglish
      1·
      11 months ago

      #3 isn’t true. There’s a username field, so you just put in the username of the alt accounts.

      Your point about the master password and two factor is a good one though.

      In practice password restrictions are rare (like 1% of sites), but they are problematic when they happen because there’s so many different ways to restrict passwords and trying all combinations is impractical. Needing the counter is exceedingly rare. Remembering the username isn’t a problem, but if you don’t have a consistent policy of always-using-a-username or always-using-the-email (as the lesspass username) it can be difficult to remember that. Similar situation with the URL, if it’s not abbreviated consistently, then it’s a problem.

      That said, I still use LessPass for everything and just deal with the edgecase problems.

    • ogarcia@lemmy.worldEnglish
      1·
      11 months ago

      In my view, both a password file (vault/database) and LessPass are potentially attackable via brute force. I don’t see that one is safer than the other.