Live data from Hacker News

Gitlab Support is no longer processing MFA resets for free users

about.gitlab.com

51–60 of 228 posts

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

#51
post #3

> 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 pie…

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

[2]: https://developer.apple.com/documentation/localauthenticatio...

[3]: https://developer.apple.com/documentation/security/ksecattra...

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

#52
post #5

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

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.

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

#53
post #3

> 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 pie…

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

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

#54

Earlier quoted context omitted.

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.

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

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

#55

Earlier quoted context omitted.

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.

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

Does no one else take real vacations these days?

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

#56
post #43

Earlier quoted context omitted.

Ugh, thanks for the courtesy comment and not downvoting me to oblivion for not being able to read quite well enough.

I really appreciate your good humour about this, but it seems to me to be less classy to delete the original comment; it invalidates later comments, and leaves people to infer what is missing from contextual clues (in this case ample, but not always). Why not just put a note up top saying "EDIT: I misread; thanks to jkaplowitz and toomuchtodo for setting me straight", while leaving the original post intact?

I also appreciate your good humor and sentiment.

I deleted my comment because while I appreciate the context staying, I felt it was retained in children replies and I also feel that it’s my right as a human being to remove my own stupidity from the Internet as long as I’ve left a clear trail documenting it for others to learn from, so that’s why I deleted it :)

I also added it back because I’m easily swayed by civility online. It’s in short supply.

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

#57

Earlier quoted context omitted.

How is it less secure than no second factor?

There have been many instances of attacks of people hijacking the connection, calling the service and saying "I forgot my password, can you reset it by verifying my SMS?", which wouldn't have been possible without a second factor.

I'd argue that it isn't truly a second factor if it can be used on it own...

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

#58
post #7

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.

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

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

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

#59
post #55

Earlier quoted context omitted.

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

Does no one else take real vacations these days?

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

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

#60
post #45

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

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!"

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

Post reply on HN