Hi, Maarten and the Spectre developers.
This post is about suggestions on how a stateless password manager can be useful in the future. I talk mostly for my use case and experience.
Firstly, thanks you for the work on Master Password and Spectre, as I am also a believer that almost all password managers suck.
As you all know that traditional password managers save password of different accounts into a "encrypted vault" that requires syncing across multiple devices (laptops and phones) in order to become useful and it becomes a risk when the vault falls into the hand of someone else or get lost so you can't recover your accounts.
I believe being stateless would be the ideal way of keeping my password. At least for my use case.
Here is the way I manage my passwords: I usually think of a good, secret passphrase, mixed with some numbers and punctuation, that would be easy to remember for me, but difficult to crack by brute force. I also adopted a scheme of incorporating the service/website name into my "secret", which is a very simply way to avoid reusing the same passphrase across services.
An example of how this "secret" passphrase could look like (it's not the secret I use for my personal accounts, but just to give everyone an idea):
ZOMbie-tangerine:4TH*war>TWITTER
ZOMbie-tangerine:4TH*war>FACEBOOK
ZOMbie-tangerine:4TH*war>GOOGLE
Try putting the above example into any online password strength checker. Most of them would say it's very strong for now.
It's my belief that the best passwords are the ones easy to remember for humans and difficult to crack by computers, and to keep the secret all in my head (not storing it in a password manager or anywhere).
While I liked the stateless approach of Spectre, I soon found out that Spectre (as well as LessPass) was designed to be over-complicated for the use case I have in mind.
To help explaining this, let me present a simplified diagram of how Spectre algorithm generates passwords (note: you are free to reuse this picture in places that need to explain the Spectre algorithm. I hereby grant you permission for that)
As you can see there are 3 or 4 inputs that the user (me) needs to type in. This limits how the password generator can be useful. The most important part is that I have to type my secret, user name, and site name as three separate fields.
The diagram below is what I considered the "ideal" way for a stateless password generator:
When I have come up a way of making a secret passphrase, with site name incorporated, before using any password manager, I just want a single text field to type in "the combined thing". For people who aren't used to this scheme of generating passphrases, the password manager UI can provide separate text fields for each (secret, user name, site name) as an optional feature.
With one text field to type in the combined secret || user name || site name, the stateless password generator tool might look like no more than a "password encryptor" or "passphrase transformer", but that's fine. Because after all, my experience tells me that people need password managers because of:
- Websites / services imposing stupid password policies (most importantly the limit on password length) that prevents a good, long and strong passphrase from applying everywhere.
- Passphrases transmitted on the Web as plaintext, or merely TLS-encrypted but unhashed, with servers potentially storing user passwords as plaintext as well.
Instead of expecting servers to revise the stupid password policies (I'm not against password policies in general, but it's just many of them that did more nuisance than good) or encrypting the passwords the proper way (with scrypt or Argon2), I realize the real thing I need is password hashing at client side and I believe that's the role that a stateless password manager should take.
