Live data from Hacker News

Gitlab Support is no longer processing MFA resets for free users

about.gitlab.com

151–160 of 228 posts

Re: Gitlab Support is no longer processing MFA resets for free users

#151
post #66
post #46

Earlier quoted context omitted.

I wish someone would convince Paypal. They require SMS for verification, no other options at all.

I think they offer TOTP now, right? Started sometime last year? Do you have to activate SMS alongside it? I have been using TOTP with PayPal for (I think) a few years now. You used to have to run some weird local Python script that somehow imitated the one RSA (I think) dongle they supported in a way I don't understand, but the net result was that you just get a TOTP key that works fine.

I wasn't able to see any way to do even TOTP for PayPal when they insisted I enable SMS a few hours ago.

I don't have any money in there, it just mediates broken payment interfaces (e.g. Patreon rejected all my payment cards, from multiple banks apparently they're all fraud or something? No idea, the cards remain working no problem everywhere else, but I wanted to give people money for what they do, so I used Paypal to manage that)

It's pretty sad that in 2020 PayPal thinks SMS is a reasonable choice for protecting accounts that might actually have money in them...

Re: Gitlab Support is no longer processing MFA resets for free users

#153
post #9

For comparison, here's GH Policy: https://docs.github.com/en/github/authenticating-to-github/r... > Warning: For security reasons, GitHub Support may not be able to restore access to accounts with two-factor authentication enabled if you lose your two-factor authentication credentials or lose access to your account recovery methods. I think it's hard to securely restore an account that is using MFA without being vuln…

Github does (for better or worse) support SMS for MFA though.

Re: Gitlab Support is no longer processing MFA resets for free users

#154

This seems to create an interesting security loophole. If someone figures out our GitLab password (i.e. by looking over our shoulder), they can just log in, enable MFA and we are locked out, forever. Think about this. Any criminal who gets access to your Gitlab account can make it impossible for you to access it ever again. If I used GitLab, I would seriously consider moving somewhere else.

Or you can just enable MFA yourself, and prevent that from happening? Am I missing something?

Re: Gitlab Support is no longer processing MFA resets for free users

#155
post #99
post #93

Question: How secure would it be to use a QR code as a password, and scan it with a phone camera?

It'd be about as secure as writing down a password or using a password manager. Note that it would be a password, not multi-factor authentication. These days, really, the important part isn't so much "something you know" vs. "something you have," it's the nature of how the credentials work. A password is sort of a one-way credential, something that serves by itself to authenticate you (or whoever is in possession of…

One thing you missed here:

In most of these designs the Relying Party (a web site in these cases) has to store secrets and we know bad guys steal secrets and the site won't always find about it immediately or sometimes at all.

For a password we somewhat mitigate this using password hashing. If the site uses a halfway decent password hash and you use a halfway decent truly random password then this is enough to protect both of you. But if you use a bad password or the site does a less than great job protecting it then game over.

For SMS the site stores your phone number (not terrible but not great for bad guys to learn) and maybe a temporary code (bad guys may be able to use this by learning it before you do but that's typically a small time window)

But for TOTP and similar "One time" codes the site stores the generator value. Bad guys who have this value can make any number of fresh codes at any time.

What jumps out here for WebAuthn is that the site stores nothing of value. A random-looking identifier that's useless for anyone other than the Relying Party, and a Public Key that's useless for anything at all other than confirming signatures made with the corresponding Private Key.

I've published the actual database contents for some of my own WebAuthn credentials on HN before, because they don't matter, unlike even an Argon2id password hash they are designed to be utterly useless to bad guys.

That's a huge benefit because there are fewer people trying to break in because what you have ain't worth stealing any more.

Re: Gitlab Support is no longer processing MFA resets for free users

#156

Good - 2FA is the responsibility of the user and resetting it kind of invalidates the security it helps bring. I think the bigger issue is that people's 2fa codes are still tied to their phone. You can lose your phone at any moment, which is why i've always disliked apps like Google Authenticator which don't let you export 2fa keys (for good reason). I personally use 1password, but there's definitely room for a cloud…

Google Authenticator now allows you to export your keys to another phone. I keep my keys in analog form - I print QR code for every service. We know how to handle valuables stored on paper.

I also do this, and I have a backup Yubikey in cold storage for all the services that supports it. Better be safe than sorry.

Re: Gitlab Support is no longer processing MFA resets for free users

#157

I don't care how high up you are on your infosec high horse, but the likelihood and potential damage caused by a developer losing access to their 2F device is far higher in nearly every scenario than someone being hacked. The only correct response to this is for companies to make it against internal policy for developers to enable 2FA. Which is sad.

It does look like they have a different, less “fatal” avenue to recover work related accounts[0], but I’d still be scared to host my FOSS repos there and make a mistake only to lose my account forever.

[0] “What if this is a work account?“ FAQ header in OP

Re: Gitlab Support is no longer processing MFA resets for free users

#158
post #146

Earlier quoted context omitted.

> Good - 2FA is the responsibility of the user and resetting it kind of invalidates the security it helps bring. Actually, no. This is a terrible idea. Think about the psychology of what you are telling people: "You have two choices - one is normal security, which you use on 80%+ of the rest of the internet, and one is 2fa which you only use on the annoying services that badger you into it. On the first one, if you l…

yes, i agree completely. but! how many keys to your car or to your home have you got? i'm willing to wager that you've got more than one. in the same way you never should have one key to your account, especially with hardware keys, but 2fa code apps should also apply.

If I lose all the keys to my car or they are destroyed, I can pay a dealership to create new ones for me, I don't just have to forfeit the car.

Re: Gitlab Support is no longer processing MFA resets for free users

#159
post #131

Earlier quoted context omitted.

Google Authenticator now allows you to export your keys to another phone. I keep my keys in analog form - I print QR code for every service. We know how to handle valuables stored on paper.

Is this specific to the Android version? The iOS version has not been updated since 2018.

Android version also didn't see any updates until May this year, when this feature arrived.

Re: Gitlab Support is no longer processing MFA resets for free users

#160

Earlier quoted context omitted.

> Good - 2FA is the responsibility of the user and resetting it kind of invalidates the security it helps bring. Actually, no. This is a terrible idea. Think about the psychology of what you are telling people: "You have two choices - one is normal security, which you use on 80%+ of the rest of the internet, and one is 2fa which you only use on the annoying services that badger you into it. On the first one, if you l…

The correct fix is to make the better option less annoying. You can do this today with WebAuthn. Here's the steps to sign in to a WebAuthn-enabled site with say a Pixel 2: 1. Go to the site 2. Touch the "Sign in" button 3. When prompted touch the fingerprint sensor That's it. Did a bunch of complicated stuff happen? Yes, but the user didn't do any of that, so they needn't care.

...Neither my work nor personal laptops have a fingerprint sensor.
Post reply on HN