52

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.

Cookiecutter
  • 631
  • 1
  • 5
  • 6
  • 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 '19 at 05: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 '19 at 07:14
  • If it doesn't depend on state, what does it depend on? Does that contain a vulnerability? – Mast Jul 30 '19 at 07:54
  • 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 – Giacomo Alzetta Jul 30 '19 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 '19 at 11:56
  • 1
    @JMK there's also mega.nz (The owner got burned by the FBI in the past and learned the lesson. It's now a paranoid service, centered on the privacy of the users' data: they don't want to know what you store on their service so that they cannot get blamed for hosting it. If their web crawler finds a private key they automatically delete the associated data, without looking into it.) – A. Hersean Jul 31 '19 at 12:57
  • Also, if you don't trust cloud services, you could sync a local password database (e.g. from KeePass) between your devices using a syncing program like Syncthing or Resilio Sync. – user31389 Jul 31 '19 at 14:39
  • 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 01 '19 at 14:47

7 Answers7

83

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.

Benoit Esnard
  • 14,694
  • 7
  • 69
  • 69
  • Thank you! So you switched to a standard password manager? It seems to me that all except your last point can be solved by binding that data to a website variable – Cookiecutter Jul 29 '19 at 19:30
  • 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 '19 at 03:24
  • @LieRyan indeed. By using one of these you'd have to manually synch between all your computers and devices by moving files around. At best cumbersome in the extreme, at worst a serious security problem and possibly impossible (given the restrictions in secure environments on introducing external files). – jwenting Jul 30 '19 at 07:42
  • 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 '19 at 07: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 '19 at 08:25
  • 1
    I roll my own stateless password manager (https://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). – PascalVKooten Jul 30 '19 at 11:16
  • 1
    @PascalVKooten you might want to consider sticking with one that has had proper auditing...with your current implementation, rainbow tables could be set up on a per-site basis to crack the master password – Qwerty01 Jul 30 '19 at 14:55
  • @Qwerty01 It would be too slow or too expensive to crack - that's the idea of a slow hashing function like scrypt and a long master password. This will make it so there's no point to attempt a rainbow attack. – PascalVKooten Jul 30 '19 at 15:01
  • @PascalVKooten The point of a rainbow table is to do expensive calculations once--the only thing barring others from doing so currently is because your implementation is not widely used enough to make it profitable. – Qwerty01 Jul 30 '19 at 15:04
  • @Qwerty01 You use rainbow tables only when you can reuse the calculations, which is not the case here. But note that people are not going to attempt to create rainbow tables for slow hashing functions as it would simply not be affordable. Yes, the idea sounds great... reusing the calculations... but slow hashing functions are simply too expensive to do this for (unless you assume very short master passwords). – PascalVKooten Jul 30 '19 at 15:07
  • 1
    @PascalVKooten you can reuse it with your implementation...the salt you use is the site name, so anyone else using that site will have the same salt. – Qwerty01 Jul 30 '19 at 15:11
  • @Qwerty01 Yea, but the salt is indeed not a secret. It fully relies on the master password for security. So let's indeed say you know my site name (and everyone else uses it too), you still have to do so many expensive computations that it is not worth it. – PascalVKooten Jul 30 '19 at 15:12
  • 1
    Let us continue this discussion in chat. – Qwerty01 Jul 30 '19 at 15:13
  • 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 '19 at 15:38
  • "standard password managers requires to compromise both the encrypted passwords and the master key." - I don't understand this. Surely just the the master key must be compromised (plus maybe any MFA), since the user only has to input the master key (+MFA) in order to access the encrypted passwords. Otherwise it sounds like the standard password managers you've used require the user to memorize all their passwords in order to access their passwords. Or did you mean that the attacker must both compromise the master key and gain access to the database? – 8bittree Jul 31 '19 at 21:01
  • @8bittree: If I told you my master key, you couldn't do anything unless you already have access to my encrypted password database: you can't decrypt something you don't have. That's why both are necessary! – Benoit Esnard Aug 01 '19 at 07:58
  • 1
    @BenoitEsnard The confusion here is probably over what constitutes a "standard" password manager. It might be better to be more explicit, e.g. "file-based password manager", to distinguish from a "cloud-based password manager" like 1Password, where you access the database remotely. – IMSoP Aug 01 '19 at 10:58
  • 1
    @BenoitEsnard That makes more sense. I suggested an edit that I think makes the wording more clear. – 8bittree Aug 01 '19 at 15:00
  • @BenoitEsnard but most people don't copy the file from their password manager by hand to all devices they are using every time they register for a new page? You store the file most likely somewhere online, where you can access it with your master-password. So only one thing needs to be compromised, or you have a lot of hassle with transferring files via USB. – Falco Aug 09 '19 at 13:17
44

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.

Sjoerd
  • 30,589
  • 13
  • 80
  • 107
  • 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 09 '19 at 13:19
22

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.

schroeder
  • 129,372
  • 55
  • 299
  • 340
Kolappan N
  • 2,692
  • 15
  • 29
  • 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 '19 at 19:07
17

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.

Daniel Darabos
  • 540
  • 3
  • 6
10

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.

Community
  • 1
  • 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 '19 at 05:47
  • 3
    @Alexander https://en.wikipedia.org/wiki/Kerckhoffs%27s_principle – Federico Poloni Jul 30 '19 at 07:40
  • 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 '19 at 07: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 '19 at 09:38
  • @Luc I would wager that the security gained by using getpass is significantly less than using an actually random password. –  Jul 30 '19 at 16:03
  • 9
    @James_pic Countering password reuse is the entire point of using a password manager. –  Jul 30 '19 at 16:04
  • 2
    @MechMK1 yes, and so long as the master password has enough entropy, a stateless password manager still counters password reuse. – James_pic Jul 30 '19 at 16:29
  • 1
    @James_pic Yes and no. If you assume a password/passphrase is strong enough to not be crackable, then you might as well use that password for everything and not lose too much. Yes, you are in danger of websites using plaintext passwords, but those are dying out very quickly. Even the worst offenders use at least MD5 now. –  Jul 30 '19 at 17:41
  • 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 '19 at 21:29
  • 2
    So that is my reason for downvoting, I feel like it is wrong to the point where it may be harmful. Someone may not want to use a password manager (for reasons beyond the scope of this comment) but might be okay with a stateless pwdgenerator. You might discourage them and basically tell them to use plaintexts instead. So it's not personal, and if the answer were changed to reflect this (assuming you see the logic of my point), I would also change the vote (assuming I saw the edit). – Luc Jul 30 '19 at 21:33
  • @Luc I changed the wording to reflect that. I stated it as not adding that much security, but still being better than using a low-entropy password. –  Jul 31 '19 at 12:44
  • Let's get the facts straight. A stateless password manager is no different from a client side hashing of a master password. It was merely to address many awkward password policies of websites that didn't even make user accounts more secure. Using a stateless password manager doesn't mean you must use a single master password. Actually you can remember two or three as long as you know which master password is associated to which accounts. – Explorer09 Jun 18 '23 at 11:48
10

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.

Ben
  • 4,032
  • 1
  • 12
  • 23
  • 1
    +1 This is the only disadvantage that really matters. All others are mere inconveniences. – Agent_L Aug 01 '19 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 01 '19 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 '23 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 '23 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 '23 at 21:24
  • @Ben Here's a tip: Your master password should never be shorter than the password whatever your "password manager" generates. No password manager can magically turn a weak password into a strong one (stateless or not). – Explorer09 Jun 20 '23 at 21:28
  • @Explorer09 yes, I know. Thats why in my answer I very explicitly say "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." Both stateless and stateful managers are actually, practically vulnerable to a local attacker. Only stateless are (theoretically, if not practically) vulnerable without ever touching your system at all. – Ben Jun 23 '23 at 15:13
  • @Ben I can't say that the comparison is fair without mentioning that the encrypted database of a "traditional" password manager can be stolen if it was ever uploaded into the cloud (as a backup or for other purposes). Although a stateless manager doesn't need a database in order to start cracking, a "traditional" manager isn't safe from a similar threat, since the user would likely back up the database in multiple places, and each having the risk of being stolen. – Explorer09 Jun 25 '23 at 02:44
  • @Explorer09 the difference is you can put your backup at one or two VERY SPECIFIC backup storage places, whether in the cloud or not, and have a great deal of flexibility in picking a secure backup provider. With a stateless manager, you're at the mercy of the security of EACH AND EVERY ONE of the accounts you use the password manager with. I currently have close to 250 accounts in my password manager. That would be 250 separate chances for my master password to be attacked. All it takes is ONE site out of that 250 with shitty password storage or stupid logging practices or site compromise. – Ben Jun 30 '23 at 22:45
  • @Ben What if I trust no places? Your argument for a "traditional" password manager assumes there is a place I can trust for storage, but I wish to trust no one! – Explorer09 Jul 20 '23 at 20:36
1

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?

Sir Muffington
  • 1,611
  • 2
  • 13
  • 25
Willem
  • 11
  • 1