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). 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.) 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. -- Jeremy Stanley
Attachment:
signature.asc
Description: PGP signature