On 4/27/20 12:18 AM, Paride Legovini wrote: > It's still one static shared secret you need to enter every time. If it > gets stolen, because your browser or your computer is compromised, or in > a MITM attack where the attacker gained access to a valid certificate > for salsa.debian.org [1,2], your account is gone. It gets much, much > more difficult with 2FA.
You're mixing many things here, so let's debunk one by one. 1/ If my browser or computer is compromised, then it's game over anyways. 2/ If what the attacker is trying to get access to your account (and eventually later, change the 2FA / password couple), then having 2FA doesn't help against MITM. 3/ I don't enter anything, my password manager does it for me (so it doesn't go into the clipboard). Now, X-Window could be hacked, but that really means we're in case 1. > The amount of annoyance added by the GitLab 2FA is extremely limited, > and implements *the* standard for web 2FA (webauthn). Personally I'd > like to see it required to get the DD status on salsa, or at least to > all whole Debian team. > > In general, we are switching from the cumbersome client certificate > approach of sso.debian.org to plain passwords. This doesn't sound right > to me. I think that with the tools we already have 2FA is as near as we > can get to the sweet spot of usability vs. security. What I hate here, is that we're switching from a "each person gets to keep its own secret safe and we trust him to do so" (ie: case of client side certs) to "we trust the centralized database of password, and we just hope it never gets hacked". I have serious doubts the choice is the correct one. I would prefer to risk that one or 2 person gets hacked, rather than the full password db / SSO provider. Cheers, Thomas Goirand (zigo)