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.
You can get a slightly more bothersome PIN prompt in Windows with a FIDO2 Authenticator (entering your PIN serves the same purpose as providing a fingerprint, neither a PIN nor a fingerprint leaves your device), or you can lose the convenience and do traditional two separate factors.
I think you should call the authorities to report that your local zoo or safari park is poorly managed if this keeps happening so that it interferes with how you regularly use web sites.
More seriously - yes, you still need a more complicated recovery procedure for extraordinary cases, but these are now truly extraordinary cases, rather than, as the original thread claimed, just a routine nuisance for the user.
It is of course up to people if they want to enable additional security and of course have to put up with increased friction and difficulty.
Myself I consider what would it mean if someone got access to my Github, Gitlab, and/or email accounts and have decided that I will put up with the cost (buying U2F tokens) and hassle (having to use the U2F token to login).
The alternative is the much higher chance that someone could at some point get into one of my accounts.
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.
At any non-shady dealership, you should presumably have to give some sort of evidence that you own the car in question (registration documents etc. and ID matching the name on the registration). For many online accounts, you probably don't need (or want) to give ID when creating account, so that's out as a way to prove ownership when attempting to recover. So how else do you prove ownership?
I did this recently actually, bought a car where the owner only had a valet key. Had to email them a copy of my registration, my driver's license and the VIN, and they ordered me a new key.
For important accounts I wonder if we should have the ability to tie them to a physical address or something else possible to verify.
> . 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.
That's an argument that works well for getting an MVP out the door, not so well if a company decides to make their product worse to save a little money.
I use randomly generated passwords that are unique per site. It is more likely for someone to socially engineer the site support (or the registered mail account) than to guess it.
Another annoying thing is that some sites do not consider your password enough even if you do not have 2fa enabled and they insist on sending you a mail (thanks github! - I can't connect to my account there because the registered mail was in my old domain) or an sms (thanks google/twitter! I had not even provided my phone number yet somehow giving it to you will verify that it's me)
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.
since the qr code is just the totp seed, i simply print the seed in huge font on a sheet of paper. chance of enough degredation to inlegibility is pretty slim if stored correctly
Screenshot the QR Code and print it? Put it in a vault or store somewhere safe. It’s a standard practice for securing enterprise accounts (AWS root acc. for example)
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.)
I suspect if one can a) exhibit genuine interest in becoming a customer waving their credit card around, and b) demonstrate ownership of 1FA for the account, then this would be relatively straightforward.
Or rather, at least as straightforward as the process is meant to be for existing paid-up customers, as per TFA.
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.
That depends on the country. In Europe 4 weeks of summer holidays are common, in some countries even the law. An increasing number of people logs in to work accounts during holidays, but generally it's considered poor work-life balance. I don't take pressure either way, I might or might not log in once or twice during my 3 weeks (twice a year) if I am curious about something. My private mail I scan occasionally, but it has happened many times that I haven't done so for 2 weeks. There is enough stress in my life, I don't need to be connected every day of the year. There is a phone for personal emergencies. And if someone is afraid someone is dying before they get there they probably can never move out of their parents' home.
Ever went to a National Park or National Forest? There are huge areas without reception (mostly on purpose). Even if you're on camping grounds with facilities and not hiking in the wilderness, having no reception for several days is standard.
In fact, I know people who choose the camping grounds for that. There's no better way to properly relax than not having any possibility to check what's going on in the world.
Many financial institutions are required by regulation to enforce a minimum contiguous two week period without accessing internal systems. Even if the regulations don't require it, it's not necessarily a bad idea.
If your systems are so fragile that they can't cope with a two week absence, that's a problem. And the point of the regs is to flush out people who are trying to cover up problems -- two weeks may well be long enough for someone else to notice something they wouldn't normally notice because the person who is away would normally "deal with it".
The other measure I'd add are trusted intermediaries: that helps both with continuity (e.g. “any 2 of these 5 people are allowed to confirm that I am legally dead”) and notifications like this as long as they aren't all people you go on long vacations in remote areas with.
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.
Not sure how you get that conclusion from my comment, of course people make mistakes - my suggestion is one way to prevent such a mistake? i.e. if you have MFA enabled, it "doesn't matter" as much if you do make a mistake and accidentally reveal your password to someone
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.
Yeah, sure, set up a recovery process I don't need anywhere else in life and hope I never mess that up. Then have several thousand people (or far more if I'm lucky) rely on it, I'm sure that'll go well!
I don't need recovery codes for anything in my professional nor personal life outside open source programming.
I don't think that's true though. I have recovery codes for my MFA for Azure, Google, Fastmail, and many others. I'm wouldn't count on being able to convince support to let me into any of these accounts if I lost my MFA and my backups. They might, but as the article mentioned it'd be hard to do in a way that doesn't defeat the purpose of MFA in the first place.
You don’t have any other MFAs you need to manage in your digital life? That seems ... odd. It seems like you’re deciding to make an issue of, well, how MFA is _supposed_ to work.
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.
I generally support not resetting MFA credentials, and understand where Gitlab is coming from, but wish there were an easier way for the average user. I think that easier way is getting two FIDO2 keys (they're pretty cheap and will get cheaper), and have one on your keychain and one at home, as a backup.
For a casual user (unlikely to be specifically targetted for attack) I think SMS is a good option. If you lose your phone then you can just order a replacement sim card and you have your second facto back.
I 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.
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 think they offer TOTP now, right? Started sometime last year? Do you have to activate SMS alongside it?
I have been using TOTP with PayPal for (I think) a few years now. You used to have to run some weird local Python script that somehow imitated the one RSA (I think) dongle they supported in a way I don't understand, but the net result was that you just get a TOTP key that works fine.
I wasn't able to see any way to do even TOTP for PayPal when they insisted I enable SMS a few hours ago.
I don't have any money in there, it just mediates broken payment interfaces (e.g. Patreon rejected all my payment cards, from multiple banks apparently they're all fraud or something? No idea, the cards remain working no problem everywhere else, but I wanted to give people money for what they do, so I used Paypal to manage that)
It's pretty sad that in 2020 PayPal thinks SMS is a reasonable choice for protecting accounts that might actually have money in them...
Thanks, I think it worked. At least they are no longer asking me to confirm the mobile number, although I can't seem to delete the unconfirmed number so who knows if there is still a way to use it to take over the account :(. Along the way I found a disturbing number of TOTP utilities that want you to pass the key on the command line :(. I found this one as a simple version that doesn't do that and uses OpenSSL or LibreSSL:
As someone who travels frequently and has moved to different countries, SMS is the absolute worst.
If a service asks me to verify my number after crossing a border, the chances of me ever being able to log into that account ever again are basically zero.
Then there's Google. Google doesn't have a phone number on file for me, but they sometimes demand that I input a phone number and enter a verification code to access my accounts. This has led to me needing to ask a total stranger to help me login to my accounts, potentially allowing them full access to all of my data in the name of "security." But hey, nobody ever said Google hires smart people.
I would recommend getting a cheap prepaid SIM card that doesn't expire quickly, and recharging it from time to time, just so you have a stable number for 2FA.
While I understand your desire not to, reality is what it is, and at some point, e.g. your bank may force you to give them a phone number.
This is a very niche case. Why can't you recieve sms abroad? Do you leave your phone behind when you travel? Why can't you give Google your current phone number?
Because my SIM card is useless the minute I'm outside of its recognized area.
> Why can't you give Google your current phone number?
Because my phone number is useless the minute I'm outside of its recognized area.
My old bank accounts have my old phone number on record. It hasn't been my phone number in 6 years and they don't accept phone numbers from my current country.
I'm not going to give Google my current phone number, because if it changes again, I'll be locked out of those accounts forever should I move or change numbers again. As it is, I can still login while having someone lend me a phone and making my account completely insecure.
Two tokens is just what it costs to use secure MFA. Ideally three - store one at EG your parents house so you aren’t losing access if your home is inaccessible.
> 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.
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.
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.
> 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.
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.
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.
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.
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).
> 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.
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.
Microsofts Authenticator App allows backups of the MFA secrets on iOS at least. As far as I understood, it does the backup of the secrets to iCloud and requires a separate microsoft account (o365 won't do) to store an encryption key. So an attacker would need to breach both accounts.
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
I think it's not so clear. If someone tells me "I can't authenticate, and so I'm locked out of my account", that sounds like his fault. If someone tells me "I can't authenticate, and they'll let me into my account, but only if I pay them money", then that sounds like their fault. I do carefully say sounds—I recognise the underlying tech is the same in both cases; but the nature of publicity is to attach much more about appearance than to technical facts.
They 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.
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.
Sorry, wrote that and then went offline for a couple of days. Perhaps it's my own cynicism about corporate engagement coming through, and that may be unfair given how open GitLab is as a company -- but the sentence beneath that heading just says "we're accepting community feedback, write your thoughts over here".
I guess the core of my (admittedly petty) complaint about the language is that it doesn't really indicate a willingness to listen, more than it steers people towards a box in the corner they can vent into. A bit of language along the lines of "we think this is the right decision, but we're willing to reconsider" would maybe come off as more considerate, I guess?
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".
Seems to me like it actually makes not having MFA even riskier, as if you fail to have it, someone pwns you, and then adds MFA to your account, it's literally a dead end to you.
Isn't this why almost every site with 2FA support asks you to print out backup codes and keep them somewhere safe, and warns you that you won't be able to recover your account if you lose them? I thought this was standard practice. I'm surprised it seems to be so controversial.
Why not introduce a model where one who has lost their MFA keys pays something like, say, 50 $ to make up for the time the support team spends on the ticket?
Such a decision is something that would make me either leave the service, not trust it with anything important or not enable MFA.
(Side note, this is also valid for Google, Twitter, Facebook, AWS and other services that take pride in letting AI manage everything with no avenue of contacting a human with authority to override the AI)
This makes sense. If it bugs you, just upgrade to a paid account. Being able to manually verify your identity in case of emergency is a real service and worth paying money for.
If you mostly use a desktop or laptop, purchase two different FIDO authenticators that match the form factor you need.
If purchasing a new laptop (or having one purchased for you) and you run Windows or Mac OS consider fingerprint devices that can turn it into a "Platform Authenticator" able to prove that the person with the authorised fingerprint and the machine authorised are together and wish to sign in.
If you mostly use a phone, look for a newer iPhone or for select Androids (e.g. Google's "Pixel" series) with fingerprint readers, again these function as a platform authenticator.
Unfortunately for the latter case U2F isn't an option. Sites should be migrating to WebAuthn (and please people do not implement U2F instead of WebAuthn in 2020, for the same reason you wouldn't build a new Flash video site, nothing new supports that technology any more, stop it)
Today GitLab is U2F only, there is a logical upgrade path to WebAuthn, and they seem to be working through a bunch of patches to land it, but for now it's less compatible with a site with WebAuthn (e.g. GitHub). So that means if you use the site largely or exclusively from a phone hardware tokens do not buy you much yet.
Sites should be migrating to WebAuthn (and please people do not implement U2F instead of WebAuthn in 2020, for the same reason you wouldn't build a new Flash video site, nothing new supports that technology any more, stop it)
I think this is terrible advice because WebAuthn isn't supported by Linux browsers and I still want to be able to login to services on the internet.
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.
The anti-fingerprinting in Firefox will flag that first site you linked.
The site is asking your FIDO Authenticator to provide "attestation". In theory this could be useful to require users to pick a high quality authenticator. It might make sense, for example for Big Bank to require customers use an authenticator Big Bank bought in bulk with Big Bank branding, because they trust it.
But, although countermeasures against tracking were incorporated in the FIDO design for attestation, it is unavoidably a potential privacy risk and so Firefox decided to flag it. Sites which try to ask for attestation during registration get a "Fingerprint" icon in newer Firefox versions. Click the fingerprint and opt either to press on anyway or to Anonymise the authentication (essentially pretend your device hasn't got any attestation) on this site.
For a site owner: Do not do attestation just because it seems cool and worked in Edge or whatever. If you don't need this sensitive information do not request it. You need to work out a policy, which authenticators are OK and which aren't - if that seems like too much then don't do attestation. If the answer is "actually any authenticator seems good" then don't do attestation. If you allow users to just not have an authenticator (100% of general purpose web sites today) then don't do attestation for those who want one. If you are throwing the data away because you have no idea how to process it don't do attestation.
This is the right move. Get two u2f keys. Keep one on your person on your keys, keep the other in your car, at your parent's, or in a safe deposit box depending on your personal threat surface.
Side note - the SSH-based recovery mechanism is great and delightful. I happened to need a reset for salsa.debian.org and it saved me from bugging Debian's GitLab folks for support.
I wonder if services like Git..b would ever enable MFA based on ssh. That is, configure their endpoint to require both the key and the password to log in, push or fetch.
It'd be about as secure as writing down a password or using a password manager.
Note that it would be a password, not multi-factor authentication. These days, really, the important part isn't so much "something you know" vs. "something you have," it's the nature of how the credentials work.
A password is sort of a one-way credential, something that serves by itself to authenticate you (or whoever is in possession of it). Anyone who holds the password can authenticate until it's changed. You should pick a long password, something that it hard for others to guess.
A phone number (SMS or phone call) requires an active cell network connection. This is spoofable/interceptable/SIM-jackable, but for the most part, it retains the important property that at the time you log in, the site makes a request to your device to confirm the login. Things like Duo Push is a less attackable version of this mechanism. In both cases that makes it harder to use stolen credentials if "stolen" simply means 'digitally copied" - they'd need some way of disabling the actual physical device in your possession, too.
A code generator doesn't require an network connection, but it's still active unlike passwords: it changes every 30-60 seconds. That means a code that logs you in now can't actually log you in forever, so someone who happens to intercept a particular login request (say, someone who watches you type) can't come back and log in later. They'd need the long-term secret which isn't ordinarily revealed by the app except during backups. Things like RSA hardware tokens are less attackable versions of this mechanism. An SSH key also falls in this category - logging in with the SSH key doesn't reveal the entire key, the way logging in with a password does.
A security key (U2F/FIDO/WebAuthn) is active like a code generator, but it also verifies the website that's requesting the credential. If someone tricks you into visiting gitIab.com (with a capital I), your browser will send that domain name to the security key, which will not respond with your actual gitlab.com credentials. A password manager with a browser extension is a weaker form of this mechanism - there are a lot more avenues to attack, but fundamentally none of the above mechanisms attempt to be resistant to phishing / social-engineering attacks.
So, sure, you could use a large QR code as a password, but that doesn't get you the protections against attacks that the other MFA mechanisms do. It's well worth setting up MFA on important accounts even if you are using a long and unique password, because it protects you from attacks other than password-guessing.
In most of these designs the Relying Party (a web site in these cases) has to store secrets and we know bad guys steal secrets and the site won't always find about it immediately or sometimes at all.
For a password we somewhat mitigate this using password hashing. If the site uses a halfway decent password hash and you use a halfway decent truly random password then this is enough to protect both of you. But if you use a bad password or the site does a less than great job protecting it then game over.
For SMS the site stores your phone number (not terrible but not great for bad guys to learn) and maybe a temporary code (bad guys may be able to use this by learning it before you do but that's typically a small time window)
But for TOTP and similar "One time" codes the site stores the generator value. Bad guys who have this value can make any number of fresh codes at any time.
What jumps out here for WebAuthn is that the site stores nothing of value. A random-looking identifier that's useless for anyone other than the Relying Party, and a Public Key that's useless for anything at all other than confirming signatures made with the corresponding Private Key.
I've published the actual database contents for some of my own WebAuthn credentials on HN before, because they don't matter, unlike even an Argon2id password hash they are designed to be utterly useless to bad guys.
That's a huge benefit because there are fewer people trying to break in because what you have ain't worth stealing any more.
I think this is interesting in that the correct response as a user is to literally maintain a backup mirror gitlab account in case you lose access to your original one. What a bizarre change from a SaaS company who’s value proposition is to make things easier than doing them yourself.
This is a terrible idea which encourages people to use weak security: it's effectively telling people that if they enable MFA, GitLab will ensure that they suffer irrecoverable damages — but if they don't enable MFA, everything is recoverable. That is the opposite of what we want from a security perspective and it risks causing users to be less secure everywhere else because having seen that message will make them question whether they'll regret enabling MFA even on sites which have good security policies.
GitLab should respect the trust that users place in it and account account for the kind of life events which happen to people every day: houses get flooded or burned, safes are burgled, people have to leave abusive situations in a hurry and may be escaping household members who actively try to sabotage them, people die without having made perfect handover plans (especially relevant this year), etc. Of particular interest, consider why the browser manufacturers reversed course on HTTPS key pinning after seeing attackers successfully use it to prevent legitimate users from regaining control — if implemented, this would make it extremely risky to use GitLab because everyone would be one compromise away from an attacker having permanent control of your account — and that would make GitLab look extremely bad for having put themselves in the position of supporting the attacker _unless_ you pay GitLab money (I am certain this is not the _intention_ but it is definitely how it would look to say that FOSS developers are second-class).
There are a number of fallback techniques which can make most of those situations recoverable, and it's okay if they're slow or inconvenient — nobody complains that their airbags are messy. Some ideas:
1. Have a process where someone can use a trusted third-party to verify identity: for example, register identifiers (drivers license, passport, etc.) and have a form which can be notarized after checking ID and mailed in. It's slow but that works even in the “I lost everything I wasn't wearing” scenario — and if you did just lose your house to a natural disaster or flee an abusive ex, you probably have bigger concerns than getting control of your GitLab identity back in less than a week.
2. Configure next-of-kin / trusted friends who can approve a reset request, perhaps requiring more than one.
3. Allow the user to configure some number of IdPs to approve an unlock, increasing the level of compromise that an attacker would need to hit before getting the ability to perform a reset. There are drawbacks to this approach but most people do not have threat models which are meaningfully resistant against someone who can compromise multiple of {Apple, Google, Facebook, Microsoft, login.gov, etc.} and could be pretty effective combined with a time-delay (e.g. send notifications for n days before actually resetting MFA.
I'm on the community advocates team at GitLab and we really appreciate your feedback. I wanted to point out that our team responded to your post on the GitLab forum, you can see the response here: https://forum.gitlab.com/t/gitlab-support-is-no-longer-proce...
Thanks — I've been replying there but figured I should comment here since this is where I first saw it. I definitely hope this leads to some UX work, especially through the lens of thinking about how badly it will fail for vulnerable users.
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.
> 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.
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 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.
Is it cause you think China or some hacker gives a shit about you?
Newsflash you are no one to most people. Your actions matter to no one but yourself and the people close to you.
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