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
> 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 lose your password you can do a password reset. On the second one, if your laptop and phone get fried in a rainstorm / car crash / act of children, you lose access to everything forever, no recourse and no recovery. And by the way, we totally encourage you to choose the second one... "
Yes, online services that store credentials and backup passwords mitigate this somewhat, but they also add an attack vector via keyloggers, or make you dependent on the third party's security measures.
And I probably don't need to point out to the HN crowd just how badly internet services are moving towards no-recourse solutions to petty problems to save money. Yet another one doing this is not a good thing.
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.
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.
> . On the second one, if your laptop and phone get fried in a rainstorm / car crash / act of children, you lose access to everything forever, no recourse and no recovery.
No. I just use my U2F token that I have on my keychain. Or the one I have in my office. Or the one I have in my safe.
I also backup my TOTP codes using GPG and my Yubikey can store up to 32 TOTP codes on it.
The problem with storing the 2FA keys in 1Password is that you're practically downgrading your account to 1FA because once 1Password is compromised, the second factor lost all of its value, though that compromise is much harder to achieve than a compromised shared machine I'm typing my password in on (which you probably also should never do).
I'm saying this as I'm looking at my 1Password database which also contains all my 2FA keys because, yes, all 2FA apps I tried so far treat these keys as way too valuable and the risk of losing them as I move from device to device is just too high.
Do as I say, not as I do I guess :p
I feel confident to rely on the security of my machine and 1Password specifically, though I am aware that I can't really claim my accounts to be secured by 2FA.
Yes, in 1Password's 2FA announcement its head of security mentions that using 2FA in 1PW does not give you true 2FA:
> If you would like to turn a site’s offering of TOTP into true two-factor security, you should not store your TOTP secret in 1Password (or in anything that will synchronize across systems).
They mention multiple times that if you want true 2FA the second factor needs to be on a different device or a physical key like a YubiKey.
Then they say that “two-step” security offered by 1PW + 2FA is probably enough for most use cases, and that 2FA in 1PW still has additional value because (a) some sites require 2FA and (b) one-time passwords offer protection against sniffing passwords over insecure networks.
The fact that 1PW even auto-copies the code to your clipboard after auto-filling a password so that you can paste it in when prompted raised my eyebrows when I first used the feature, though. It's very convenient but it's obvious at that point that you're throwing away the protection that storing the key on a second device would offer, even if 1PW requires you to authenticate before the app will open.
I use Lastpass for passwords and Authy for 2FA for this exact reason. If my Lastpass is compromised they only get my passwords, not my 2FA tokens. If Authy is compromised and they manage to get my 2FA backup they still don't have my passwords.
> I'm saying this as I'm looking at my 1Password database which also contains all my 2FA keys because, yes, all 2FA apps I tried so far treat these keys as way too valuable and the risk of losing them as I move from device to device is just too high.
When I set up TOTP on a site, I save the QR code as a PNG file (via the Grab application on my Mac) and the text version of the code in a text file. (If the site provided some one-time use recovery codes, those all go in the text file). Those two files go into a directory, that directory gets made into a tarball, which then gets encrypted, then stored in my "recovery" directory which later gets saved in an encrypted backup.
That's all after I scan the QR code into an authenticator app on my phone.
Moving codes to a new device is then just a matter of decrypting and extracting them from my recovery directory and scanning them on the new device.
I do this too. And each time I mention my hard copies I also have to explain there are actually 3 copies, physically isolated, etc. Hope you're doing the same.
You can store the TOTP seeds in more compact form by converting QR code screenshots to alphanumeric using zbar barcode tools.
In my experience it has difficulty parsing some QR codes created using CSS due to tiny borders between blocks. Those can be fixed by applying a small gaussian blur followed by sharpening (use imagemagick for maximum automation) to fill out the borders.
I recommend andOTP and Aegies if you are using android. The first one is more mature, second more actively developed. Both open source with ability to backup you database.
Yes, I can confirm I've had the same google auth token on multiple devices both concurrently and when setting up new phones for a SaaS login for years now.
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.
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.)
Yes. I would cheerfully enable this for almost everything. If your product or service isn't worth several hours of my time to try to recover, then I shouldn't have to risk it being worth several hours of somebody else's time to steal it.
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.
The problem is that it's helping attackers and it doesn't send a great message to say “if someone roots you, we'll ensure that you can't recover” and “FOSS developers aren't important enough to be secure”.
Support cost is a valid consideration but it's something they could address using payment infrastructure they already have: require someone to pay $20 to get a reset, with a delay period where the account is frozen but before the MFA reset goes into place.
> 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?
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.
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.
What about using time ? Let support reset MFA, but with a mandatory x days (3? 5? 7?) “cooling period”. And spam the user email with notifications during that time period.
That's probably why their corporate resets take at least 3 business days. For companies, if you send warning emails for 3 business days to all accounts, someone will see it and social engineering is nearly impossible.
For individual accounts that's different though. Even with a three day waiting period it's not guaranteed that a user will see it. It also is a big cost on Gitlab which isn't justified for free users.
> What are some good strategies you've seen other providers take?
Fallback to SMS auth if you've lost your MFA and recovery codes. It's not good per se, but the users who need it will love you and the users who get SIM jacked/swap attacked will hate you. You're not going to please everyone. I've been trying to figure out a good way to handle this, but at least in the US, there isn't a good government provided identity provider you could rely on to true up identity issues when auth factors are lost (login.gov just ain't there yet, but it might get there as it's what US DHS uses to auth you for Global Entry, and what you're looking for is essentially a programatic/digital notary to attest to you that the person is whom they say they are).
If I'm going to allow my account to be recovered via SIM, why not just use "poor man's MFA" by just authing via SIM? Security is as weak as its weakest link.
I looked at GitLab's recovery options, and you have the option of recovering your MFA if you have access to any SSH key used to publish to GitLab. That seems like a reasonable backup for now.
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.
It would be a good idea to make this decision a user setting, choosing complete lockout or ability to get support to reset your account. For most accounts people probably don't want full lockout, but for things like source code maybe they do. It really should be a user decision, the liability is all on them then and they are at least aware of the stakes.
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.
That's an interesting approach. It incentivizes users to have a backup plan while also providing an escape hatch if things go wrong. The only issue is, like you alluded to, this could price out a large portion of the world's developer population. Perhaps the price could be determined by where you are in the world, although this may not cover US support costs. That and users could attempt to game the system by faking their location. Regardless, it's an interesting approach I hadn't considered before - I like it.
This doesn't really solve the problem causing GitLab to enforce this change; I highly doubt the cost of providing support to users for MFA had any bearing on this discussion.
Meanwhile, Gray's suggestion would provide any attacker within enough capital to a backdoor, while legitimate users need to pay to unlock their account without any benefit to them from a security perspective.
I strongly disagree with such a concept -- unless, as you mentioned, payment could be used to verify the identity. That said, I think that's the same reason GitLab is now only offering MFA for paying customers, because they have a bit more PII to confirm your identity if you're a current customer -- in which case, why require payment at all?
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.
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.
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.
I don't feel the need to go beyond SMS/TOTP MFA for my personal, private, security. I can just call my banks and recover if I lose my phone and SIM somehow.
However, I have an open source project with at least a thousand users who could be severely harmed by both compromise of my account (malicious code changes) or loss of my account (having to fork without being able to update the original).
With this change, in order to protect my users I have to go beyond an anti-compromise standard of MFA to an anti-loss standard of MFA (e.g. by buying many physical devices). I also have to be constantly vigilant as if I mess up and break my MFA, lose that piece of paper, have my house burn down, I harm many people.
So, do I choose to disable MFA, and risk my users machines being compromised?
Or do I enable MFA, and risk my mental health?
Or do I just stop supporting this open source project?
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.
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
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.
> 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.
The safest option would be to prompt users next time they log in (or at least next time they use the site) and have them choose one of "Sounds great, please permanently enable MFA" or "Please disable MFA on my account for now." However, that'd probably leave you with a long tail of users (like, uh, myself) who use gitlab.com rarely and will be in the limbo state for months.
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.
Readit News
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
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 lose your password you can do a password reset. On the second one, if your laptop and phone get fried in a rainstorm / car crash / act of children, you lose access to everything forever, no recourse and no recovery. And by the way, we totally encourage you to choose the second one... "
Yes, online services that store credentials and backup passwords mitigate this somewhat, but they also add an attack vector via keyloggers, or make you dependent on the third party's security measures.
And I probably don't need to point out to the HN crowd just how badly internet services are moving towards no-recourse solutions to petty problems to save money. Yet another one doing this is not a good thing.
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.
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.
No. I just use my U2F token that I have on my keychain. Or the one I have in my office. Or the one I have in my safe.
I also backup my TOTP codes using GPG and my Yubikey can store up to 32 TOTP codes on it.
I would argue that this is a negative thing. Sites should at least give the option to disable password reset.
Deleted Comment
I'm saying this as I'm looking at my 1Password database which also contains all my 2FA keys because, yes, all 2FA apps I tried so far treat these keys as way too valuable and the risk of losing them as I move from device to device is just too high.
Do as I say, not as I do I guess :p
I feel confident to rely on the security of my machine and 1Password specifically, though I am aware that I can't really claim my accounts to be secured by 2FA.
> If you would like to turn a site’s offering of TOTP into true two-factor security, you should not store your TOTP secret in 1Password (or in anything that will synchronize across systems).
They mention multiple times that if you want true 2FA the second factor needs to be on a different device or a physical key like a YubiKey.
Then they say that “two-step” security offered by 1PW + 2FA is probably enough for most use cases, and that 2FA in 1PW still has additional value because (a) some sites require 2FA and (b) one-time passwords offer protection against sniffing passwords over insecure networks.
https://blog.1password.com/totp-for-1password-users/
The fact that 1PW even auto-copies the code to your clipboard after auto-filling a password so that you can paste it in when prompted raised my eyebrows when I first used the feature, though. It's very convenient but it's obvious at that point that you're throwing away the protection that storing the key on a second device would offer, even if 1PW requires you to authenticate before the app will open.
When I set up TOTP on a site, I save the QR code as a PNG file (via the Grab application on my Mac) and the text version of the code in a text file. (If the site provided some one-time use recovery codes, those all go in the text file). Those two files go into a directory, that directory gets made into a tarball, which then gets encrypted, then stored in my "recovery" directory which later gets saved in an encrypted backup.
That's all after I scan the QR code into an authenticator app on my phone.
Moving codes to a new device is then just a matter of decrypting and extracting them from my recovery directory and scanning them on the new device.
I keep my keys in analog form - I print QR code for every service. We know how to handle valuables stored on paper.
You can store the TOTP seeds in more compact form by converting QR code screenshots to alphanumeric using zbar barcode tools.
In my experience it has difficulty parsing some QR codes created using CSS due to tiny borders between blocks. Those can be fixed by applying a small gaussian blur followed by sharpening (use imagemagick for maximum automation) to fill out the borders.
Edit: packages available in Ubuntu (zbar-tools) & Fedora (zbar), source code at https://github.com/mchehab/zbar
As far as cloud storage goes, standard notes might be a good option, I don't use it for 2FA, but it's an extension they provide.
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.
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.)
I may have misread the announcement, but it sounds like upgrading to a paid account recovers (npi) the ability to recover your account.
With free users you also have less information available to you as a provider in determining if the reset request is legit or not.
Support cost is a valid consideration but it's something they could address using payment infrastructure they already have: require someone to pay $20 to get a reset, with a delay period where the account is frozen but before the MFA reset goes into place.
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 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?
For individual accounts that's different though. Even with a three day waiting period it's not guaranteed that a user will see it. It also is a big cost on Gitlab which isn't justified for free users.
Fallback to SMS auth if you've lost your MFA and recovery codes. It's not good per se, but the users who need it will love you and the users who get SIM jacked/swap attacked will hate you. You're not going to please everyone. I've been trying to figure out a good way to handle this, but at least in the US, there isn't a good government provided identity provider you could rely on to true up identity issues when auth factors are lost (login.gov just ain't there yet, but it might get there as it's what US DHS uses to auth you for Global Entry, and what you're looking for is essentially a programatic/digital notary to attest to you that the person is whom they say they are).
IAM is hard.
I looked at GitLab's recovery options, and you have the option of recovering your MFA if you have access to any SSH key used to publish to GitLab. That seems like a reasonable backup for now.
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.
0: https://risky.biz/soapbox43/
Meanwhile, Gray's suggestion would provide any attacker within enough capital to a backdoor, while legitimate users need to pay to unlock their account without any benefit to them from a security perspective.
I strongly disagree with such a concept -- unless, as you mentioned, payment could be used to verify the identity. That said, I think that's the same reason GitLab is now only offering MFA for paying customers, because they have a bit more PII to confirm your identity if you're a current customer -- in which case, why require payment at all?
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.
Sort of like "If this person is paying for this, he's probably legit."
The only correct response to this is for companies to make it against internal policy for developers to enable 2FA. Which is sad.
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.
However, I have an open source project with at least a thousand users who could be severely harmed by both compromise of my account (malicious code changes) or loss of my account (having to fork without being able to update the original).
With this change, in order to protect my users I have to go beyond an anti-compromise standard of MFA to an anti-loss standard of MFA (e.g. by buying many physical devices). I also have to be constantly vigilant as if I mess up and break my MFA, lose that piece of paper, have my house burn down, I harm many people.
So, do I choose to disable MFA, and risk my users machines being compromised?
Or do I enable MFA, and risk my mental health?
Or do I just stop supporting this open source project?
Dead Comment
[0] “What if this is a work account?“ FAQ header in OP
Deleted Comment
Deleted Comment
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...
> 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.
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.