20 ms·
Gitlab Support is no longer processing MFA resets for free users
- sixhobbits 6y agoI 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.
- whatl3y 6y agoIt 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
- deleted 6y ago[deleted]
- deleted 6y ago[deleted]
- graton 6y agoGitlab 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 6y agothis 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 6y ago> you're living in a very small bubble. Why did you try to make this personal by attempting to insult me?
- Dayshine 6y agoI 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?
- sarakayakomzin 6y ago>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. damn, that's a tall horse!
- smallsaas 6y agoSeems like a good way to discourage the use of mfa...
- nawgz 6y agoSeems 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.
- whatl3y 6y ago> 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 agoCertifying 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 agoThey 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).
- frio 6y ago> 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.
- nawgz 6y ago>it reads as dismissive Really? It's followed with a link to their community forum, which they are telling you they will read and consider feedback from. I don't know how else you can signal "we will consider your feedback" other than saying "we get you might not like this so we will have an open discussion at this hyperlinked resource".
- lkozloff 6y agoSupport 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 6y agoSorry, 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?
- belltaco 6y agoThis 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 6y agoSupport 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/adc7dbeb387adc690cbe1fff650846bc48970348/app/views/profiles/two_factor_auths/_codes.html.haml#L2 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.
- geofft 6y agoThe 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.
- Dayshine 6y agoI made this post on the forums: https://forum.gitlab.com/t/gitlab-support-is-no-longer-processing-mfa-resets-for-free-users/40905/15?u=tboby https://forum.gitlab.com/t/gitlab-support-is-no-longer-proce... 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.
- StavrosK 6y agoI 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 6y agoFor 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.
- StavrosK 6y agoI really hate SMS for security, given how easy it is to hijack a number for a few minutes. It has been the basis of so many hacks, that we'd do well to just abolish it everywhere.
- virtue3 6y agobut convenient :) I'd feel really uncomfortable if it wasn't a backup option. But if it's a backup option it's a security hole. That's a tough circle.
- EdJiang 6y agoFor comparison, here's GH Policy: https://docs.github.com/en/github/authenticating-to-github/recovering-your-account-if-you-lose-your-2fa-credentials 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?
- toomuchtodo 6y ago> 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). IAM is hard.
- EdJiang 6y agoIf 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.
- toomuchtodo 6y agoI agree with your points. Really depends on the service, what auth factors you have available to you, what your risk appetite is, etc.
- Androider 6y agoAlthough 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 6y agoI'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.
- acdha 6y agoThe 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.
- codezero 6y agoI 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 6y agoGithub is owned by Microsoft, not Gitlab (which is whom this link refers to).
- jkaplowitz 6y ago> 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. Microsoft owns GitHub, not GitLab. This article is about GitLab.
- quadrangle 6y agoInstead of just saying they won't do it for free accounts, they could charge a fee for the service.
- Androider 6y agoThey do, it just happens to be a $4 / month fee and they'll even throw in some other features ;) For security reasons you cannot pay for the service if you're not able to access the account, so you better enable it ahead of time.
- Rapzid 6y agoThis is the answer. Charge 2-4 years worth of basic subscription to recover. Or a 1 year up-front payment and recurring after that. Otherwise, with no path forward, this is just user hostile.
- TheChaplain 6y agoThen next post on HN will be how GitLab is "blackmailing" users who lost their credentials...
- JadeNB 6y agoGood 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 6y agoI 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
- exabrial 6y agoThis 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.
- totetsu 6y agoWhat are the current best options for hardware tokens then?
- exabrial 6y agoYubico 5c by far. There is also "soft tokens" that are software devices.
- tialaramex 6y agoIf 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 6y agoSites 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 6y agoWhich "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.
- cmeacham98 6y agoIs 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.
- zndr 6y agoYes 100% it does make it safer.
- tialaramex 6y agoYes. 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.
- GoblinSlayer 6y agoDoes it make free accounts safer than paid accounts?
- tgsovlerkhgsel 6y agoIt 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 6y ago> ... 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.
- jeppesen-io 6y agoAs 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 6y agoNot 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 6y agoGitLab does have this, here is a link to our docs with more info: https://docs.gitlab.com/ee/user/profile/account/two_factor_authentication.html#recovery-codes https://docs.gitlab.com/ee/user/profile/account/two_factor_a... and how you can regenerate them if you lose them: https://docs.gitlab.com/ee/user/profile/account/two_factor_authentication.html#generate-new-recovery-codes-using-ssh https://docs.gitlab.com/ee/user/profile/account/two_factor_a...
- lebaux 6y agoTo be fair, both GH and GL tell you in painfully obvious ways that those recovery codes are important.
- graton 6y agoMaybe invest in a couple of U2F tokens that you can keep on a keychain or at home.
- nooyurrsdey 6y agoGood - 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
- manojlds 6y agoIsn't there Authy?
- vmception 6y agoAuthy's SMS convenience/reliance undermines the whole thing. Avoid.
- jackson1442 6y agoYou can turn off Multi-Device at any time, which just disables the ability to add new devices. I think that's protection enough.
- xvector 6y agoAuthy supports symmetrically encrypting your OTP codes with a password which is fine IMO: https://authy.com/blog/how-the-authy-two-factor-backups-work/ https://authy.com/blog/how-the-authy-two-factor-backups-work...
- lebaux 6y agoI 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.
- triyambakam 6y agoThanks for sharing that! I've been looking for something besides Google Authenticator
- usr1106 6y agoThe 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?
- simonjgreen 6y agoWhy the distinction between paid and free accounts though?
- deleted 6y ago[deleted]
- jokoon 6y agoQuestion: How secure would it be to use a QR code as a password, and scan it with a phone camera?
- geofft 6y agoIt'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.
- geofft 6y agoSide 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.
- lacker 6y agoThis 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.
- mschuster91 6y agoWhy 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)
- callesgg 6y agoExactly 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.
- deleted 6y ago[deleted]
- dan_pixelflow 6y agono... and im not even going to explain why
- callesgg 6y agoIs 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.
- miki123211 6y agoThis 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.
- sixhobbits 6y agoThey mention this as an exception that they will still handle manually in the community thread https://forum.gitlab.com/t/gitlab-support-is-no-longer-processing-mfa-resets-for-free-users/40905/2 https://forum.gitlab.com/t/gitlab-support-is-no-longer-proce...
- SifJar 6y agoOr you can just enable MFA yourself, and prevent that from happening? Am I missing something?
- marcrosoft 6y agoSeconding this: enforce MFA on all gitlab accounts and make sure they at least click the print recovery codes button.
- littldevl 6y agoIn your world no one ever makes mistakes or errors, it must be nice.
- SifJar 6y agoNot 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
- drawkbox 6y agoIt 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.
- u801e 6y agoI 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 6y agoI 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.
- Ajedi32 6y agoIsn'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 6y agoThat does somewhat presuppose access to a printer.
- Ajedi32 6y agoSlightly less convenient, but if you don't have access to a printer you could always just write the codes down.
- acdha 6y agoThis 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.
- K0nserv 6y agoThere 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/
- schwag09 6y agoThat'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.
- Dayshine 6y agoSo, 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 6y agoDon’t lose your recovery codes and you should be fine, right?
- Dayshine 6y agoYeah, 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.