4 ms·

> 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

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

leonidasv 6y ago
Certifying authenticity is a manual process and costs money. Even though I think GitLab could have handled it better, I understand their reasons.
- deleted 6y ago
  [deleted]
turnerc 6y ago
> Even crypto exchanges allow recovery if you lose all traditional recovery Yes, and Crypto exchanges are a paid product so they would be able to provide this additional support.
- qes 6y ago
  They do it because they'd lose business by the metric ton if it was possible to irrecoverably lose access to your account. It's probably not even legal.. I would bet it's not for a bank and if it's not for crypto exchanges it's only because of some legislative gap that hasn't been filled yet. Crypto exchanges aren't known for their well staffed support departments, either, and they'll reset your MFA even if you haven't provided them with income (you don't pay simply to have an account, only when you buy & sell).
akerl_ 6y ago
For somebody who signed up to your SaaS service as an individual, enabled MFA, and then lost their MFA device / recovery codes / etc, how do you validate they’re the account owner to reset MFA? I’m not aware of any way to validate this that doesn’t open the door to various trivial degrees of attack.
- derekp7 6y ago
  If it is an anonymous account (identified only by a made up user ID and password), then that limits options. If a user supplies credentials when creating the account, including a valid credit card that ties back to the individual, then later on when a reset is required the user can open a paid support ticket with a credit card (either same one, or another one in their name). If a user is more paranoid, they can select the list of recovery criteria at MFA creation time. This can include the common method of charging the card, submitting two small amounts (less than a dollar each) in the user's bank account and having the user report those amounts back, followed up by a physical letter with a reset code. All of this gets paid for by the initial credit card charge ($10 would be reasonable for many people). Also, have the option of registering more than one MFA.
  - akerl_ 6y ago
    As per the post, this policy change only affects free users (so, users who aren’t using a credit card to pay GitLab). They also do support multiple FIDO2 tokens as well as recovery codes.
    - derekp7 6y ago
      Right, what I was proposing is that even a free user should be able to (optionally) provide enough identifying information when setting up MFA. Then upon needing a reset, that would be a per-incident charge.
codetrotter 6y ago
I started working on a replacement TOTP app on iOS that I intend to use instead of Google Authenticator. (Currently I am not planning on supporting HOTP, since all of the accounts that I secure with Google Authenticator are using TOTP.) Google Authenticator prevents the MFA shared secrets from syncing to iCloud and it also prevents said shared secrets from being restorable from local backup to any device aside from the device where the secret was originally put into Google Authenticator [1]. What Google Authenticator does is good for security but not so great for the experience of switching phones. The first time I came across this was a few years ago, when for the first time after beginning to use Google Authenticator I had bought a new phone, and I had factory reset my old phone and was restoring the local backup of it to a new phone. At the time, when I saw that Google Authenticator was empty on the new phone I freaked out a little bit and I also did not realise that I would be able to restore them on the old phone still because I assumed that them not being on the new phone meant that they were not included in the backup at all. So I went through account recovery for all of the accounts that I had MFA enabled on and it was a bit of a drag but at least all of them allowed me to use my e-mail or phone number in order to regain access so I was not permanently locked out of any of my accounts. When I set up MFA again on the accounts, I stored screenshots of the QR codes for each of them all together in a directory on an external, encrypted drive. Still though, when I replace old hardware with new hardware those QR codes can become difficult to find back to. And keeping the files on an external drive at home also means that if I lose my phone while I am traveling then I can't access the QR codes that I saved until I get back home. So currently I have decided that at the very least my app will allow me to retrieve the original MFA shared secrets from within it when the phone is unlocked (PIN code) and user presence is confirmed. In other words; kSecAttrAccessibleWhenUnlockedThisDeviceOnly, .userPresence [2] [3] Doing as I suggest in the above paragraph will at least make it simple to set up the MFA on a new device as long as I still have the old device in hand, without having to go through each account and disabling and re-enabling MFA in order to get new shared secrets for each of them. So far I consider the security of my MFA to be equivalent to that of not having export functionality built in. If my device is lost or stolen, the data would still remain as well guarded as they were. Beyond that I am thinking about even compromising on the security a bit by allowing the TOTP shared secrets in the keychain to be synchronised to iCloud. But I am still a bit on the fence about that one. I have misplaced my phone in the past, and I've caused accidentally damage to it as well when it has slipped out of my hand. So there is a plausible risk that I might lose or accidentally destroy my phone while traveling. Then again, when I travel I also bring with me my MacBook Air. So instead of syncing the TOTP to iCloud, I could make a macOS version of the TOTP app and have it function in the same way that it would on the phone in terms of requiring that my machine is unlocked and presence is confirmed and then allowing the TOTP shared secrets to be seen. And whenever I add a TOTP shared secret, I do so on both my computer and my phone (either at the same time or one first and then later the other). If I was on a trip and I lost or accidentally destroyed both my phone and my computer at the same time, I would certainly be returning home early anyway. And if on top of that my home had burned to the ground while I was away, so that the external drive at home was gone too, well, I think that then the TOTP stuff would be the least of my concerns anyways. Probably. So I think I've figured out the answer to what my app should do. iCloud no, show secrets when unlocked and presence confirmed yes. [1]: https://apple.stackexchange.com/questions/305372/will-my-google-authenticator-codes-work-if-i-restore-my-iphone-from-a-backup https://apple.stackexchange.com/questions/305372/will-my-goo... [2]: https://developer.apple.com/documentation/localauthentication/accessing_keychain_items_with_face_id_or_touch_id https://developer.apple.com/documentation/localauthenticatio... [3]: https://developer.apple.com/documentation/security/ksecattraccessiblewhenunlockedthisdeviceonly https://developer.apple.com/documentation/security/ksecattra...
lkozloff 6y ago
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-2fa-support-security/ https://about.gitlab.com/blog/2018/10/08/enforcing-managing-...
- tgsovlerkhgsel 6y ago
  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 6y ago
    > 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.
