Re: Gitlab update, 2FA now mandatory
On 2022.10.26 16:33, Tobias Leupold wrote:
Am Montag, 24. Oktober 2022, 01:16:30 CEST schrieb Jack:
> On 2022.10.23 02:32, Ben Cooksley wrote:
> > Hi all,
> >
> > This afternoon I updated invent.kde.org to the latest version of
> > Gitlab,
> > 15.5.
> > Release notes for this can be found at
> > https://about.gitlab.com/releases/2022/10/22/gitlab-15-5-released/
> >
> > There isn't much notable feature wise in this release, however
there
> > have
> > been some bug fixes surrounding the "Rebase without Pipeline"
> > functionality that was introduced in an earlier update.
> >
> > As part of securing Invent against recently detected suspicious
> > activity I
> > have also enabled Mandatory 2FA, which Gitlab will ask you to
> > configure
> > next time you access it. This can be done using either a Webauthn
> > token
> > (such as a Yubikey) or TOTP (using the app of choice on your
phone)
> >
> > Should you lose access to your 2FA device you can obtain a
recovery
> > token
> > to log back in via SSH, see
> >
https://docs.gitlab.com/ee/user/profile/account/two_factor_authentication.
> > html#generate-new-recovery-codes-using-ssh for more details on
this.
> >
> > Please let us know if there are any queries on the above.
> >
> > Thanks,
> > Ben
>
> Sorry to be dense, but without a webauthn token device, it seems
I'm at
> a total block if I don't have a phone (or don't have it with me.)
Is
> that correct, or is there some fine manual I need to read?
Just to take this up again, possibly for the more conservative folks
here:
I never had anything to do with Two-Factor-Authentication until now.
But
actually, it's not so complicated as it seems to be at first glance.
After having messed with it a bit, I found out that one doesn't have
to use a
phone to scan QR codes and such. The one-time-password used for
GitLab 2FA is
only derived from the "secret" (or "key", as GitLab calls it) and the
moment
in time where it should be used.
So you can e.g. store that key (it's displayed on GitLab below the QR
code, we
don't need the other stuff) in pass's db, e.g. in
var/invent.kde.org_2FA or
such.
With the help of a small shell script invoking pass and oathtool
(from oath-
toolkit), you can then retrieve the one-time-password by only using
the shell:
#!/bin/bash
secret=$(pass $1) # Get the key from pass's
db
secret=${secret// /}# Strip all spaces from it
valid=$((30 - 10#$(date +%S) % 30)) # Calculate the validity
otp=$(oathtool --base32 --totp $secret) # Generate the OTP
echo "$otp (valid ${valid}s)" # Print the result
Call it e.g. with the above var/invent.kde.org_2FA as the parameter,
and you
get (after having unlocked your PGP key of course) something like
111658 (valid 28s)
If the time the password will be valid is too short, you can simply
call it
again after some seconds (the PGP key stays unlocked for some time).
Of course, this has no error checking or such. But this could be
added quite
trivially. This way, we neither need some phone, nor some specialized
device
or app to deal with that OTP stuff, but only well-known console tools.
Maybe this helps somebody ;-)
Thanks. I might just try that.
I also found a KDE app called keysmith, but Gentoo doesn't package it,
so I don't quite know what to think of it. I've installed it, but not
yet tried to use it.
Jack
Cheers, Tobias
Re: Gitlab update, 2FA now mandatory
Am Montag, 24. Oktober 2022, 01:16:30 CEST schrieb Jack:
> On 2022.10.23 02:32, Ben Cooksley wrote:
> > Hi all,
> >
> > This afternoon I updated invent.kde.org to the latest version of
> > Gitlab,
> > 15.5.
> > Release notes for this can be found at
> > https://about.gitlab.com/releases/2022/10/22/gitlab-15-5-released/
> >
> > There isn't much notable feature wise in this release, however there
> > have
> > been some bug fixes surrounding the "Rebase without Pipeline"
> > functionality that was introduced in an earlier update.
> >
> > As part of securing Invent against recently detected suspicious
> > activity I
> > have also enabled Mandatory 2FA, which Gitlab will ask you to
> > configure
> > next time you access it. This can be done using either a Webauthn
> > token
> > (such as a Yubikey) or TOTP (using the app of choice on your phone)
> >
> > Should you lose access to your 2FA device you can obtain a recovery
> > token
> > to log back in via SSH, see
> > https://docs.gitlab.com/ee/user/profile/account/two_factor_authentication.
> > html#generate-new-recovery-codes-using-ssh for more details on this.
> >
> > Please let us know if there are any queries on the above.
> >
> > Thanks,
> > Ben
>
> Sorry to be dense, but without a webauthn token device, it seems I'm at
> a total block if I don't have a phone (or don't have it with me.) Is
> that correct, or is there some fine manual I need to read?
Just to take this up again, possibly for the more conservative folks here:
I never had anything to do with Two-Factor-Authentication until now. But
actually, it's not so complicated as it seems to be at first glance.
After having messed with it a bit, I found out that one doesn't have to use a
phone to scan QR codes and such. The one-time-password used for GitLab 2FA is
only derived from the "secret" (or "key", as GitLab calls it) and the moment
in time where it should be used.
So you can e.g. store that key (it's displayed on GitLab below the QR code, we
don't need the other stuff) in pass's db, e.g. in var/invent.kde.org_2FA or
such.
With the help of a small shell script invoking pass and oathtool (from oath-
toolkit), you can then retrieve the one-time-password by only using the shell:
#!/bin/bash
secret=$(pass $1) # Get the key from pass's db
secret=${secret// /}# Strip all spaces from it
valid=$((30 - 10#$(date +%S) % 30)) # Calculate the validity
otp=$(oathtool --base32 --totp $secret) # Generate the OTP
echo "$otp (valid ${valid}s)" # Print the result
Call it e.g. with the above var/invent.kde.org_2FA as the parameter, and you
get (after having unlocked your PGP key of course) something like
111658 (valid 28s)
If the time the password will be valid is too short, you can simply call it
again after some seconds (the PGP key stays unlocked for some time).
Of course, this has no error checking or such. But this could be added quite
trivially. This way, we neither need some phone, nor some specialized device
or app to deal with that OTP stuff, but only well-known console tools.
Maybe this helps somebody ;-)
Cheers, Tobias
> Thanks.
>
> Jack
Re: Gitlab update, 2FA now mandatory
On 25/10/22 15:06, Christoph Cullmann (cullmann.io) wrote: On 2022-10-25 14:55, Ahmad Samir wrote: On 25/10/22 14:31, Christoph Cullmann (cullmann.io) wrote: On 2022-10-25 13:52, Ahmad Samir wrote: On 25/10/22 13:29, Harald Sitter wrote: On Tue, Oct 25, 2022 at 1:22 PM Ahmad Samir wrote: Can a first time contributor create a fork, create multiple/100 MR's and spin up CI jobs? if yes, then, first time contributors can disrupt the system. Weren't there some suspicious accounts that were using our gitlab instance for bitcoin mining (I could be wrong, I vaguely remember someone from Sysadmin team talking about something like that)? were these first time contributors or ones with developer accounts? I'm sure 2fa doesn't help with that (: I am not a cyber security expert, but isn't 2FA comparable to captcha stuff? it's not hard, but it takes some extra time. Which forum would a spammer target? the one with the "create account and login immediately" or the one with "create account, verify captcha hell, verify email address"? That is true, but did we have concrete issues with spam accounts? And if yes, a one time captcha solving is a lot lower barrier the to need to do 2fa auth for a trivial issue Comment or merge request. At least for any part I work on in KDE the issue is manpower. Any step to make it more easier to help is good. Any step to make it harder is bad. I see the point why we not work on GitHub, I don't like to be dependent on some random company that in worst case can randomly pull the plug. But I somehow don't understand why we need to enforce this now even for new accounts without rights. I must confess I would like it even more if 2fa would only be required on doing some action that Is problematic and not just on any issue or merge request comment. But I assume that is not feasible. Greetings Christoph FWIW, when I log in to GitHub, they email me a pin number that I have to put in the web page, for me it's exactly the same level of inconvenience: - "check email, find pin, copy, paste" - "check app on phone, type pin" A mail is a lot easier on many devices, at least for me. My Kindle Fire can read my mails, but per default has zero otp stuff I could use. Same for my different work computers. All can get mail, none had before any such application. Therefore, yes, GitHub or the Steam Store work for me Without any extra setup effort. A mail address was Required anyways. And no, not even per default KDE Plasma ships with any obviously well integrated otp client. In this thread Ivan said Plasma Pass has OTP support: https://mail.kde.org/pipermail/kde-community/2022q4/007309.html (I haven't tried it myself). Regards, Ahmad Samir OpenPGP_signature Description: OpenPGP digital signature
Re: Gitlab update, 2FA now mandatory
On Wed, Oct 26, 2022 at 1:32 AM Christoph Cullmann (cullmann.io) < christ...@cullmann.io> wrote: > On 2022-10-25 13:52, Ahmad Samir wrote: > > On 25/10/22 13:29, Harald Sitter wrote: > >> On Tue, Oct 25, 2022 at 1:22 PM Ahmad Samir > >> wrote: > >>> > >>> Can a first time contributor create a fork, create multiple/100 MR's > >>> and spin up CI jobs? if yes, > >>> then, first time contributors can disrupt the system. > >>> > >>> Weren't there some suspicious accounts that were using our gitlab > >>> instance for bitcoin mining (I > >>> could be wrong, I vaguely remember someone from Sysadmin team talking > >>> about something like that)? > >>> were these first time contributors or ones with developer accounts? > >> > >> I'm sure 2fa doesn't help with that (: > > > > I am not a cyber security expert, but isn't 2FA comparable to captcha > > stuff? it's not hard, but it takes some extra time. Which forum would a > > spammer target? the one with the "create account and login immediately" > > or the one with "create account, verify captcha hell, verify email > > address"? > > That is true, but did we have concrete issues with spam accounts? > 2FA and CAPTCHA's try to solve two totally different problems. Please do not try to conflate them with each other. CAPTCHA's are designed to prevent bots (and more recently other suspicious actors) from taking specific actions, such as registering accounts. Often CAPTCHA's are intended to block spammers. 2FA is designed to verify that a user is who they say they are - through confirming they are in possession of something (whether that be a TOTP Secret, or a Webauthn hardware token). It is intended to defeat phishing, where legitimate and innocent user accounts are compromised and abused by bad actors. > > And if yes, a one time captcha solving is a lot lower barrier the to > need to do 2fa auth for a trivial issue > Comment or merge request. > > At least for any part I work on in KDE the issue is manpower. > > Any step to make it more easier to help is good. > Any step to make it harder is bad. > > I see the point why we not work on GitHub, > I don't like to be dependent on some random company > that in worst case can randomly pull the plug. > > But I somehow don't understand why we need to enforce > this now even for new accounts without rights. > > I must confess I would like it even more if 2fa > would only be required on doing some action that > Is problematic and not just on any issue or merge > request comment. But I assume that is not feasible. > You are correct. 2FA forms part of the process of authentication - that is confirming the user is who they say they are. It therefore can only be applied at the time of login. > > Greetings > Christoph > > -- > Ignorance is bliss... > https://cullmann.io | https://kate-editor.org Regards, Ben
Re: Gitlab update, 2FA now mandatory
On Wed, Oct 26, 2022 at 12:22 AM Ahmad Samir wrote: > On 25/10/22 12:11, Carl Schwan wrote: > > Le dimanche 23 octobre 2022 à 5:55 PM, Christoph Cullmann (cullmann.io) > a écrit : > > > > > >> On 2022-10-23 08:32, Ben Cooksley wrote: > >> > >>> Hi all, > >>> > >>> This afternoon I updated invent.kde.org [1] to the latest version of > >>> Gitlab, 15.5. > >>> Release notes for this can be found at > >>> https://about.gitlab.com/releases/2022/10/22/gitlab-15-5-released/ > >>> > >>> There isn't much notable feature wise in this release, however there > >>> have been some bug fixes surrounding the "Rebase without Pipeline" > >>> functionality that was introduced in an earlier update. > >>> > >>> As part of securing Invent against recently detected suspicious > >>> activity I have also enabled Mandatory 2FA, which Gitlab will ask you > >>> to configure next time you access it. This can be done using either a > >>> Webauthn token (such as a Yubikey) or TOTP (using the app of choice on > >>> your phone) > >>> > >>> Should you lose access to your 2FA device you can obtain a recovery > >>> token to log back in via SSH, see > >>> > https://docs.gitlab.com/ee/user/profile/account/two_factor_authentication.html#generate-new-recovery-codes-using-ssh > >>> for more details on this. > >>> > >>> Please let us know if there are any queries on the above. > >> > >> > >> Hi, > >> > >> whereas I can see the security benefit, this raises the hurdle for one > >> time > >> contributors again a lot. > >> > >> Before you already had to register to get your merge request, > >> now you need to setup this too (or at least soon it is mandatory). > >> > >> I am not sure this is such a good thing. > >> > >> I see a point that one wants to avoid that e.g. somebody steals my > >> account > >> that has enough rights to delete all branches in the Kate repository via > >> the > >> web frontend. > >> > >> Could the 2FA stuff perhaps be limited to people with developer role or > >> such? > > > > Yes this would be ideal. We don't need to require 2fa for people who just > > started contributing or want to give some feedback on a MR/ticket. > > > > This should be possible with the following features: > > > https://docs.gitlab.com/ee/security/two_factor_authentication.html#enforce-2fa-for-all-users-in-a-group > > > > We can just require 2fa for developers because with great powers come > great > > responsibilities. > > > > Cheers, > > Carl > > > > Can a first time contributor create a fork, create multiple/100 MR's and > spin up CI jobs? if yes, > then, first time contributors can disrupt the system. > They certainly can, although it hasn't been an abuse pattern we have had to deal with so far. > > Weren't there some suspicious accounts that were using our gitlab instance > for bitcoin mining (I > could be wrong, I vaguely remember someone from Sysadmin team talking > about something like that)? > were these first time contributors or ones with developer accounts? > Bitcoin mining no. Trying to use a Docker container on our CI nodes as their own personal server by utilising a reverse shell, then abusing that access to compile their own Android image, yes. All aided by GitHub distributing the Docker image on their container registry and ignoring our abuse reports. > > > -- > Ahmad Samir > Regards, Ben
