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
  • 13,979
  • 7
  • 65
  • 65
  • 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](https://chat.stackexchange.com/rooms/96816/discussion-between-qwerty01-and-pascalvkooten). – 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
  • 28,897
  • 12
  • 76
  • 102
  • 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
  • 125,553
  • 55
  • 289
  • 326
Kolappan N
  • 2,672
  • 14
  • 27
  • 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
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
  • 3,896
  • 1
  • 10
  • 22
  • 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
0

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,536
  • 2
  • 11
  • 23
Willem
  • 1