tgsovlerkhgsel 6y ago
Offtopic: > 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. With the high values at stake and the number of passport copies leaked from various breaches, I'm surprised this works as well as it apparently does.
boring_twenties 6y ago
Crypto exchanges make money off most customers, though, so they can afford to dedicate support staff to recovering people's 2FA. Does GitLab make any money at all on free users, or are they just a loss leader? Note that paid GitLab users aren't losing the recovery option, only free ones.

leonidasv 6y ago

Certifying authenticity is a manual process and costs money. Even though I think GitLab could have handled it better, I understand their reasons.

deleted 6y ago
[deleted]

turnerc 6y ago

> Even crypto exchanges allow recovery if you lose all traditional recovery Yes, and Crypto exchanges are a paid product so they would be able to provide this additional support.

qes 6y ago
They do it because they'd lose business by the metric ton if it was possible to irrecoverably lose access to your account. It's probably not even legal.. I would bet it's not for a bank and if it's not for crypto exchanges it's only because of some legislative gap that hasn't been filled yet. Crypto exchanges aren't known for their well staffed support departments, either, and they'll reset your MFA even if you haven't provided them with income (you don't pay simply to have an account, only when you buy & sell).

akerl_ 6y ago

For somebody who signed up to your SaaS service as an individual, enabled MFA, and then lost their MFA device / recovery codes / etc, how do you validate they’re the account owner to reset MFA? I’m not aware of any way to validate this that doesn’t open the door to various trivial degrees of attack.

derekp7 6y ago
If it is an anonymous account (identified only by a made up user ID and password), then that limits options. If a user supplies credentials when creating the account, including a valid credit card that ties back to the individual, then later on when a reset is required the user can open a paid support ticket with a credit card (either same one, or another one in their name). If a user is more paranoid, they can select the list of recovery criteria at MFA creation time. This can include the common method of charging the card, submitting two small amounts (less than a dollar each) in the user's bank account and having the user report those amounts back, followed up by a physical letter with a reset code. All of this gets paid for by the initial credit card charge ($10 would be reasonable for many people). Also, have the option of registering more than one MFA.
- akerl_ 6y ago
  As per the post, this policy change only affects free users (so, users who aren’t using a credit card to pay GitLab). They also do support multiple FIDO2 tokens as well as recovery codes.
  - derekp7 6y ago
    Right, what I was proposing is that even a free user should be able to (optionally) provide enough identifying information when setting up MFA. Then upon needing a reset, that would be a per-incident charge.

codetrotter 6y ago

