Thomas Goirand <z...@debian.org> writes: > Now, if you want something safer, maybe we could implement something > that involves crypto a smarter way, like SQRL, so we avoid storing any > password in Salsa, even hashed: > https://www.grc.com/sqrl/sqrl.htm
I don't know anything about SQRL (and am too lazy to try to digest the PDFs on that web site), but I'll assume that this shares with PAKE schemes the requirement that the client do crypto. PAKE has always looked like a good idea up until one starts trying to tackle the problem of deploying clients everywhere you need them, at which point it usually ends up looking easier to just use TLS client certificates. I realize the advantage of a PAKE-style scheme is that you don't need to store a security artifact on a person's computer, just get them to enter in a password, but personally I consider passwords to be a bug rather than a feature. We're already at the point where remembering a strong password is too difficult for the average person. I think it's more likely that computer security will evolve towards using passwords only as physical-presence-only PINs to unlock local secure storage, rather than making an attempt to improve passwords as a network protocol. That's effectively what a password manager simulates, albeit trading off local secure storage for convenience while limiting the strong passwords someone has to memorize to one. I would argue that the only functional difference between a properly-configured password manager and using TLS client certificates is that password managers have better UI. (Which is important!) > Because seriously, I'm more concerned with Salsa itself being hacked, > and the password db of *all accounts* being stolen, or the Salsa SSO > provider being hacked, rather than having a *single* idiot user falling > into a phishing trap. GitLab uses bcrypt (although with no pepper, at least that [1] mentions, which is a shame), so if you're using randomly-generated passwords with a password manager, I'm not sure why you're worried about theft of the password database. It would be a problem for people using weak passwords, but doesn't that go back to your argument that we can assume Salsa users will generally follow good practices? [1] https://docs.gitlab.com/ee/security/password_storage.html The Salsa SSO provider being hacked is would allow the attacker to impersonate anyone to anything protected by Salsa, but that's obviously still true with SQRL, so it seems unrelated to the question of password storage. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>