
Gitlab Support is no longer processing MFA resets for free users - WalterSobchak
https://about.gitlab.com/blog/2020/08/04/gitlab-support-no-longer-processing-mfa-resets-for-free-users/
======
nooyurrsdey
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 storage
solution that safely holds 2fa credentials

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

~~~
gknoy
Would you be willing to describe the process you use to do this?

~~~
cuu508
Not op, but my usual process is:

* when setting up 2FA, a website shows a QR code

* I screenshot the QR code, and print it out on an A4 sheet, with an annotation of what service it is for

* I scan the QR code from the A4 sheet on two different phones.

* Back on the website, I continue 2FA setup process only after the A4 sheet is printed, and both phones show the same codes

* The A4 sheet goes in a folder for safe keeping

* One phone goes in my desk drawer for daily use

* The other phone goes in my "go" bag that I take with me on short trips etc.

Both phones are used exclusively for Google Authenticator:

* they have no extra apps

* they have a screen lock

* they are always in flight mode

Started doing this when I got burned by having to extract GA's sqlite file
from mostly-dead Nexus One over adb.

~~~
Chris2048
interesting idea. I wonder what the minimum you need for a 2FA-only device
would be.

~~~
thinkmassive
The Passport by Foundation Devices is a device that's pretty close to this, it
just happens to do more than only 2FA:
[https://foundationdevices.com/](https://foundationdevices.com/)

------
cmeacham98
Is it just me, or does this make my MFA-protected account safer?

I wish conpanies offered this as a feature, in the sense I'm much more worried
about someone SEing their way into my account rather than me losing access to
all my MFA methods and backup codes or whatever.

~~~
tgsovlerkhgsel
It makes your MFA-protected account safer from takeover, but also creates a
new risk of completely losing access to your account _and username_ forever.

Github has the same policy, and it deterred me from using MFA for a long time,
and when I finally did, I added a large number of alternatives, including the
not-so-secure SMS.

I think the fear of being _temporarily_ unable to access your account is
already a major reason why people don't use MFA. Turning the threat into a
_permanent_ loss will make people even more reluctant to do it.

Dealing with some of the backup methods (e.g. off-site copies of backup codes)
is tedious, and I wouldn't be willing to do it for less important sites. If I
had 2FA on Gitlab, I'd probably turn it off now. (Actually, just saw they
don't have an option to add a phone number - I'd definitely turn it off.)

~~~
Jedd
> ... but also creates a new risk of completely losing access to your account
> and username forever.

I may have misread the announcement, but it sounds like upgrading to a paid
account recovers (npi) the ability to recover your account.

~~~
noisem4ker
How does one upgrade their account if they cannot access it at all?

~~~
Jedd
I suspect if one can a) exhibit genuine interest in becoming a customer waving
their credit card around, and b) demonstrate ownership of 1FA for the account,
then this would be relatively straightforward.

Or rather, at least as straightforward as the process is meant to be for
existing paid-up customers, as per TFA.

------
Androider
Although framed as a security improvement, I'm sure it's also a massive
support burden. When you have hundreds of thousands or millions of users, at
some point you probably have support staff who do nothing but helping users
reset their MFAs all day every day. It seems fair not to do this for free
users. Some services gate MFA to paid accounts which seems like a worse trade-
off.

With free users you also have less information available to you as a provider
in determining if the reset request is legit or not.

~~~
Already__Taken
I'm sure it'd be abused but it'd be cool if I could put a support payment in
escrow should I need to escalate an issue for special attention.

------
EdJiang
For comparison, here's GH Policy:

[https://docs.github.com/en/github/authenticating-to-
github/r...](https://docs.github.com/en/github/authenticating-to-
github/recovering-your-account-if-you-lose-your-2fa-credentials)

> 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 vulnerable to social engineering, SMS takeover, etc. If it's on a
corporate account it's easy -- just talk to IT. But for semi-anonymous free
accounts? I'm not sure what the expectation here is. What are some good
strategies you've seen other providers take?

~~~
cjbprime
Make the reset take three days, during which time emails and SMS are sent to
the addresses on file alerting them that they may be being attacked and should
cancel the recovery if so.

~~~
tialaramex
Though note this will still work for a _targeted_ attack. You wait until your
target will be out of the loop and then begin your attack run. But it would
definitely help.

