One-time codes rejected by GitLab

cfr · 2024-06-04 05:16:05

I have an account on GitLab which I have successfully accessed using 2 FA before. My user name and password are accepted, but no matter how many times I enter a fresh OTP token or restart the login process, my tokens are always rejected as invalid.

I know this is not a forum for technical questions, but it seemed the least inappropriate. I couldn't find anything on the pages about Arch in the wiki. I realise I could email accounts for support, but I'd like to try to figure out if I'm doing something obviously wrong first, as I'm not 100% comfortable with 2FA.

I used Aegis to generate the tokens, which is the authenticator I set up for Arch's GitLab. I did that because that was on the recommended list. For the other sites I need OTPs for, I'm using MS's Authenticator app because I need to authenticate with Microsoft 365 etc. for work.

Aegis generates the tokens fine. They just aren't accepted and I have no idea why. I don't, however, get any notification to my phone giving me a code provided by the site. I am assuming GitLab does it the other way i.e. it takes a token generated on the second device rather than sending one to that device.

Does anybody have any advice or instructions for this? Although I'm not really comfortably with 2FA, I do generally get it to work, but I'm not sure what else to try in this case.

[Perhaps I should not say this, but the login pages are not the most informative or helpful.]

lahwaacz · 2024-06-04 05:22:57

Which web browser are you using? Can you try it from a different one?

seth · 2024-06-04 07:27:53

I use this here

#!/bin/bash
totp_key="$(grep -im1 "$@" ~/.toptp || exit 1)"
context="${totp_key#*otpauth://}"; context="${context%%\?*}"; context="${context//%/\\x}"
context="$(printf '%b' $context)"
totp_key="${totp_key#*secret=}"; totp_key="${totp_key%%&*}"; 
totp_key="$(oathtool --base32 --totp "$totp_key")"

printf "$totp_key" | xsel -ib
dunstify -u low "$totp_key" "$context"

and ~/.toptp lists the otpauth:// url you got as qrcode so I can "totp arch" and then paste the URL.
The entire thing is of course (next to being security by simulation and makebelieve that gives me headaches everytime I think about it after reading up the TOTP spec and background*-) system time dependent ===> maybe a DST problem on the generating device?

Fcs, relevant section of my local qr decoder

#!/bin/bash
ogg123 $HOME/.local/share/sounds/myscheme/camera_focus.ogg &
rm '/tmp/.qrdecode.png'
scrot --line style=dash,width=1,color='#1793d0' -s -q85 '/tmp/.qrdecode.png'
ogg123 -q $HOME/.local/share/sounds/myscheme/camera.ogg &
qr_content="$(zbarimg --raw -q /tmp/.qrdecode.png)"
echo "$qr_content" | xsel -ib
if [[ "$qr_content" = 'otpauth://'* ]]; then
    echo "$qr_content" >> ~/.toptp
    totp_key="${qr_content#*secret=}"; totp_key="${totp_key%%&*}"; 
    totp_key="$(oathtool --base32 --totp "$totp_key")"
    echo "$totp_key" | xsel -ib
    qr_content="${qr_content#*otpauth://}"; qr_content="${qr_content%%\?*}"; qr_content="${qr_content//%/\\x}"
    qr_content="$(printf '%b' $qr_content)\n----------\n$totp_key"
fi
dunstify -I /tmp/.qrdecode.png -u low -a qrdecode "QR decoded" "$qr_content"

* for context, this isn't really a "second factor" or "something you have" or let alone your phone - you're simply getting a second password that has decent entropy but gets generated by the other side and is stored symmetrically because it's not like D&H had figured out how to do this right 50 years ago and you're completely giving up on the single benefit of "I can store a password in my brain" and so we could have had an asymetrically encrypted one-time-pin that's not complete fake just as much … and I'm ranting again

Arch Linux

#1 2024-06-04 05:16:05

One-time codes rejected by GitLab

#2 2024-06-04 05:22:57

Re: One-time codes rejected by GitLab

#3 2024-06-04 07:27:53

Re: One-time codes rejected by GitLab

Board footer