Does anybody have hands-on experience with stateless password generators (managers) like Getpass?

It seems like it does most of the work of cloud password managers, but leans more to the security side as there is no servers with passwords to penetrate.

  • 9
    There are plenty of password managers that use local storage. You can sync those using your own choice of cloud service (Dropbox, Box, iCloud, Drive, OneDrive, etc.), or not at all. It's up to you
    – Alexander
    Jul 30, 2019 at 5:45
  • 24
    "leans more to the security side" - that's not a fair assessment. They all lean to the security side - this type of tool has a feature that mitigates one type of risk.
    – schroeder
    Jul 30, 2019 at 7:14
  • 10
    I use keepass. One of the nice advantages is that it doesn't simply store my passwords. I can store a lot of other pieces of data about a certain account, including "attachments". Obviously a stateless password manager cannot be used for anything other than passwords which, for me, is a pretty big limitation Jul 30, 2019 at 14:41
  • 1
    @Alexander Dropbox recently changed their free plan to limit to 3 devices, it used to be perfect for syncing Keepass. iCloud is apple only, Google Drive is meh, OneDrive is Microsoft based.
    – JMK
    Jul 31, 2019 at 11:56
  • 2
    @JMK I manage to keep to exactly 3 devices and sync my KeePass file over dropbox. But there's another downside: the Android client doesn't upload changed files automatically. There are 3rd-party clients that do. Until they get broken.
    – Chris H
    Aug 1, 2019 at 14:47

7 Answers 7


I have used a stateless password generator for years, and I think there are a lot of drawbacks:

  • If your master password is compromised, all of your passwords are. In comparison, standard password managers requires that the attacker both compromise the master key and gain access to the password store.
  • If a website has a password policy, you might not be able to generate a password that respects it.
  • If one of the passwords needs to be updated for some reason, you need to keep that state somewhere. For example, you need to remember to generate a password for "StackExchange2" instead of "StackExchange".
  • If you already have some passwords that you can't change (for various reasons), a static password generator won't help you.