~~~
cjbprime
I'm not sure there are many attractive targets left who are uncontactable by
email and SMS for three continuous days.

~~~
mcherm
Does no one else take real vacations these days?

~~~
belltaco
Even on vacations people do connect atleast once a day. Even if to just check
on possible family emergencies.

~~~
usr1106
That depends on the country. In Europe 4 weeks of summer holidays are common,
in some countries even the law. An increasing number of people logs in to work
accounts during holidays, but generally it's considered poor work-life
balance. I don't take pressure either way, I might or might not log in once or
twice during my 3 weeks (twice a year) if I am curious about something. My
private mail I scan occasionally, but it has happened many times that I
haven't done so for 2 weeks. There is enough stress in my life, I don't need
to be connected every day of the year. There is a phone for personal
emergencies. And if someone is afraid someone is dying before they get there
they probably can never move out of their parents' home.

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

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

~~~
littldevl
In your world no one ever makes mistakes or errors, it must be nice.

~~~
SifJar
Not sure how you get that conclusion from my comment, of course people make
mistakes - my suggestion is one way to prevent such a mistake? i.e. if you
have MFA enabled, it "doesn't matter" as much if you _do_ make a mistake and
accidentally reveal your password to someone

------
K0nserv
There was a discussion about the topic of MFA resets on the Risky Business
podcast[0] in which the host, Patrick Gray, suggested companies require a one
time fee for MFA resets. I think the suggested amount in the show was $50
which seems reasonable enough for western markets. It creates a deterrent for
attackers and in the case of free products like GitLab allows the support
costs to be covered. Additionally the act of payment itself can help prove
identity.

