"A stateless password manager"

I'm not sure yet whether I think this is amazingly brilliant or just insanely silly... it could be either:

@fribbledom So it generates a consistent password for each website?


Yeah, if I understand it correctly:

you use a master password, plus some site specifics (URL e.g.) to generate a password.

@fribbledom That's quite interesting, but you'll have to be careful with the algorithms you use.

@fribbledom I presume it's based on the idea of taking the name of the site and hashing it together with the master password?

That approach has a serious flaw: Changing passwords is impossible.

@fribbledom Right, they have a counter. But then it's no longer stateless. 🙂

@veer66 @fribbledom No. State needs to be stored somewhere. The master password is never stored anywhere.

@loke @fribbledom If a user doesn't store any counter too, it will be stateless?

Since this morning, I thought about just re trying with counter from one to three. When any counter is more than three, I will reset the master password.

However, the worst state may be the list of websites that I logged in. 🥺 Because I will need this list when I change the master password. 😱


@veer66 @fribbledom You will also need to change passwords on every single site when you change the master password.

@fribbledom I used a methodology like this for awhile. I found I ended up needing a config file that designated password limits and a per-site seed for the generator (due to forced rotations), and that became just as important and sensitive as a key vault.

@trysdyn @fribbledom I think a shared public repository of per-site information about password limits and constraints would make this a lot more usable. There's no reason that part needs to be sensitive. I think the only sensitive state is the counter of how many times you've rotated that password, right?

That said, personally I'm hoping for broad adoption of WebAuthn or something to replace shared secrets entirely.

@fribbledom if you don't want to deal with the hassle of keeping a database in-sync and not-corrupted-by-fucking-nextcloud it's pretty good

@fribbledom Hmm, with this you make password spray attacks easier. Just spray Master passwords against all services your victim uses. And once you hit it, you got them all. Not sure if the makers are aware of this limitation.

@fribbledom ah yeah, the classic “brain wallet” solution to security

@fribbledom You'll never change your passwords again!

...because you literally won't be able to

@fribbledom There was something similar called Master Password. It had no counter so multiple users on a site or changing password was not possible without ugly hacks. Counters is still an ugly hack. And to be safe I had to use ridiculously long passphrase. Soon bored myself enough to switch.

@fribbledom being stateless that way means that it's a key derivation algorithm. If your password gets compromised, your public username and site name are already widely known, where the only missing part is your master password. The crucial part here is: is such function bijective?

hashlib.pbkdf2_hmac("sha256", master_password.encode("utf-8"), salt.encode("utf-8"), 100000, 32)

It's brute-forceable if your master password is weak.

I'll continue trusting my passwords to a "stateful" password manager with passwords generated by a random password generator ( Some sites I use have unreasoable requirements, such as 6-8 chars long or up to 8-24 chars with no special chars.

@fribbledom after reading "How it works" I'm leaning to "brilliant" :-) I especially like the ability to re-generate your password via web site without installing anything.

@fribbledom I suspect you have to remember a few too many things to be practical - your bank's password policy?

@quarky @fribbledom The question then becomes: does autosyncing the password options make this inherently insecure?

@fribbledom I've been using a stateless password manager for close to 10 years now. I've got around the "you can't change your password" problem by having it generate 2 passwords for each site. One password has special symbols (for those that require it) and the other has no special symbols (for those that prohibit it). For 95% of sites it works great. Those 5% are a pain, though.

@fribbledom remembering options besides the "counter" is too much

other than that, I approve

@fribbledom won‘t work because I can‘t remember my user name, too

Da muss ich erst mal drüber nachdenken.

So ... what if I want to change my master password, or a website has multiple points of entry, or switches URL ...?

Keepass plus syncthing works nicely for me, and the very few passwords I might need on other people's devices, I know by heart.

If I ever need more, I still have keepass on my phone so I could get to the passwords, even if it's a little less comfortable.

@fribbledom I think it's a nice idea for some scenarious, but I also think that a major drawback is that if your master password gets leaked in some way, all your passwords are automatically known too.

In the case of a locally stored encrypted db, an attacker would need to access both the db itself and the master password to get you in trouble.

Another thing is that I'm a bit suspicious about browser integrations. What if the page's JS tries to somehow grab the master password field?

@fribbledom My thoughts:
- Access to an offline passwordmanagerfile can be considered a second factor.
- Having to remember options and generation for each website counters the concept.
- Non-bijectivity and crypto have to be proven
- Effectively, this system just takes the concept of "one master password for all services" and protects it from bad password-handling on the serverside. I am not sure wether this is the only reason why masterpasswords are bad.

@fribbledom friend used to use this, or atleast something built using the same idea

Seemed to work, but they’ve gone to a traditional password manager

@Mikescops @fribbledom Yes, current state of the art for password based key derivation is argon2id. This is because PBKDF2 with SHA256 in this case is very weak against FPGAs, GPUs and ASICs. Argon2id makes RAM the bottleneck for bruteforcing thereby increasing the cost thereof by many orders of magnitude.

@fribbledom those things have been around for a long time. I used to use one in the late '00s, early '10s. It used a laughably simple hashing process compared to this one though, and produced passwords which were just 8-character hexadecimal strings. Ah, how innocent we were.

Sign in to participate in the conversation

Server run by the main developers of the project 🐘 It is not focused on any particular niche interest - everyone is welcome as long as you follow our code of conduct!