For all those reasons, I think you should definitively use standard password managers.

  • 38
    The biggest advantage of stateless password manager is that you don't have to keep an extra file. If you end up having to maintain an extra file anyway for all those site specific variables, that kinda defeats the point of using stateless password manager.
    – Lie Ryan
    Jul 30, 2019 at 3:24
  • 2
    The lat con might well be the worst of them all. Might be good to sort that one on top and emphasize it more, because people use some really awful passwords, also for password managers, and whereas a password manager would have to be compromised itself (without the password database, the master password is useless), here a compromise of the key would be disastrous, plus that the key can be brute forced by any website owner if they wish (and if they make a correct assumption about your password hashing settings, which aren't secret under Kerckhoff's principle).
    – Luc
    Jul 30, 2019 at 7:54
  • 1
    @Luc but the last con is not that huge, because in most cases the encrypted passwords are stored somewhere online. And whatever that is, it is either secured only be the master password itself, or by a second password - which the user has to remember together with the master-password (so in the end effectively just a longer master-password, which when stolen allows access to all passwords)
    – Falco
    Jul 30, 2019 at 8:25
  • 1
    I roll my own stateless password manager (vks.ai/ppm) and I have had no issues. Only the fact that if indeed my master password would ever be compromised and people are tech savy enough to abuse it. But this a risk I am willing to take. Addressing the points: I have so far never had an issue where my method did not meet the password policy (and I'm using it for a few years now). The cool thing about StackExchange and then StackExchange2 is that usually you do remember the number. But if you don't, you can easily brute force it within 3 attempts (highest I reached is 5). Jul 30, 2019 at 11:16
  • 2
    Re: point 3, LessPass (another stateless password manager) supports having options that get hashed in and used as part of the generation; one such option is a number that you can increment. They solve the "having to remember" issue by allowing you to keep a database of username/site/options, but the password generation itself is stateless and the database is just a convenience
    – Piccolo
    Jul 30, 2019 at 15:38

Here are two less often mentioned problems.

  • Determining the website is hard. You want to use a different password for a.github.io and b.github.io, but you want the same password for microsoft.com and live.com, or wikipedia.org and wikimedia.org.
  • Changing anything breaks passwords. Once you've released your password manager and people start using it, you can't change anything about it, or users can't log in anymore. The way domains are handled must remain the same, even though domains change ownership. The way passwords are hashed must remain the same, even when a vulnerability is discovered in the algorithm.

See also my blog post about this.

  • If you release an optional new version, people would have to change their passwords once on all pages to use the new version. It would not be fun, but could be done. - I would likely do the same thing if my masterpassword with a file-based password manager was compromised (since the file is usually accessible somewhere online)
    – Falco
    Aug 9, 2019 at 13:19

1. Password managers provide additional options

A key difference between using a stateless password manager and a password manager is that password managers can store additional data such as

  • Security Questions
  • Credit/Debit card numbers
  • Id card numbers
  • Cryptographic keys
  • WiFi passwords
  • API keys, etc...

2. Existing passwords cannot be accommodated

Password managers can accommodate existing passwords. But a Stateless password manager will force you to change passwords for all your existing sites.

This is very important if you want to store passwords for any account where you are not authorized to change the password. This can be a shared office mailbox, server password, etc...

3. Deterministic password generators cannot accommodate varying password policies.

Some sites will need mandatory symbols with passwords but some sites do not allow symbols in passwords. Some websites like Payback support only numeric PIN.

Users either need to tweak the generated password or change settings. In either case, they need to keep the tweak or settings in memory which is not good.

  • 6
    For #3, you also need to record what the password policy was when you created the password. I have at least one account where my password violates their new password policy, but the old one is still good.
    – Tezra
    Jul 30, 2019 at 19:07

Besides those already mentioned, one more problem is that you cannot change your master password. Switching to a new master password would require changing your password on all the web sites where you've used the generator.


The problem is that it doesn't add that much meaningful security.

Instead of using your password directly, you use a publicly available function instead of your password. Let's use the example on their website for a demonstration:

Login: andromeda
Website: milkyway.com
Secret Keyword: 2,52m light years away

Produces password: 3q_q(MFWaMGeao+[CX

You may say 3q_q(MFWaMGeao+[CX is your password, but it's really not. It's actually 2,52m light years away, which is not very entropic. Is it better than just using 2,52m light years away? Yes, but not by that much.

Instead, use an offline password manager and generate an actually random password. It's about as much work on your end, and gives you much more real security.

  • 8
    Well to be fair, 2,52m light years away on its own isn't your password. It's 2,52m light years away plus the knowledge that you use Getpass. Granted that second component is pretty easy to brute force, as it's only a small multiplier of the former (since there's only a handful of popular password generation algorithms
    – Alexander
    Jul 30, 2019 at 5:47
  • 7
    -1 "it doesn't give you any added security" isn't true. The security properties are similar to and even slightly stronger than general client-side hashing (which all software should be doing anyway). It isn't a perfect solution, but it's also not useless.
    – Luc
    Jul 30, 2019 at 7:50
  • 6
    It does give you extra security, provided your master password is very entropic. A stateless password manager prevents the (all too common) situation where a website that stores your password in plaintext is compromised, and then the same password is used to log into other sites you frequent (yes, password re-use is bad, but an ordinary human can't remember more than 2 or 3 high entropy passwords).
    – James_pic
    Jul 30, 2019 at 9:38
  • 9
    @James_pic Countering password reuse is the entire point of using a password manager.
    – user163495
    Jul 30, 2019 at 16:04
  • 5
    @MechMK1 "I would wager that the security gained by using getpass is significantly less than using an actually random password." This is not a wager, you are simply correct about that. Random is clearly better than derived. But still, the "it does not give you any added security" part of your answer is not correct, or at least it's more nuanced than that. Using the plaintext password disallows you from reusing it. By sending a salted hash (where the site name is the salt), you have a unique login token for every site. Better than reusing the password, so definitely not 'no added security'.
    – Luc
    Jul 30, 2019 at 21:29

One more I haven't seen mentioned explicitly (as of writing all existing answers also make good points):

If an attacker gets hold of one of your generated passwords, now they are able to try cracking your master password from it, gaining access to all your accounts.

It's relatively easy to get one low-value password, whether through phishing, plaintext password leaks (even Google apparently is not immune to that), keylogging on a public computer, open WiFi on sites not using https, etc. The whole point of using a password manager is that one site's bad security should not provide any advantage in attacking you on some other site.

Sure, a strong enough master password can prevent this from being a problem. But a "traditional" password manager doesn't have this attack vector at all.

  • 1
    +1 This is the only disadvantage that really matters. All others are mere inconveniences.
    – Agent_L
    Aug 1, 2019 at 11:31
  • 4
    I agree basically, but if the master password is sufficiently strong and the password manager uses a good one-way function (ideally a password-hashing function like scrypt or so), then it should not be easy/able to brute-force. That said, this is the same discussion of why we usually do password hashing on servers. The only difference is: You control/know the factors that contribute and can (theoretically) estimate whether a brute-force attack would be successful.
    – rugk
    Aug 1, 2019 at 15:20
  • This answer is wrong, technically. With a stateless password manager using a one-way hash function, it is impossible to brute-force the master password from a generated password. What you only get is collisions, which are useless for cracking other generated passwords. The real risk for a stateless password manager is when your hardware generating password contain backdoors, cause everything it generates get leaked out.
    – Explorer09
    Jun 18, 2023 at 11:33
  • @Explorer09, no. I am absolutely aware that a one-way hash function is not reversible. But it is absolutely brute-forceable. In the extreme, consider a password consisting of a single numeric character. It will hash to one of 10 possible values (because there are 10 possible inputs to the hash function). To "brute force" the hash, all you do is run the hash function over every possible input and see if the output matches the known hash. This is not a collision. Collision based attacks are only theoretically possible, and only for very weak hashes. Nobody tries for a collision attack.
    – Ben
    Jun 19, 2023 at 19:28
  • @Ben And this is the reason you shouldn't use a weak master password in the first place! A stateless password manager is never designed to work with a master password that is short or weak, if you use a weak one and you complain about the password being brute-forced, it's your fault. A strong master password will never have this problem -- those who try brute-forcing will likely get a collision before the real master password being discovered.
    – Explorer09
    Jun 20, 2023 at 21:24

If you have to change a password then a stateless password manager mostly works with a counter to get the possibility for more than one variation in the password calculation. If you have many passwords it is almost impossible to remember what counter number you have used.

I have tested a lot of stateless password managers and I must acknowledge it is a very attractive solution if you have to remember a few passwords and don’t have to keep other secrets within a vault password manager.

It is also possible to use a stateless password manager as a password generator and backup for your vault password manager?

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .