@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.
Indeed. However, see their FAQ:
@fribbledom Right, they have a counter. But then it's no longer 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. 😱
@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 this sounds neat on paper but it's a terrible idea.
@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 (https://github.com/mar-kolya/secure-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?
@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
@fribbledom PBKDF2 is not safe enough...
@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.
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!