On 2020-04-28 18:48, Jeremy Stanley wrote:
On 2020-04-28 14:32:55 +0200 (+0200), Bernd Zeimetz wrote:
On 2020-04-28 14:27, PICCA Frederic-Emmanuel wrote:
> Is it possible to use it's ssh key in order to have acces to
> the salsa api ? I mean instead of the token, which looks to me
> quite fragile compare to ssh via a gpg card and the gpg agent.
The api works with a token - and without 2fa. That will not change
if you enforce 2fa.
If you use ssh, you can create an own account for the ssh key and
give it very special permissions, if you need it for automatic
pushes or similar things.
So to summarize, 2FA in Salsa may protect against someone losing
control of their WebUI credentials, but does nothing to secure
against theft of API keys they've generated, nor of an SSH key
persisted/forwarded in an agent or left lying around unencrypted (or
easily guessed because someone made unfortunate choices when
patching a random number generator).
Hopefully adding those requires reauthenticating with 2FA even in an
open session.
Before adding security controls, it's a good idea to assess your
threat model. Is it the same as projects which experienced high
profile compromises like the Linux kernel archive or Matrix, where
the attackers leveraged stolen SSH keys to gain a foothold? What is
Salsa hosting which would be sensitive if altered? Source code. And
how are those alterations normally applied? Git over SSH. (Granted,
there's discussion of using its WebUI to authenticate sessions for
other project systems, so that does potentially change the risks
involved.)
While that's true that's also a "it needs to provide perfect security"
argument. While I'd also like to see 2FA gain proper support for
authenticated key use including touch (FIDO/U2F support landed in
OpenSSH), it also solves a different problem. The problem here is
phishing. And unfortunately even the most technically adept users can be
phished when they let their guard down.
I agree that having 2FA support in Salsa is great, but providing it
for those who want to rely on it for their accounts is different
from unilaterally forcing it on all users even if they find it a
significant additional inconvenience for little actual benefit.
Thankfully, it sounds like the Salsa admins plan to keep use of 2FA
voluntary.
It's a risk assessment and one of the population it needs to support. I
think one should encourage people to set up 2FA and if necessary send
out some hardware if there's an undue hardship. And then eventually make
it mandatory. I fully understand that this is currently infeasible, but
if Salsa is going to be the primary development platform we eventually
need to trust, it should probably go into the direction of having a 2FA
requirement as an ultimate goal.
Or we decide not to trust it because of its exposure and everyone else
needs to work around that. I know ftp-master, DSA and other service
owners have to do this today for good reasons. That pushes the cost
elsewhere of course. On the other hand it's not the worst idea to
require signatures on all commits instead.
Kind regards
Philipp Kern