I started working on a replacement TOTP app on iOS that I intend to use instead of Google Authenticator. (Currently I am not planning on supporting HOTP, since all of the accounts that I secure with Google Authenticator are using TOTP.) Google Authenticator prevents the MFA shared secrets from syncing to iCloud and it also prevents said shared secrets from being restorable from local backup to any device aside from the device where the secret was originally put into Google Authenticator [1]. What Google Authenticator does is good for security but not so great for the experience of switching phones. The first time I came across this was a few years ago, when for the first time after beginning to use Google Authenticator I had bought a new phone, and I had factory reset my old phone and was restoring the local backup of it to a new phone. At the time, when I saw that Google Authenticator was empty on the new phone I freaked out a little bit and I also did not realise that I would be able to restore them on the old phone still because I assumed that them not being on the new phone meant that they were not included in the backup at all. So I went through account recovery for all of the accounts that I had MFA enabled on and it was a bit of a drag but at least all of them allowed me to use my e-mail or phone number in order to regain access so I was not permanently locked out of any of my accounts. When I set up MFA again on the accounts, I stored screenshots of the QR codes for each of them all together in a directory on an external, encrypted drive. Still though, when I replace old hardware with new hardware those QR codes can become difficult to find back to. And keeping the files on an external drive at home also means that if I lose my phone while I am traveling then I can't access the QR codes that I saved until I get back home. So currently I have decided that at the very least my app will allow me to retrieve the original MFA shared secrets from within it when the phone is unlocked (PIN code) and user presence is confirmed. In other words; kSecAttrAccessibleWhenUnlockedThisDeviceOnly, .userPresence [2] [3] Doing as I suggest in the above paragraph will at least make it simple to set up the MFA on a new device as long as I still have the old device in hand, without having to go through each account and disabling and re-enabling MFA in order to get new shared secrets for each of them. So far I consider the security of my MFA to be equivalent to that of not having export functionality built in. If my device is lost or stolen, the data would still remain as well guarded as they were. Beyond that I am thinking about even compromising on the security a bit by allowing the TOTP shared secrets in the keychain to be synchronised to iCloud. But I am still a bit on the fence about that one. I have misplaced my phone in the past, and I've caused accidentally damage to it as well when it has slipped out of my hand. So there is a plausible risk that I might lose or accidentally destroy my phone while traveling. Then again, when I travel I also bring with me my MacBook Air. So instead of syncing the TOTP to iCloud, I could make a macOS version of the TOTP app and have it function in the same way that it would on the phone in terms of requiring that my machine is unlocked and presence is confirmed and then allowing the TOTP shared secrets to be seen. And whenever I add a TOTP shared secret, I do so on both my computer and my phone (either at the same time or one first and then later the other). If I was on a trip and I lost or accidentally destroyed both my phone and my computer at the same time, I would certainly be returning home early anyway. And if on top of that my home had burned to the ground while I was away, so that the external drive at home was gone too, well, I think that then the TOTP stuff would be the least of my concerns anyways. Probably. So I think I've figured out the answer to what my app should do. iCloud no, show secrets when unlocked and presence confirmed yes. [1]: https://apple.stackexchange.com/questions/305372/will-my-google-authenticator-codes-work-if-i-restore-my-iphone-from-a-backup https://apple.stackexchange.com/questions/305372/will-my-goo... [2]: https://developer.apple.com/documentation/localauthentication/accessing_keychain_items_with_face_id_or_touch_id https://developer.apple.com/documentation/localauthenticatio... [3]: https://developer.apple.com/documentation/security/ksecattraccessiblewhenunlockedthisdeviceonly https://developer.apple.com/documentation/security/ksecattra...

lkozloff 6y ago

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-2fa-support-security/ https://about.gitlab.com/blog/2018/10/08/enforcing-managing-...

tgsovlerkhgsel 6y ago
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 6y ago
  > 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.

tgsovlerkhgsel 6y ago

Offtopic: > 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. With the high values at stake and the number of passport copies leaked from various breaches, I'm surprised this works as well as it apparently does.

boring_twenties 6y ago

Crypto exchanges make money off most customers, though, so they can afford to dedicate support staff to recovering people's 2FA. Does GitLab make any money at all on free users, or are they just a loss leader? Note that paid GitLab users aren't losing the recovery option, only free ones.