0: [https://risky.biz/soapbox43/](https://risky.biz/soapbox43/)

~~~
Dayshine
So, not only are developers working on open source projects in their free time
expected to maintain and provide support for free, they're now also expected
to pay in order to provide baseline security for their users?

If NPM or any other package repository introduced this, do you think
maintainers of commonly used open source projects wouldn't feel obliged to pay
up? Generally immediately after a traumatic event such as having their phone
stolen.

Even if you never plan to update your package, you can't fix a security
vulnerability without spending money.

~~~
amazingman
Don’t lose your recovery codes and you should be fine, right?

~~~
Dayshine
Yeah, sure, set up a recovery process I don't need anywhere else in life and
hope I never mess that up. Then have several thousand people (or far more if
I'm lucky) rely on it, I'm sure that'll go well!

I don't need recovery codes for anything in my professional nor personal life
outside open source programming.

~~~
amazingman
You don’t have any other MFAs you need to manage in your digital life? That
seems ... odd. It seems like you’re deciding to make an issue of, well, how
MFA is _supposed_ to work.

~~~
Dayshine
I have other MFAs, but they all have real-world recovery routes.

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

~~~
graton
Gitlab allows you to have multiple U2F tokens. From what I can tell it is is
at least 10. I myself probably own eight U2F tokens. Anyone of the U2F tokens
I have registered can be used to log me into Gitlab, assuming I remember my
username/password ;)

Besides the somewhat minimal cost of $20 for a U2F token I don't see any
reason people should not have multiple U2F tokens and register them to their
accounts.

~~~
sixhobbits
this is pretty much the high horse I was talking about. If you think a
majority of people do this, or are likely to do this given the right process,
you're living in a very small bubble.

~~~
graton
> you're living in a very small bubble.

Why did you try to make this personal by attempting to insult me?

------
belltaco
This looks like a page that people would find _after_ they lose access to
their account permanently. There's a lot of CYA language here. Maybe they
should have this at signup for MFA or force people to read next time they
login.

~~~
lkozloff
Support Manager for GitLab here.

I appreciate this feedback, and you're right. We don't want folks to get
themselves in a position where they lose access.

Our current language when you enable MFA is here: [https://gitlab.com/gitlab-
org/gitlab/-/blob/adc7dbeb387adc69...](https://gitlab.com/gitlab-
org/gitlab/-/blob/adc7dbeb387adc690cbe1fff650846bc48970348/app/views/profiles/two_factor_auths/_codes.html.haml#L2)

> Should you ever lose your phone or access to your one time password secret,
> each of these recovery codes can be used one time each to regain access to
> your account. Please save them in a safe place, or you __will __lose access
> to your account.

We're directly emailing our most at risk users and are still processing resets
in the mean time. Additionally, many users will see a CTA banner reminding
them to regenerate their recovery codes if they haven't recently.

If there's anything else we can do - I'm happy to hear it! I've had to rely on
recovery services in the past because of pure bad luck and a move to a new
country, so we didn't take this decision lightly.

~~~
Dayshine
I made this post on the forums: [https://forum.gitlab.com/t/gitlab-support-is-
no-longer-proce...](https://forum.gitlab.com/t/gitlab-support-is-no-longer-
processing-mfa-resets-for-free-users/40905/15?u=tboby)

In summary:

Please consider some kind of exemption for non-commercial open source projects
over a certain size.

This change would force me to choose between unacceptable risk to my users, or
severe impact on my hobby/life balance and mental health due to the extreme
personal responsibility I would have to take to mitigate it.

It's already terrifying enough to publish applications that users run on their
systems. If I make an error I can cause all sorts of harm. But at least I only
have to worry about that when developing.

Now, if I enable MFA, I can never relax. If I lose my work MFA, there's a
perfectly safe process to recover. If i lose my personal MFA it's a few hours
of calling banks. If I lose my GitLab MFA I harm hundreds of people. So, I
have to permanently vigilant for something I already give so much to for free.

~~~
samanthalee233
Thanks for your feedback, I'm a community advocate at GitLab and just wanted
to point out that our team has responded to your forum post here:
[https://forum.gitlab.com/t/gitlab-support-is-no-longer-
proce...](https://forum.gitlab.com/t/gitlab-support-is-no-longer-processing-
mfa-resets-for-free-users/40905/17?u=)

------
StavrosK
I generally support not resetting MFA credentials, and understand where Gitlab
is coming from, but wish there were an easier way for the average user. I
think that easier way is getting two FIDO2 keys (they're pretty cheap and will
get cheaper), and have one on your keychain and one at home, as a backup.

~~~
nicoburns
For a casual user (unlikely to be specifically targetted for attack) I think
SMS is a good option. If you lose your phone then you can just order a
replacement sim card and you have your second facto back.

~~~
fiblye
As someone who travels frequently and has moved to different countries, SMS is
the absolute worst.

If a service asks me to verify my number after crossing a border, the chances
of me ever being able to log into that account ever again are basically zero.

Then there's Google. Google doesn't have a phone number on file for me, but
they sometimes demand that I input a phone number and enter a verification
code to access my accounts. This has led to me needing to ask a total stranger
to help me login to my accounts, potentially allowing them full access to all
of my data in the name of "security." But hey, nobody ever said Google hires
smart people.

~~~
epanchin
This is a very niche case. Why can't you recieve sms abroad? Do you leave your
phone behind when you travel? Why can't you give Google your current phone
number?

~~~
lbotos
Not OP but I face this problem:

\- Why can't you recieve sms abroad?

Because I use e-sims and pay $10 for 30 days of data only vs. the $30 my
provider would add to my bill for "global data".

> Do you leave your phone behind when you travel?

No, but I do leave my US number "dormant" in that i can't use it.

> Why can't you give Google your current phone number?

Because they already have a clear enough data picture of who i am, and I don't
want them to have any more data that I'm willingly giving them.

~~~
StavrosK
Can you give some more info on eSIMs, where you get them from, how much data
they have, etc?

------
whatl3y
> If you are caught where you are not able to provide your MFA token and
> without these backup methods, your account will be irrecoverable.

This seems absurd. I vaguely remember another SaaS tool I used that had this
policy, but I don’t understand it. Even crypto exchanges allow recovery if you
lose all traditional recovery methods by submitting documentation like your
scanned driver’s license among a couple other pieces of info proving you are
who you are.

If you offer MFA, I love the idea of following best security practices for
users recovering their accounts when losing MFA devices/tokens/etc., but there
has to be a “best practice” that includes recovering an account after a due
diligence process has been followed proving who a user is who she says if she
lost all normal recovery methods.

Edit: It does look like they have a different, less “fatal” avenue to recover
work related accounts (“What if this is a work account?“ FAQ), but I’d still
be scared to host my FOSS repos there and make a mistake only to lose my
account forever.

~~~
lkozloff
Support Manager at GitLab here.

We did use to do identity card verification. The issue that we had was that we
often didn't have a lot of information about the folks who opened free
accounts.

Often names would be pseudonyms or match only partially with their ID. Not to
mention, of course, the difficulty of verifying the authenticity of IDs from
all over the world.

We wrote about this back in 2018:
[https://about.gitlab.com/blog/2018/10/08/enforcing-
managing-...](https://about.gitlab.com/blog/2018/10/08/enforcing-managing-2fa-
support-security/)

~~~
tgsovlerkhgsel
I suspect that support cost also played into the decision.

Consider requiring payment: It covers your support costs, and provides _some_
ties to a real-world identity as well as rate limiting/imposing a real cost on
attackers.

For credit cards, AFAIK you can set which security level to apply (i.e.
whether you'd rather have a higher fraud risk or more shopping cart
abandonement because the customer didn't have/want to deal with whatever auth
the bank requires at the highest security level). I imagine cranking this to
the max would reduce the risk of stolen cards significantly.

I'd imagine requiring

\- identity verification (even if you can't link it to the account, it will
deter attackers) through a third party provider \- payment (both to cover the
cost and as a second form of verification/audit trail generation) \-
inactivity of the account \- contacting and warning the user for a week \-
requiring the user to confirm a confirmation link at the beginning and end
(i.e. an attacker would need control of the user's e-mail)

would strike a good balance. If you don't want human judgement in the loop on
your side, it can also be completely automated if the ID check is done by a
third party.

If there is no way to recover, it creates a perverse incentive to not use 2FA
in the first place.

~~~
whatl3y
> I suspect that support cost also played into the decision.

I respect this if it’s the case, but just say it, don’t hide behind a “best
practice” security blanket when your true motive includes other factors.

> If there is no way to recover, it creates a perverse incentive to not use
> 2FA in the first place.

Agree. The user has to now perform a cost benefit analysis in her head to
determine if she’ll use MFA with the most punitive risk being she loses access
to her account forever.

------
quadrangle
Instead of just saying they won't do it for free accounts, they could charge a
fee for the service.

~~~
JadeNB
Good God, imagine the bad publicity that comes out of that. "This is
advertised as a security measure, but it's clear it's just a way to extort the
user at his most vulnerable!"

~~~
quadrangle
I don't know. Free service that _isn 't_ even paid for with ads or privacy-
invasion, like legitimately free. If something happens on _your_ end, you can
pay them for service. What's wrong?

Which is worse publicity:

A) if you use this security feature, and something goes wrong on your side,
you will lose your account forever

B) if you use this security feature, and something goes wrong on your side,
helping you get your account back will require a lot of work and due-diligence
which we can't afford to do for free

It's not _SO_ different from:

A) if your device fails outside the warranty, it cannot be repaired

