[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Salsa update: no more "-guest" and more

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.


Thomas Goirand (zigo)

Reply to: