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

[Tomas Pospisek]

On 30.04.20 01:15, Bernd Zeimetz wrote:
> 
> On 4/28/20 3:20 PM, Thomas Goirand wrote:
> 
>> That's not the case. An MITM attack could gain a session and maintain it
>> open, while the end user would just notice "oh shit, I miss-typed the
>> 2FA numbers, let's try again". Then the only thing the attacker needs to
>> do is keep the session open to not loose access...
> 
> I hope you realize that no session is open forever.

Just for giggles: [longest TCP
connection](https://ask.slashdot.org/comments.pl?sid=1462=1673396)

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

[Bernd Zeimetz]

On 4/28/20 3:20 PM, Thomas Goirand wrote:

> That's not the case. An MITM attack could gain a session and maintain it
> open, while the end user would just notice "oh shit, I miss-typed the
> 2FA numbers, let's try again". Then the only thing the attacker needs to
> do is keep the session open to not loose access...

I hope you realize that no session is open forever.

-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F

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

[Philipp Kern]

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

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

[Jeremy Stanley]

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


signature.asc
Description: PGP signature

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

[Bastian Blank]

On Tue, Apr 28, 2020 at 02:32:55PM +0200, Bernd Zeimetz wrote:
> 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.

Or add it as writable deploy key to a project.

Bastian

-- 
I'm a soldier, not a diplomat.  I can only tell the truth.
-- Kirk, "Errand of Mercy", stardate 3198.9

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

[Thomas Goirand]

On 4/28/20 2:30 PM, Bernd Zeimetz wrote:
> 
> 
> On 4/27/20 2:49 AM, Paride Legovini wrote:
>> An active MITM attack is way more complicated than just sniffing and
>> storing traffic for later analysis. Changing the 2FA or password is not
>> a great strategy, as you would immediately realize what's going on.
>> Silently gaining access to an account allows to act when the conditions
>> are the best from the attacker's point of view.
> 
> Exactly.
> An attacker would gain access to a few accounts, wait and see what they
> can do with the gained permissions in the long run. And at some point
> compromise something.
> 
> 2FA stops this kind of attacks completely. Without a current 2fa token,
> your password knowledge is useless.
> 
> Gaining access with a MITM attack once gives you a very short amount of
> time to do whatever you want to do, as your login will be gone as soon
> as the next login without MITM happens.

That's not the case. An MITM attack could gain a session and maintain it
open, while the end user would just notice "oh shit, I miss-typed the
2FA numbers, let's try again". Then the only thing the attacker needs to
do is keep the session open to not loose access...

Cheers,

Thomas Goirand (zigo)

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

[Bernd Zeimetz]

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.


--
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F

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

[Bernd Zeimetz]

On 4/27/20 2:49 AM, Paride Legovini wrote:
> An active MITM attack is way more complicated than just sniffing and
> storing traffic for later analysis. Changing the 2FA or password is not
> a great strategy, as you would immediately realize what's going on.
> Silently gaining access to an account allows to act when the conditions
> are the best from the attacker's point of view.

Exactly.
An attacker would gain access to a few accounts, wait and see what they
can do with the gained permissions in the long run. And at some point
compromise something.

2FA stops this kind of attacks completely. Without a current 2fa token,
your password knowledge is useless.

Gaining access with a MITM attack once gives you a very short amount of
time to do whatever you want to do, as your login will be gone as soon
as the next login without MITM happens.


-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F

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

[Bernd Zeimetz]

On 4/26/20 10:29 PM, Jeremy Stanley wrote:
> You're already seeing quite a few folks responding that being
> required to use an additional application or device each time they
> authenticate would be an inconvenience to them. This is a signal. I
> personally wouldn't enjoy being prompted to activate my TOTP client
> software every time I invoke `git push` so I can understand the
> resistance to your proposal.

Well, use an ssh key than. No need for 2fa there.


-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F



signature.asc
Description: OpenPGP digital signature

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

[Philipp Kern]

On 2020-04-28 05:08, Wookey wrote:

On 2020-04-26 14:07 +0200, Bernd Zeimetz wrote:

Hi,

Google Authenticator is a software-based authenticator by Google that
implements two-step verification services using the Time-based 
One-time
Password Algorithm (TOTP; specified in RFC 6238) and HMAC-based 
One-time
Password algorithm (HOTP; specified in RFC 4226), for authenticating 
users of

software applications.

There are even cli tools that do the same stuff. I'd guess there is at 
least

one on Debian.


yes oathtool.

But this is still a PITA for sites where it is required, like
microsoft and google. I don't want to have to do this for Debian stuff
too. (run this auth program, then have a menu to say which site I
am making the number for so it knows which token to use, then paste
the resulting magic number into a webform). Are you proposing
something less tiresome than this?

I would much prefer to continue to be trusted not to have a shit
password and take reasonable care in using it. Or that PAKE thing
sounded like it might work quite well and the site didn't have to keep
the whole password list. But my experience of 2FA so far has been
deeply irksome, so I resent it being enforced, unless there is some
way of not having to go through that rigmarole every time (the above
sites generally only make me do it every two weeks - if it was every
time I'd explode). But if every site started doing this it would be
truly awful - one has hundreds of logins these days.

Debian is one place that has a reasonably competent userbase - I
remain unconvinced that we need to change things.


It's kinda weird that the solution exists with 2FA FIDO tokens using 
webauthn. (Like the current generation of Yubikeys but there are of 
course others.) Gitlab supports that.


I mean I don't want to suggest that buying hardware is required, but 
that's literally what they were designed for. Automatically dealing with 
origin information sanely and then a touch signs you in. OTPs are as 
fishable as passwords.


Kind regards
Philipp Kern

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

[Ihor Antonov]

On Monday, 27 April 2020 17:11:21 PDT Jeremy Stanley wrote:
> On 2020-04-27 16:28:39 -0700 (-0700), Ihor Antonov wrote:
> > On Friday, 24 April 2020 14:13:52 PDT Bernd Zeimetz wrote:
> > 
> > The subject of this thread was click-baity enough but this thread appears
> > to be a wonderful bike-shedding with MFA flavor.
> > 
> > Please help me find the original thread, as my Salsa account is still
> > "-guest" and I want no more of it.
> 
> Sign in at https://salsa.debian.org/ and then go to your account
> settings at https://salsa.debian.org/profile/account and use the
> "Change username" option to remove the -guest suffix (or change it
> to whatever you like really, so long as it's not already taken by
> someone else).

 Thanks Jeremy!

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

[Wookey]

On 2020-04-26 14:07 +0200, Bernd Zeimetz wrote:
> Hi,
> 
> Google Authenticator is a software-based authenticator by Google that
> implements two-step verification services using the Time-based One-time
> Password Algorithm (TOTP; specified in RFC 6238) and HMAC-based One-time
> Password algorithm (HOTP; specified in RFC 4226), for authenticating users of
> software applications.
> 
> There are even cli tools that do the same stuff. I'd guess there is at least
> one on Debian.

yes oathtool.

But this is still a PITA for sites where it is required, like
microsoft and google. I don't want to have to do this for Debian stuff
too. (run this auth program, then have a menu to say which site I
am making the number for so it knows which token to use, then paste
the resulting magic number into a webform). Are you proposing
something less tiresome than this?

I would much prefer to continue to be trusted not to have a shit
password and take reasonable care in using it. Or that PAKE thing
sounded like it might work quite well and the site didn't have to keep
the whole password list. But my experience of 2FA so far has been
deeply irksome, so I resent it being enforced, unless there is some
way of not having to go through that rigmarole every time (the above
sites generally only make me do it every two weeks - if it was every
time I'd explode). But if every site started doing this it would be
truly awful - one has hundreds of logins these days.

Debian is one place that has a reasonably competent userbase - I
remain unconvinced that we need to change things.

Wookey
-- 
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/


signature.asc
Description: PGP signature

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

[Jeremy Stanley]

On 2020-04-27 16:28:39 -0700 (-0700), Ihor Antonov wrote:
> On Friday, 24 April 2020 14:13:52 PDT Bernd Zeimetz wrote:
> 
> The subject of this thread was click-baity enough but this thread appears to 
> be a wonderful bike-shedding with MFA flavor.
> 
> Please help me find the original thread, as my Salsa account is still 
> "-guest" 
> and I want no more of it.

Sign in at https://salsa.debian.org/ and then go to your account
settings at https://salsa.debian.org/profile/account and use the
"Change username" option to remove the -guest suffix (or change it
to whatever you like really, so long as it's not already taken by
someone else).
-- 
Jeremy Stanley


signature.asc
Description: PGP signature

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

[Ihor Antonov]

On Friday, 24 April 2020 14:13:52 PDT Bernd Zeimetz wrote:

The subject of this thread was click-baity enough but this thread appears to 
be a wonderful bike-shedding with MFA flavor.

Please help me find the original thread, as my Salsa account is still "-guest" 
and I want no more of it.

Thanks

---
Ihor Antonov

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

[Moritz Mühlenhoff]

Russ Allbery  schrieb:
> Vincent Bernat  writes:
>
>> This is not how this is implemented. I am using GitHub and GitLab with
>> 2FA enabled and I am rarely asked to enter any token. Once you get
>> authenticated on a device, it remains for a long time.
>
> Pretty much every time I go to salsa.debian.org, I have to log back in
> again.  The "long time" seems subjectively to be a week or two (or maybe a
> month).  Am I doing something wrong?

This is probably caused by the fast-paced upstream release process, looking
at the archives of debian-infrastructure-announce, January has seen the
12.6/12.7 updates, February 12.8, March 12.9 and the 12.10 update happened
last Thursday.

Cheers,
Moritz

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

[Thomas Goirand]

On 4/27/20 7:34 PM, Russ Allbery wrote:
> Thomas Goirand  writes:
> 
>> Except that SQRL has no password involved, just crypto.
> 
>> Since you are too lazy to read on, let me do a tl;dr. Simply put, the
>> client holds a private key. From that private key, a new one is derived
>> doing a HMAC of that key with the domain, meaning a client has a unique
>> public/private keypair for each site. Then the site only holds the
>> public key, and the client auth using his private key (again, unique to
>> each site), presented a one time challenge.
> 
> Thanks for the explanation!
> 
> Why would we do this and not just use TLS (or X.509 more generally), which
> has essentially the same properties and for which implementations are far
> more widely available?  What you describe is basically equivalent to how
> Webauthn works except that Webauthn uses X.509 certs, for which there are
> numerous well-tested and audited implementations.

We just had chat on #debian-devel. It looks like Webauthn is similar,
yes. I'd be nice too.

Thomas Goirand (zigo)

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

[Russ Allbery]

Thomas Goirand  writes:

> Except that SQRL has no password involved, just crypto.

> Since you are too lazy to read on, let me do a tl;dr. Simply put, the
> client holds a private key. From that private key, a new one is derived
> doing a HMAC of that key with the domain, meaning a client has a unique
> public/private keypair for each site. Then the site only holds the
> public key, and the client auth using his private key (again, unique to
> each site), presented a one time challenge.

Thanks for the explanation!

Why would we do this and not just use TLS (or X.509 more generally), which
has essentially the same properties and for which implementations are far
more widely available?  What you describe is basically equivalent to how
Webauthn works except that Webauthn uses X.509 certs, for which there are
numerous well-tested and audited implementations.

-- 
Russ Allbery (r...@debian.org)  

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

[Thomas Goirand]

On 4/27/20 2:19 AM, Russ Allbery wrote:
> Thomas Goirand  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.

Except that SQRL has no password involved, just crypto.

Since you are too lazy to read on, let me do a tl;dr. Simply put, the
client holds a private key. From that private key, a new one is derived
doing a HMAC of that key with the domain, meaning a client has a unique
public/private keypair for each site. Then the site only holds the
public key, and the client auth using his private key (again, unique to
each site), presented a one time challenge.

As a result, the site *never* store any secret from the client (again:
no passwords involved), only the identity of the user (ie: his public
key for that site). So there's nothing to be stolen from the server,
which is the very point.

Cheers,

Thomas Goirand (zigo)

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

[Vincent Bernat]

 ❦ 26 avril 2020 15:04 -07, Russ Allbery:

>> This is not how this is implemented. I am using GitHub and GitLab with
>> 2FA enabled and I am rarely asked to enter any token. Once you get
>> authenticated on a device, it remains for a long time.
>
> Pretty much every time I go to salsa.debian.org, I have to log back in
> again.  The "long time" seems subjectively to be a week or two (or maybe a
> month).  Am I doing something wrong?

You are right. I don't have this issue on hosted gitlab.com, but maybe
it's because I work with it everyday. I have just enabled 2FA on Salsa.
I'll see if you also have to reenter 2FA each time.
-- 
Truth is the most valuable thing we have -- so let us economize it.
-- Mark Twain


signature.asc
Description: PGP signature

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

[Paride Legovini]

Thomas Goirand wrote on 27/04/2020:
> 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.

Well, I gave you two examples.

> 1/ If my browser or computer is compromised, then it's game over anyways.

This is true if you get *fully* compromised, but you could be affected
by a very narrow vulnerability which causes e.g. some browser memory to
leak under very specific conditions, requiring a carefully crafted
attack. If you happen to be affected by this kind of vulnerability
(spectre?) the game is far from over.

> 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.

An active MITM attack is way more complicated than just sniffing and
storing traffic for later analysis. Changing the 2FA or password is not
a great strategy, as you would immediately realize what's going on.
Silently gaining access to an account allows to act when the conditions
are the best from the attacker's point of view.

> 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.

My point is that *something* enters a password in a web form. In this
case it doesn't really matter if this is done by a program or by you
pressing keys on a keyboard.

Anyway, I have no doubt your way of managing passwords is excellent, but
I hope I've been able to show that "2FA will add nothing in my case" is
not true.

Paride

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

[Russ Allbery]

Russ Allbery  writes:

> 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!)

On re-reading this (which I should have done before sending it rather than
afterwards), I left out some context that made this statement look too
sweeping.  I meant that a password manager with random passwords and
client TLS certificates look similar in their security properties for a
user: you enter a password to unlock a secure store and then some opaque
blob in that secure store is used to authenticate.

Obviously, passwords (assuming no special crypto magic) are effectively
bearer tokens whereas TLS client certificates use asymmetric crypto, so
TLS client certificates are better than password managers for all the
normal reasons why asymmetric crypto is better than bearer tokens (defense
against man-in-the-middle eavesdropping, primarily).  My very rough
understanding of PAKE schemes (which may well be wrong) is that they
effectively turn passwords into asymmetric crypto, thus bringing them
closer to TLS certs except with a fairly weak asymmetric key.

-- 
Russ Allbery (r...@debian.org)  

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

[Russ Allbery]

Thomas Goirand  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)  

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

[Thomas Goirand]

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)

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

[Thomas Goirand]

On 4/26/20 8:34 PM, Bernd Zeimetz wrote:
> 
> 
> On 4/26/20 12:41 AM, Thomas Goirand wrote:
>> On 4/25/20 11:14 PM, Bernd Zeimetz wrote:
>>> Actually I think 2FA should be enforced for everybody.
>>> Even debian.org related passwords might get lost.
>>
>> I use strong password, stored with keepassxc, with the password db
>> encrypted using the HMAC of my yubikey. In what way is this not safe
>> enough already? 2FA will add nothing in my case, just more annoyance.
> 
> And then somebody sends you a phishing mail and you enter your password
> into salsa.debiana.org...

Nice try but ... I use the "Append Domain" plugin in Firefox, so that
Keepasxc can auto-type passwords if they match the URL of the site I'm
visiting, to what Keepassxc has in its database. So nice try, but your
phishing example doesn't work on me. :P

On 4/26/20 9:04 PM, Bernd Zeimetz wrote:
> So you have a browser integrated password manager and consider it
> secure? Interesting...

This wasn't addressed to me, but I'll reply anyways...

No, I don't use *any* browser integration. I just use the window title
of my browser with the "append domain" plugin to differentiate domains,
and the auto-type feature of Keepassxc. Yes, it's probably possible to
hack into the window title with Javascript, though I still consider it
kind of safer.

Now, if you want to go this way, we can go even further, and I can
miss-quote you to have fun:

"So, you use a browser and consider it secure?"

Because at the end, that's how far it goes... :)

> And if it doesn't happen to you, it happens to somebody else.

I very much advise everyone to use the same setup I have so that what
you describe cannot happen. But that's not the idea. The idea is that
everyone must be taken as accountable for keeping his/her password safe.
Someone not using a password manager should be using 2FA indeed, but
please don't *enforce* it. It makes me think about these stupid sites
that ask me to use upper case, special char, numbers, etc. when really,
I'm generating all of my passwords with OpenSSL. Don't try to know
better than I do please...

> Or you or
> somebody else has to use a more public or work computer for whatever reason.

I don't enter passwords on computers who aren't mine. Never. Ever...

Though that's not the point. You're applying the same pattern again:
you're giving example of idiots doing stupid things, and because of
these idiots, you want to enforce a security which doesn't help on every
case. Some people will always fall into traps, 2FA or not.

Did you ever realize that it's possible to defeat 2FA with phishing,
simply by asking the user to enter the 2FA code, and reuse that to
immediately login fraudulently?

> There are more ways to loose a password than you seem to be able to
> think of.

There are more idiots than you may think of (warning: entertaining!!!):
https://www.youtube.com/watch?v=opRMrEfAIiI
https://www.youtube.com/watch?v=UzvPP6_LRHc

:)

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

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.

Cheers,

Thomas Goirand (zigo)

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

[Russ Allbery]

Paride Legovini  writes:

> 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.

If we're concerned about CA attacks on debian.org servers, it's worth
noting that (a) most of us run Debian for obvious reasons, and (b) the
entire *point* of Debian is to safely and securely put configuration onto
all of our machines, which together mean that implementing certificate
pinning for our own infrastructure is entirely doable.

-- 
Russ Allbery (r...@debian.org)  

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

[Paride Legovini]

Thomas Goirand wrote on 26/04/2020:
> On 4/25/20 11:14 PM, Bernd Zeimetz wrote:
>> Actually I think 2FA should be enforced for everybody.
>> Even debian.org related passwords might get lost.
> 
> I use strong password, stored with keepassxc, with the password db
> encrypted using the HMAC of my yubikey. In what way is this not safe
> enough already? 2FA will add nothing in my case, just more annoyance.

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.

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.

Paride

[1] https://en.wikipedia.org/wiki/Certificate_authority#CA_compromise
[2] https://en.wikipedia.org/wiki/Kazakhstan_man-in-the-middle_attack,
mostly to say that state backed attacks to the CA trust model do exist.

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

[Sean Whitton]

Hello,

On Sun 26 Apr 2020 at 10:53PM +02, Vincent Bernat wrote:

>  ❦ 26 avril 2020 20:29 +00, Jeremy Stanley:
>
>> You're already seeing quite a few folks responding that being
>> required to use an additional application or device each time they
>> authenticate would be an inconvenience to them. This is a signal. I
>> personally wouldn't enjoy being prompted to activate my TOTP client
>> software every time I invoke `git push` so I can understand the
>> resistance to your proposal.
>
> This is not how this is implemented. I am using GitHub and GitLab with
> 2FA enabled and I am rarely asked to enter any token. Once you get
> authenticated on a device, it remains for a long time. The model threat
> is to prevent someone stealing your password through
> phishing/spying/guessing to login into your account. SSH keys being
> asymmetrical, they are not covered by this.

It is worth knowing that with GitLab 2FA you can request reset codes so
long as you have control over an SSH key registered to the account:


This limits the categories of attack that GitLab's 2FA can protect you
against -- e.g. laptop compromise.

-- 
Sean Whitton


signature.asc
Description: PGP signature

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

[Michael Biebl]

Am 26.04.2020 um 23:47 schrieb Paride Legovini:
> 
> Another good one with builtin backup functionality is Aegis [1,2]. It's
> GPLv3 and available via f-droid.
> 

Thanks, haven't heard of it before but looks interesting.

Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

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

[Russ Allbery]

Vincent Bernat  writes:

> This is not how this is implemented. I am using GitHub and GitLab with
> 2FA enabled and I am rarely asked to enter any token. Once you get
> authenticated on a device, it remains for a long time.

Pretty much every time I go to salsa.debian.org, I have to log back in
again.  The "long time" seems subjectively to be a week or two (or maybe a
month).  Am I doing something wrong?

What you say is true of GitHub for me.

-- 
Russ Allbery (r...@debian.org)  

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

[Russ Allbery]

Mattia Rizzolo  writes:

> Since I sometimes I don't really know my passwords, I suppose at that
> point the "something I know" instead of being the actual password is the
> GPG passphrase used to decrypt the file that actually contains the
> password, but it's still 2fa.

By equivalent logic, a GnuPG-encrypted password manager containing long,
randomly-generated passwords is also 2FA, without adding the TOTP element,
since you need both your passphrase to unlock it and a copy of the
password manager store.  (The reality is that counting factors has
limitations as a measure of security, and it breaks down here.)

The main benefit of adding a TOTP authentication element is that a
successful phishing attack without a local compromise of your laptop has
to use your credentials immediately and only gets to log in once, as
opposed to being able to store your credentials and use them at any time
in the future.  This is real benefit, although I'm not sure it's worth the
hassle for everyone.  The drawback of adding a second factor (account
lockout) is real and worth considering as well, although less of a worry
for Debian Developers and Maintainers with GnuPG keys in the keyring since
we can use GnuPG signatures as an account recovery mechanism.

If you want a good second factor, a physically separate Webauthn device is
superior to any OTP scheme (and also provides much stronger phishing
protection), but it does require buying and tracking a physical object,
and since that object can break or be lost, also storing backup codes
somewhere safe.

-- 
Russ Allbery (r...@debian.org)  

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

[Paride Legovini]

Michael Biebl wrote on 26/04/2020:
> Am 26.04.20 um 14:36 schrieb Mattia Rizzolo:
>> On Sun, Apr 26, 2020 at 02:07:54PM +0200, Bernd Zeimetz wrote:
>>> There are even cli tools that do the same stuff. I'd guess there is at 
>>> least one on Debian.
>>
>> Indeed, after I first lost a phone, and a second one broke, leaving me
>> with a quite huge pain to recover my accounts, I started using
> 
> On Android I switched from Google Authenticator to andOTP [1] because it
> has builtin backup functionality and being open source is a nice bonus.

Another good one with builtin backup functionality is Aegis [1,2]. It's
GPLv3 and available via f-droid.

[1] https://getaegis.app/
[2] https://github.com/beemdevelopment/Aegis

Paride

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

[Vincent Bernat]

 ❦ 26 avril 2020 20:29 +00, Jeremy Stanley:

> You're already seeing quite a few folks responding that being
> required to use an additional application or device each time they
> authenticate would be an inconvenience to them. This is a signal. I
> personally wouldn't enjoy being prompted to activate my TOTP client
> software every time I invoke `git push` so I can understand the
> resistance to your proposal.

This is not how this is implemented. I am using GitHub and GitLab with
2FA enabled and I am rarely asked to enter any token. Once you get
authenticated on a device, it remains for a long time. The model threat
is to prevent someone stealing your password through
phishing/spying/guessing to login into your account. SSH keys being
asymmetrical, they are not covered by this.
-- 
10.0 times 0.1 is hardly ever 1.0.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

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

[Jeremy Stanley]

On 2020-04-26 21:02:34 +0200 (+0200), Bernd Zeimetz wrote:
> On 4/26/20 8:30 PM, Bastian Blank wrote:
> > On Sat, Apr 25, 2020 at 11:14:39PM +0200, Bernd Zeimetz wrote:
> >> Actually I think 2FA should be enforced for everybody.
> > 
> > No, we don't enforce 2FA for everybody.  And I don't consider it
> > appropriate to raise the option.
> 
> Could you explain why?
> 
> There is nothing bad on an extra bit of security.

Actually, there is. "Security" is always a balance of inconvenience.
Add too many "extra bits of security" and your users will decide
that working around your security model is easier than adhering to
it, undermining the robustness of the system as a whole. The classic
(pre-password-manager) example was systems requiring complex
passwords leading to users writing them on slips of paper and
sticking them to the edges of their serial terminals.

You're already seeing quite a few folks responding that being
required to use an additional application or device each time they
authenticate would be an inconvenience to them. This is a signal. I
personally wouldn't enjoy being prompted to activate my TOTP client
software every time I invoke `git push` so I can understand the
resistance to your proposal.
-- 
Jeremy Stanley


signature.asc
Description: PGP signature

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

[Bernd Zeimetz]

On 4/26/20 8:46 PM, Johannes Schauer wrote:
> Quoting Bernd Zeimetz (2020-04-26 20:34:12)
>> On 4/26/20 12:41 AM, Thomas Goirand wrote:
>>> On 4/25/20 11:14 PM, Bernd Zeimetz wrote:
 Actually I think 2FA should be enforced for everybody.
 Even debian.org related passwords might get lost.
>>> I use strong password, stored with keepassxc, with the password db
>>> encrypted using the HMAC of my yubikey. In what way is this not safe enough
>>> already? 2FA will add nothing in my case, just more annoyance.
>> And then somebody sends you a phishing mail and you enter your password into
>> salsa.debiana.org...
> 
> This cannot happen with a password manager that keeps track of the domain for
> which it stores the passwords.

So you have a browser integrated password manager and consider it secure?
Interesting...


>> And if it doesn't happen to you, it happens to somebody else. Or you or
>> somebody else has to use a more public or work computer for whatever reason.
> 
> this means, that if 2FA would be made mandatory, people like me without a
> smartphone would not be able to use other computers than their private ones
> anymore.

As discussed before, you don't need a smartphone.


-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F

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

[Bernd Zeimetz]

On 4/26/20 8:30 PM, Bastian Blank wrote:
> On Sat, Apr 25, 2020 at 11:14:39PM +0200, Bernd Zeimetz wrote:
>> Actually I think 2FA should be enforced for everybody.
> 
> No, we don't enforce 2FA for everybody.  And I don't consider it
> appropriate to raise the option.

Could you explain why?

There is nothing bad on an extra bit of security.



-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F

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

[Bastian Blank]

On Sat, Apr 25, 2020 at 11:14:39PM +0200, Bernd Zeimetz wrote:
> Actually I think 2FA should be enforced for everybody.

No, we don't enforce 2FA for everybody.  And I don't consider it
appropriate to raise the option.

However, you may choose to enforce 2FA for all users of your groups.

Regards,
Bastian

-- 
It is necessary to have purpose.
-- Alice #1, "I, Mudd", stardate 4513.3

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

[Johannes Schauer]

Quoting Bernd Zeimetz (2020-04-26 20:34:12)
> On 4/26/20 12:41 AM, Thomas Goirand wrote:
> > On 4/25/20 11:14 PM, Bernd Zeimetz wrote:
> >> Actually I think 2FA should be enforced for everybody.
> >> Even debian.org related passwords might get lost.
> > I use strong password, stored with keepassxc, with the password db
> > encrypted using the HMAC of my yubikey. In what way is this not safe enough
> > already? 2FA will add nothing in my case, just more annoyance.
> And then somebody sends you a phishing mail and you enter your password into
> salsa.debiana.org...

This cannot happen with a password manager that keeps track of the domain for
which it stores the passwords.

> And if it doesn't happen to you, it happens to somebody else. Or you or
> somebody else has to use a more public or work computer for whatever reason.

this means, that if 2FA would be made mandatory, people like me without a
smartphone would not be able to use other computers than their private ones
anymore.

signature.asc
Description: signature

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

[Bernd Zeimetz]

On 4/26/20 12:31 AM, Gard Spreemann wrote:

> Right, but what's the threat model here? For some of us, losing the
> Salsa password is essentially only possible if we have had our PGP
> dongle or offline private key backup compromised. In this case, the
> attacker can sign uploads to the archive anyway, which is arguably more
> serious than a compromised Salsa account.

It might not be you, it might be somebody else. Not everybody is doing that.

Also: even you wouldn't be the first one to click on a fake link to
salsa.debiana.org or a similar site. Targeted attacks are nothing
uncommon and it is very likely that they succeed, at least with some of
the users.


-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F

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

[Bernd Zeimetz]

On 4/26/20 2:40 PM, Michael Biebl wrote:
> Am 26.04.20 um 14:36 schrieb Mattia Rizzolo:
>> On Sun, Apr 26, 2020 at 02:07:54PM +0200, Bernd Zeimetz wrote:
>>> There are even cli tools that do the same stuff. I'd guess there is at 
>>> least one on Debian.
>>
>> Indeed, after I first lost a phone, and a second one broke, leaving me
>> with a quite huge pain to recover my accounts, I started using
> 
> On Android I switched from Google Authenticator to andOTP [1] because it
> has builtin backup functionality and being open source is a nice bonus.

Nice, thanks, I was looking for a tool like that!



-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F

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

[Bernd Zeimetz]

On 4/26/20 12:41 AM, Thomas Goirand wrote:
> On 4/25/20 11:14 PM, Bernd Zeimetz wrote:
>> Actually I think 2FA should be enforced for everybody.
>> Even debian.org related passwords might get lost.
> 
> I use strong password, stored with keepassxc, with the password db
> encrypted using the HMAC of my yubikey. In what way is this not safe
> enough already? 2FA will add nothing in my case, just more annoyance.

And then somebody sends you a phishing mail and you enter your password
into salsa.debiana.org...

And if it doesn't happen to you, it happens to somebody else. Or you or
somebody else has to use a more public or work computer for whatever reason.

There are more ways to loose a password than you seem to be able to
think of.



Bernd


-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F

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

[Bernd Zeimetz]

On 4/26/20 7:12 PM, Sean Whitton wrote:

> In such a case, though, haven't you essentially turned it back into one
> factor authentication (the single factor being your laptop)?

Still better than losing a single password in whatever way in the
internet. Targeted phishing attacks for example.

-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F

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

[Xavier]

Le 26/04/2020 à 14:07, Bernd Zeimetz a écrit :
> Hi,
> 
> Google Authenticator is a software-based authenticator by Google that
> implements two-step verification services using the Time-based One-time
> Password Algorithm (TOTP; specified in RFC 6238) and HMAC-based One-time
> Password algorithm (HOTP; specified in RFC 4226), for authenticating
> users of software applications.

I used FreeOTP+ for years, like GoogleAuthenticator and free

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

[Mattia Rizzolo]

On Sun, Apr 26, 2020 at 10:12:41AM -0700, Sean Whitton wrote:
> On Sun 26 Apr 2020 at 02:36PM +02, Mattia Rizzolo wrote:
> > On Sun, Apr 26, 2020 at 02:07:54PM +0200, Bernd Zeimetz wrote:
> >> There are even cli tools that do the same stuff. I'd guess there is at 
> >> least one on Debian.
> > Indeed, after I first lost a phone, and a second one broke, leaving me
> > with a quite huge pain to recover my accounts, I started using
> > `oathtool` to manage the TOTP and HOTP codes, which is in Debian, and I
> > store the secret hash needed to generate the codes with `pass`.
> >
> > That said, for the only website where I need HOTP (Ubuntu SSO), I stored
> > that thing in the HOTP spot of my yubikey, and for everything else they
> > also support U2F so I likewise use my yubikey for those as well.
> 
> In such a case, though, haven't you essentially turned it back into one
> factor authentication (the single factor being your laptop)?

It's still two factor: something I know (password) and something I have
(my yubikey).

Since I sometimes I don't really know my passwords, I suppose at that
point the "something I know" instead of being the actual password is the
GPG passphrase used to decrypt the file that actually contains the
password, but it's still 2fa.
Still I wouldn't consider that to be tied to my laptop (the password
storage does live in my laptop, but it's encrypted AND duplicated
elsewhere).


-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

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

[Sean Whitton]

Hello,

On Sun 26 Apr 2020 at 02:36PM +02, Mattia Rizzolo wrote:

> On Sun, Apr 26, 2020 at 02:07:54PM +0200, Bernd Zeimetz wrote:
>> There are even cli tools that do the same stuff. I'd guess there is at least 
>> one on Debian.
>
> Indeed, after I first lost a phone, and a second one broke, leaving me
> with a quite huge pain to recover my accounts, I started using
> `oathtool` to manage the TOTP and HOTP codes, which is in Debian, and I
> store the secret hash needed to generate the codes with `pass`.
>
> That said, for the only website where I need HOTP (Ubuntu SSO), I stored
> that thing in the HOTP spot of my yubikey, and for everything else they
> also support U2F so I likewise use my yubikey for those as well.

In such a case, though, haven't you essentially turned it back into one
factor authentication (the single factor being your laptop)?

-- 
Sean Whitton


signature.asc
Description: PGP signature

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

[Phil Morrell]

On Sun, Apr 26, 2020 at 12:31:42AM +0200, Gard Spreemann wrote:
> 
> Bernd Zeimetz  writes:
> > Actually I think 2FA should be enforced for everybody.
> > Even debian.org related passwords might get lost.
> 
> Right, but what's the threat model here? For some of us, losing the
> Salsa password is essentially only possible if we have had our PGP
> dongle or offline private key backup compromised.

Actually, there's a good reason I enable two-factor everywhere despite
using a password manager. Password auth submits the same secret over the
network on every login, whereas TOTP is based on a pre shared key, so an
attacker needs to intercept that initial sharing or phish the OTP.

It's probably a minor concern and over the top, but with the ease of use
of pass-otp in debian or andOTP in f-droid, why not? I think I've talked
myself out of suggesting requiring 2FA on Salsa, but if it's possible to
have it by default (opt-out vs opt-in) then that'd be great.


signature.asc
Description: PGP signature

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

[Michael Biebl]

Am 26.04.20 um 14:36 schrieb Mattia Rizzolo:
> On Sun, Apr 26, 2020 at 02:07:54PM +0200, Bernd Zeimetz wrote:
>> There are even cli tools that do the same stuff. I'd guess there is at least 
>> one on Debian.
> 
> Indeed, after I first lost a phone, and a second one broke, leaving me
> with a quite huge pain to recover my accounts, I started using

On Android I switched from Google Authenticator to andOTP [1] because it
has builtin backup functionality and being open source is a nice bonus.

Michael


[1] https://github.com/andOTP/andOTP




signature.asc
Description: OpenPGP digital signature

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

[Vincent Bernat]

 ❦ 26 avril 2020 14:07 +02, Bernd Zeimetz:

> There are even cli tools that do the same stuff. I'd guess there is at
> least one on Debian.

There is oathtool.
-- 
I dote on his very absence.
-- William Shakespeare, "The Merchant of Venice"


signature.asc
Description: PGP signature

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

[Mattia Rizzolo]

On Sun, Apr 26, 2020 at 02:07:54PM +0200, Bernd Zeimetz wrote:
> There are even cli tools that do the same stuff. I'd guess there is at least 
> one on Debian.

Indeed, after I first lost a phone, and a second one broke, leaving me
with a quite huge pain to recover my accounts, I started using
`oathtool` to manage the TOTP and HOTP codes, which is in Debian, and I
store the secret hash needed to generate the codes with `pass`.

That said, for the only website where I need HOTP (Ubuntu SSO), I stored
that thing in the HOTP spot of my yubikey, and for everything else they
also support U2F so I likewise use my yubikey for those as well.

> No need for a mobile phone.

mobile phones are overrated :P

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

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

[Bernd Zeimetz]

Hi, 

Google Authenticator is a software-based authenticator by Google that 
implements two-step verification services using the Time-based One-time 
Password Algorithm (TOTP; specified in RFC 6238) and HMAC-based One-time 
Password algorithm (HOTP; specified in RFC 4226), for authenticating users of 
software applications.

There are even cli tools that do the same stuff. I'd guess there is at least 
one on Debian.

No need for a mobile phone. 


Bernd 

Am 26. April 2020 10:06:14 MESZ schrieb Johannes Schauer :
>Quoting Bernd Zeimetz (2020-04-25 23:14:39)
>> On 4/25/20 10:05 PM, IOhannes m zmölnig (Debian/GNU) wrote:
>> > On 4/25/20 8:34 PM, Bernd Zeimetz wrote:
>> >> https://docs.gitlab.com/ee/security/two_factor_authentication.html
>> >>
>> >> Enforce that (if Salsa is doing that in the meantime,  ignore me).
>> > i hope you don't suggest to enforce 2FA system-wide for all users
>of salsa.
>> > i read you original mail as a requirement to enforce 2FA for users
>who
>> > want to use salsa as an authentication provider for their own
>> > applications (which is fine with me)
>> Actually I think 2FA should be enforced for everybody.
>> Even debian.org related passwords might get lost.
>
>I never used 2FA before, so I want to your link and then, to learn more
>about
>it to this one:
>
>https://docs.gitlab.com/ee/user/profile/account/two_factor_authentication.html
>
>There I read that I have to install some application on my iOS, Android
>or
>SailFish OS device. I do not own any device with either of those
>operating
>system and neither does anybody else in my household. I guess I would
>need to
>use Qemu to run an emulated Android on my laptop instead. But if I do
>that --
>how would that improve security at all?
>
>Thanks!
>
>cheers, josch

-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

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

[Thomas Goirand]

On 4/25/20 11:14 PM, Bernd Zeimetz wrote:
> Actually I think 2FA should be enforced for everybody.
> Even debian.org related passwords might get lost.

I use strong password, stored with keepassxc, with the password db
encrypted using the HMAC of my yubikey. In what way is this not safe
enough already? 2FA will add nothing in my case, just more annoyance.

Cheers,

Thomas Goirand (zigo)

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

[Gard Spreemann]

Bernd Zeimetz  writes:

> On 4/25/20 10:05 PM, IOhannes m zmölnig (Debian/GNU) wrote:
>> On 4/25/20 8:34 PM, Bernd Zeimetz wrote:
>>> Hi, 
>>>
>>> https://docs.gitlab.com/ee/security/two_factor_authentication.html
>>>
>>> Enforce that (if Salsa is doing that in the meantime,  ignore me).
>> 
>> i hope you don't suggest to enforce 2FA system-wide for all users of salsa.
>> i read you original mail as a requirement to enforce 2FA for users who
>> want to use salsa as an authentication provider for their own
>> applications (which is fine with me)
>
>
> Actually I think 2FA should be enforced for everybody.
> Even debian.org related passwords might get lost.

Right, but what's the threat model here? For some of us, losing the
Salsa password is essentially only possible if we have had our PGP
dongle or offline private key backup compromised. In this case, the
attacker can sign uploads to the archive anyway, which is arguably more
serious than a compromised Salsa account.


 -- Gard
 

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

[Bernd Zeimetz]

On 4/25/20 10:05 PM, IOhannes m zmölnig (Debian/GNU) wrote:
> On 4/25/20 8:34 PM, Bernd Zeimetz wrote:
>> Hi, 
>>
>> https://docs.gitlab.com/ee/security/two_factor_authentication.html
>>
>> Enforce that (if Salsa is doing that in the meantime,  ignore me).
> 
> i hope you don't suggest to enforce 2FA system-wide for all users of salsa.
> i read you original mail as a requirement to enforce 2FA for users who
> want to use salsa as an authentication provider for their own
> applications (which is fine with me)


Actually I think 2FA should be enforced for everybody.
Even debian.org related passwords might get lost.

-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F

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

[Debian/GNU]

On 4/25/20 8:34 PM, Bernd Zeimetz wrote:
> Hi, 
> 
> https://docs.gitlab.com/ee/security/two_factor_authentication.html
> 
> Enforce that (if Salsa is doing that in the meantime,  ignore me).

i hope you don't suggest to enforce 2FA system-wide for all users of salsa.
i read you original mail as a requirement to enforce 2FA for users who
want to use salsa as an authentication provider for their own
applications (which is fine with me)

gfmadsr
IOhannes



signature.asc
Description: OpenPGP digital signature

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

[Bernd Zeimetz]

Hi, 

https://docs.gitlab.com/ee/security/two_factor_authentication.html

Enforce that (if Salsa is doing that in the meantime,  ignore me).

Bernd 

Am 25. April 2020 18:49:41 MESZ schrieb Bastian Blank :
>Hi Bernd
>
>On Fri, Apr 24, 2020 at 11:13:52PM +0200, Bernd Zeimetz wrote:
>> On 4/18/20 11:33 PM, Bastian Blank wrote:
>> > You are encouraged to use Salsa as an authentication provider for
>Debian
>> > services.  GitLab supports plain OAuth2 and OpenID Connect as
>> > authentiation protocols.  Every user can register their own
>applications
>> > and allow authentication through Salsa.
>> Could we require 2FA for this please?
>
>I'm not sure what you like us to do.  Please enlighten us.
>
>Regards,
>Bastian
>
>-- 
>Most legends have their basis in facts.
>   -- Kirk, "And The Children Shall Lead", stardate 5029.5

-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

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

[Bastian Blank]

Hi Bernd

On Fri, Apr 24, 2020 at 11:13:52PM +0200, Bernd Zeimetz wrote:
> On 4/18/20 11:33 PM, Bastian Blank wrote:
> > You are encouraged to use Salsa as an authentication provider for Debian
> > services.  GitLab supports plain OAuth2 and OpenID Connect as
> > authentiation protocols.  Every user can register their own applications
> > and allow authentication through Salsa.
> Could we require 2FA for this please?

I'm not sure what you like us to do.  Please enlighten us.

Regards,
Bastian

-- 
Most legends have their basis in facts.
-- Kirk, "And The Children Shall Lead", stardate 5029.5

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

[Bernd Zeimetz]

Hi Bastian,

thanks for your work!

On 4/18/20 11:33 PM, Bastian Blank wrote:
> You are encouraged to use Salsa as an authentication provider for Debian
> services.  GitLab supports plain OAuth2 and OpenID Connect as
> authentiation protocols.  Every user can register their own applications
> and allow authentication through Salsa.

Could we require 2FA for this please?


Thanks,

Bernd



-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F



signature.asc
Description: OpenPGP digital signature