vs B) if your device fails outside the warranty, it will be expensive to
repair

~~~
JadeNB
> Which is worse publicity:

I think it's not so clear. If someone tells me "I can't authenticate, and so
I'm locked out of my account", that sounds like his fault. If someone tells me
"I can't authenticate, and they'll let me into my account, but only if I pay
them money", then that sounds like their fault. I do carefully say _sounds_ —I
recognise the underlying tech is the same in both cases; but the nature of
publicity is to attach much more about appearance than to technical facts.

------
frio
> I don’t like this and I want to tell someone.

I'm sure this is meant to come across as maybe slightly tongue-in-cheek, and
is also meant to provide users an outlet they feel they can vent in
productively, but... it reads as dismissive, and leaves me with the impression
that they don't actually care to hear any feedback.

~~~
lkozloff
Support Manager (and person who wrote that line) - it's certainly not meant to
be dismissive or tongue in cheek. If you've got some suggested wording to help
take away that feeling, I'm happy to submit (or merge) and MR to the blog post
to make it feel less that way.

We actually do want (and care) about your feedback and wanted to provide a
clear way to give that. In the past we've gotten support requests, tweets,
comments on GitLab issues and a myriad of other creative ways of voicing
thoughts, opinions and ideas.

My hope was to streamline feedback into a single place that GitLab support and
our community teams are actively monitoring. There's been some helpful
discussion there (and here) already.

~~~
frio
Sorry, wrote that and then went offline for a couple of days. Perhaps it's my
own cynicism about corporate engagement coming through, and that may be unfair
given how open GitLab is as a company -- but the sentence beneath that heading
just says "we're accepting community feedback, write your thoughts over here".

I guess the core of my (admittedly petty) complaint about the language is that
it doesn't really indicate a willingness to listen, more than it steers people
towards a box in the corner they can vent into. A bit of language along the
lines of "we think this is the right decision, but we're willing to
reconsider" would maybe come off as more considerate, I guess?

------
smallsaas
Seems like a good way to discourage the use of mfa...

~~~
nawgz
Seems to me like it actually makes not having MFA even riskier, as if you fail
to have it, someone pwns you, and then adds MFA to your account, it's
literally a dead end to you.

------
Ajedi32
Isn't this why almost every site with 2FA support asks you to print out backup
codes and keep them somewhere safe, and warns you that you won't be able to
recover your account if you lose them? I thought this was standard practice.
I'm surprised it seems to be so controversial.

~~~
andrewaylett
That does somewhat presuppose access to a printer.

~~~
Ajedi32
Slightly less convenient, but if you don't have access to a printer you could
always just write the codes down.

------
mschuster91
Why not introduce a model where one who has lost their MFA keys pays something
like, say, 50 $ to make up for the time the support team spends on the ticket?

Such a decision is something that would make me either leave the service, not
trust it with anything important or not enable MFA.

(Side note, this is also valid for Google, Twitter, Facebook, AWS and other
services that take pride in letting AI manage everything with no avenue of
contacting a human with authority to override the AI)

------
jeppesen-io
As someone who had two phones break and loose my 2FA for github, this makes me
sad

They were willing to help me - took a week but I got my account back

~~~
climb_stealth
Not sure about gitlab, but at least on github you get recovery codes that you
can use if you don't have access to your phone.

~~~
samanthalee233
GitLab does have this, here is a link to our docs with more info:
[https://docs.gitlab.com/ee/user/profile/account/two_factor_a...](https://docs.gitlab.com/ee/user/profile/account/two_factor_authentication.html#recovery-
codes) and how you can regenerate them if you lose them:
[https://docs.gitlab.com/ee/user/profile/account/two_factor_a...](https://docs.gitlab.com/ee/user/profile/account/two_factor_authentication.html#generate-
new-recovery-codes-using-ssh)

------
lacker
This makes sense. If it bugs you, just upgrade to a paid account. Being able
to manually verify your identity in case of emergency is a real service and
worth paying money for.

------
totetsu
What are the current best options for hardware tokens then?

~~~
tialaramex
If you mostly use a desktop or laptop, purchase two different FIDO
authenticators that match the form factor you need.

If purchasing a new laptop (or having one purchased for you) and you run
Windows or Mac OS consider fingerprint devices that can turn it into a
"Platform Authenticator" able to prove that the person with the authorised
fingerprint and the machine authorised are together and wish to sign in.

If you mostly use a phone, look for a newer iPhone or for select Androids
(e.g. Google's "Pixel" series) with fingerprint readers, again these function
as a platform authenticator.

 _Unfortunately_ for the latter case U2F isn't an option. Sites should be
migrating to WebAuthn (and please people do not _implement_ U2F instead of
WebAuthn in 2020, for the same reason you wouldn't build a new Flash video
site, nothing new supports that technology any more, stop it)

Today GitLab is U2F only, there is a logical upgrade path to WebAuthn, and
they seem to be working through a bunch of patches to land it, but for now
it's less compatible with a site with WebAuthn (e.g. GitHub). So that means if
you use the site largely or exclusively from a phone hardware tokens do not
buy you much yet.

~~~
papaf
_Sites should be migrating to WebAuthn (and please people do not implement U2F
instead of WebAuthn in 2020, for the same reason you wouldn 't build a new
Flash video site, nothing new supports that technology any more, stop it)_

I think this is terrible advice because WebAuthn isn't supported by Linux
browsers and I still want to be able to login to services on the internet.

~~~
tialaramex
Which "Linux browsers" are you thinking of?

Firefox only implements WebAuthn, including on Linux, the U2F support in
Firefox is essentially a "reverse polyfill" in which the browser pretends it
can do U2F but actually is just wiring some commonly used parts of U2F to the
WebAuthn implementation to tide you over until your site gets WebAuthn.

Chrome on Linux certainly supports WebAuthn although it does have U2F support.

I'm sure Lynx can't do WebAuthn, but I'm also 100% sure I don't care.

~~~
papaf
This site does not work for me with Firefox 79.0 on Linux with a Yubikey 5:

[https://demo.yubico.com/webauthn](https://demo.yubico.com/webauthn)

Is this a problem with the backend rather the browser?

Edit: This site works [https://webauthn.io/](https://webauthn.io/) My mistake!

~~~
tialaramex
The anti-fingerprinting in Firefox will flag that first site you linked.

The site is asking your FIDO Authenticator to provide "attestation". In theory
this _could_ be useful to require users to pick a high quality authenticator.
It might make sense, for example for Big Bank to require customers use an
authenticator Big Bank bought in bulk with Big Bank branding, because they
trust it.

But, although countermeasures against tracking were incorporated in the FIDO
design for attestation, it is unavoidably a potential privacy risk and so
Firefox decided to flag it. Sites which try to ask for attestation during
registration get a "Fingerprint" icon in newer Firefox versions. Click the
fingerprint and opt either to press on anyway or to Anonymise the
authentication (essentially pretend your device hasn't got any attestation) on
this site.

For a site owner: Do _not_ do attestation just because it seems cool and
worked in Edge or whatever. If you don't _need_ this sensitive information do
not request it. You need to work out a policy, which authenticators are OK and
which aren't - if that seems like too much then _don 't do attestation_. If
the answer is "actually any authenticator seems good" then _don 't do
attestation_. If you allow users to just not have an authenticator (100% of
general purpose web sites today) then _don 't do attestation_ for those who
want one. If you are throwing the data away because you have no idea how to
process it _don 't do attestation_.

------
exabrial
This is the right move. Get two u2f keys. Keep one on your person on your
keys, keep the other in your car, at your parent's, or in a safe deposit box
depending on your personal threat surface.

------
geofft
Side note - the SSH-based recovery mechanism is great and delightful. I
happened to need a reset for salsa.debian.org and it saved me from bugging
Debian's GitLab folks for support.

------
u801e
I wonder if services like Git..b would ever enable MFA based on ssh. That is,
configure their endpoint to require both the key and the password to log in,
push or fetch.

------
momokoko
I think this is interesting in that the correct response as a user is to
literally maintain a backup mirror gitlab account in case you lose access to
your original one. What a bizarre change from a SaaS company who’s value
proposition is to make things easier than doing them yourself.

------
jokoon
Question:

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

~~~
geofft
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 it). Anyone who holds the
password can authenticate until it's changed. You should pick a long password,
something that it hard for others to guess.

A phone number (SMS or phone call) requires an active cell network connection.
This is spoofable/interceptable/SIM-jackable, but for the most part, it
retains the important property that _at the time you log in_ , the site makes
a _request to your device_ to confirm the login. Things like Duo Push is a
less attackable version of this mechanism. In both cases that makes it harder
to use stolen credentials if "stolen" simply means 'digitally copied" \-
they'd need some way of disabling the actual physical device in your
possession, too.

A code generator doesn't require an network connection, but it's still active
unlike passwords: it changes every 30-60 seconds. That means a code that logs
you in now can't actually log you in forever, so someone who happens to
intercept a particular login request (say, someone who watches you type) can't
come back and log in later. They'd need the long-term secret which isn't
ordinarily revealed by the app except during backups. Things like RSA hardware
tokens are less attackable versions of this mechanism. An SSH key also falls
in this category - logging in with the SSH key doesn't reveal the entire key,
the way logging in with a password does.

A security key (U2F/FIDO/WebAuthn) is active like a code generator, but it
also _verifies the website that 's requesting the credential_. If someone
tricks you into visiting gitIab.com (with a capital I), your browser will send
that domain name to the security key, which will not respond with your actual
gitlab.com credentials. A password manager with a browser extension is a
_weaker_ form of this mechanism - there are a lot more avenues to attack, but
fundamentally none of the above mechanisms attempt to be resistant to phishing
/ social-engineering attacks.

So, sure, you could use a large QR code as a password, but that doesn't get
you the protections against attacks that the other MFA mechanisms do. It's
well worth setting up MFA on important accounts even if you are using a long
and unique password, because it protects you from attacks other than password-
guessing.

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

------
simonjgreen
Why the distinction between paid and free accounts though?

------
acdha
This is a terrible idea which encourages people to use weak security: it's
effectively telling people that if they enable MFA, GitLab will ensure that
they suffer irrecoverable damages — but if they don't enable MFA, everything
is recoverable. That is the opposite of what we want from a security
perspective and it risks causing users to be less secure everywhere else
because having seen that message will make them question whether they'll
regret enabling MFA even on sites which have good security policies.

GitLab should respect the trust that users place in it and account account for
the kind of life events which happen to people every day: houses get flooded
or burned, safes are burgled, people have to leave abusive situations in a
hurry and may be escaping household members who actively try to sabotage them,
people die without having made perfect handover plans (especially relevant
this year), etc. Of particular interest, consider why the browser
manufacturers reversed course on HTTPS key pinning after seeing attackers
successfully use it to prevent legitimate users from regaining control — if
implemented, this would make it extremely risky to use GitLab because everyone
would be one compromise away from an attacker having permanent control of your
account — and that would make GitLab look extremely bad for having put
themselves in the position of supporting the attacker _unless_ you pay GitLab
money (I am certain this is not the _intention_ but it is definitely how it
would look to say that FOSS developers are second-class).

There are a number of fallback techniques which can make most of those
situations recoverable, and it's okay if they're slow or inconvenient — nobody
complains that their airbags are messy. Some ideas:

1\. Have a process where someone can use a trusted third-party to verify
identity: for example, register identifiers (drivers license, passport, etc.)
and have a form which can be notarized after checking ID and mailed in. It's
slow but that works even in the “I lost everything I wasn't wearing” scenario
— and if you did just lose your house to a natural disaster or flee an abusive
ex, you probably have bigger concerns than getting control of your GitLab
identity back in less than a week.

2\. Configure next-of-kin / trusted friends who can approve a reset request,
perhaps requiring more than one.

3\. Allow the user to configure some number of IdPs to approve an unlock,
increasing the level of compromise that an attacker would need to hit before
getting the ability to perform a reset. There are drawbacks to this approach
but most people do not have threat models which are meaningfully resistant
against someone who can compromise multiple of {Apple, Google, Facebook,
Microsoft, login.gov, etc.} and could be pretty effective combined with a
time-delay (e.g. send notifications for n days before actually resetting MFA.

~~~
samanthalee233
I'm on the community advocates team at GitLab and we really appreciate your
feedback. I wanted to point out that our team responded to your post on the
GitLab forum, you can see the response here:
[https://forum.gitlab.com/t/gitlab-support-is-no-longer-
proce...](https://forum.gitlab.com/t/gitlab-support-is-no-longer-processing-
mfa-resets-for-free-users/40905/16?u=)

~~~
acdha
Thanks — I've been replying there but figured I should comment here since this
is where I first saw it. I definitely hope this leads to some UX work,
especially through the lens of thinking about how badly it will fail for
vulnerable users.

------
codezero
I agree, but having worked in SaaS, and done a lot of partnerships, Microsoft
has infinite leverage to turn something like MFA services into a co-branding
exercise that pays for itself.

~~~
toomuchtodo
Github is owned by Microsoft, not Gitlab (which is whom this link refers to).

~~~
app4soft
> _Github is owned by Microsoft, not Gitlab_

Yet.

~~~
codezero
I love this optimistic take on my failed comment :)

~~~
app4soft
As I'm a Symbian user, I could not be so optimistic :/

~~~
codezero
I am sorry for your lots :(

------
usr1106
The free internet services model is fundamentally broken. It's just not
sustainable that good service can be offered for free.

Where do you get free groceries, fee petrol/gas or anything else?

------
callesgg
Exactly just use a password no one is trying to hack your stuff, and the
biggest risk is you.

So sick of services that constantly tell me to use MFA.

No I don’t want to and if I thought the service was that important I would use
it.

~~~
dan_pixelflow
no... and im not even going to explain why

~~~
callesgg
Is it cause you think China or some hacker gives a shit about you? Newsflash
you are no one to most people. Your actions matter to no one but yourself and
the people close to you.

