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.
> 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.
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).
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.
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.
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.
> 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'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.
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".
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?
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.
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.
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.
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.
> 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?
> 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
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.
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.
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)
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
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.
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.
> 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.
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)
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.
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.
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.
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.
> . 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.
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.
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.
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.
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)
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.
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.
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.
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
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.
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.
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?
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.
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.
227 comments
[ 0.16 ms ] story [ 916 ms ] threadThis 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.
Yes, and Crypto exchanges are a paid product so they would be able to provide this additional support.
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).
I’m not aware of any way to validate this that doesn’t open the door to various trivial degrees of attack.
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.
They also do support multiple FIDO2 tokens as well as recovery codes.
Google Authenticator prevents the MFA shared secrets from syncing to iCloud and it also prevents said shared secrets from being restorable from local backup to any device aside from the device where the secret was originally put into Google Authenticator [1].
What Google Authenticator does is good for security but not so great for the experience of switching phones.
The first time I came across this was a few years ago, when for the first time after beginning to use Google Authenticator I had bought a new phone, and I had factory reset my old phone and was restoring the local backup of it to a new phone. At the time, when I saw that Google Authenticator was empty on the new phone I freaked out a little bit and I also did not realise that I would be able to restore them on the old phone still because I assumed that them not being on the new phone meant that they were not included in the backup at all. So I went through account recovery for all of the accounts that I had MFA enabled on and it was a bit of a drag but at least all of them allowed me to use my e-mail or phone number in order to regain access so I was not permanently locked out of any of my accounts.
When I set up MFA again on the accounts, I stored screenshots of the QR codes for each of them all together in a directory on an external, encrypted drive.
Still though, when I replace old hardware with new hardware those QR codes can become difficult to find back to. And keeping the files on an external drive at home also means that if I lose my phone while I am traveling then I can't access the QR codes that I saved until I get back home.
So currently I have decided that at the very least my app will allow me to retrieve the original MFA shared secrets from within it when the phone is unlocked (PIN code) and user presence is confirmed. In other words; kSecAttrAccessibleWhenUnlockedThisDeviceOnly, .userPresence [2] [3]
Doing as I suggest in the above paragraph will at least make it simple to set up the MFA on a new device as long as I still have the old device in hand, without having to go through each account and disabling and re-enabling MFA in order to get new shared secrets for each of them.
So far I consider the security of my MFA to be equivalent to that of not having export functionality built in. If my device is lost or stolen, the data would still remain as well guarded as they were.
Beyond that I am thinking about even compromising on the security a bit by allowing the TOTP shared secrets in the keychain to be synchronised to iCloud. But I am still a bit on the fence about that one. I have misplaced my phone in the past, and I've caused accidentally damage to it as well when it has slipped out of my hand. So there is a plausible risk that I might lose or accidentally destroy my phone while traveling. Then again, when I travel I also bring with me my MacBook Air.
So instead of syncing the TOTP to iCloud, I could make a macOS version of the TOTP app and have it function in the same way that it would on the phone in terms of requiring that my machine is unlocked and presence is confirmed and then allowing the TOTP shared secrets to be seen. And whenever I add a TOTP shared secret, I do so on both my computer and my phone (either at the same time or one first and then later the other).
If I was on a trip and I lost or accidentally destroyed both my phone and my computer at the same time, I would certainly be returning home early anyway. And if on top of that my home had burned to the ground while I was away, so that the external drive at home was gone too, well, I think that then the TOTP stuff would be the least of my concerns anyways. Probably.
So I think I've figured out the answer to what my app should do. iCloud no, show secrets when unlocked and presence confirmed yes.
[1]: <...
We did use to do identity card verification. The issue that we had was that we often didn't have a lot of information about the folks who opened free accounts.
Often names would be pseudonyms or match only partially with their ID. Not to mention, of course, the difficulty of verifying the authenticity of IDs from all over the world.
We wrote about this back in 2018: https://about.gitlab.com/blog/2018/10/08/enforcing-managing-...
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 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.
> 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.
Does GitLab make any money at all on free users, or are they just a loss leader?
Note that paid GitLab users aren't losing the recovery option, only free ones.
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.
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".
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.
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?
I appreciate this feedback, and you're right. We don't want folks to get themselves in a position where they lose access.
Our current language when you enable MFA is here: https://gitlab.com/gitlab-org/gitlab/-/blob/adc7dbeb387adc69...
> Should you ever lose your phone or access to your one time password secret, each of these recovery codes can be used one time each to regain access to your account. Please save them in a safe place, or you will lose access to your account.
We're directly emailing our most at risk users and are still processing resets in the mean time. Additionally, many users will see a CTA banner reminding them to regenerate their recovery codes if they haven't recently.
If there's anything else we can do - I'm happy to hear it! I've had to rely on recovery services in the past because of pure bad luck and a move to a new country, so we didn't take this decision lightly.
In summary:
Please consider some kind of exemption for non-commercial open source projects over a certain size.
This change would force me to choose between unacceptable risk to my users, or severe impact on my hobby/life balance and mental health due to the extreme personal responsibility I would have to take to mitigate it.
It's already terrifying enough to publish applications that users run on their systems. If I make an error I can cause all sorts of harm. But at least I only have to worry about that when developing.
Now, if I enable MFA, I can never relax. If I lose my work MFA, there's a perfectly safe process to recover. If i lose my personal MFA it's a few hours of calling banks. If I lose my GitLab MFA I harm hundreds of people. So, I have to permanently vigilant for something I already give so much to for free.
If anything takes out both me and my bank, it’s taken out the whole city so I have more to worry about than just 2FA.
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.
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 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...
https://github.com/arachsys/totp
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.
- Why can't you recieve sms abroad?
Because I use e-sims and pay $10 for 30 days of data only vs. the $30 my provider would add to my bill for "global data".
> Do you leave your phone behind when you travel?
No, but I do leave my US number "dormant" in that i can't use it.
> Why can't you give Google your current phone number?
Because they already have a clear enough data picture of who i am, and I don't want them to have any more data that I'm willingly giving them.
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.
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.
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?
Fallback to SMS auth if you've lost your MFA and recovery codes. It's not good per se, but the users who need it will love you and the users who get SIM jacked/swap attacked will hate you. You're not going to please everyone. I've been trying to figure out a good way to handle this, but at least in the US, there isn't a good government provided identity provider you could rely on to true up identity issues when auth factors are lost (login.gov just ain't there yet, but it might get there as it's what US DHS uses to auth you for Global Entry, and what you're looking for is essentially a programatic/digital notary to attest to you that the person is whom they say they are).
IAM is hard.
I looked at GitLab's recovery options, and you have the option of recovering your MFA if you have access to any SSH key used to publish to GitLab. That seems like a reasonable backup for now.
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.
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".
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.
With free users you also have less information available to you as a provider in determining if the reset request is legit or not.
Support cost is a valid consideration but it's something they could address using payment infrastructure they already have: require someone to pay $20 to get a reset, with a delay period where the account is frozen but before the MFA reset goes into place.
Yet.
Microsoft owns GitHub, not GitLab. This article is about GitLab.
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.
Extra classy! Thanks.
Otherwise, with no path forward, this is just user hostile.
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.
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.
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.
https://demo.yubico.com/webauthn
Is this a problem with the backend rather the browser?
Edit: This site works https://webauthn.io/ My mistake!
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.
The Yubikeys do more than just U2F, they also support storing 32 TOTP codes, PGP keys, and other things.
I like the Nano versions as I can leave them connected to my PC at all times.
Recommend an NFC one that you can have on your keyring as it can then be used with your phone.
In reality though almost any U2F token is all you need, and they can be purchased for about $20.
I wish conpanies offered this as a feature, in the sense I'm much more worried about someone SEing their way into my account rather than me losing access to all my MFA methods and backup codes or whatever.
Github has the same policy, and it deterred me from using MFA for a long time, and when I finally did, I added a large number of alternatives, including the not-so-secure SMS.
I think the fear of being temporarily unable to access your account is already a major reason why people don't use MFA. Turning the threat into a permanent loss will make people even more reluctant to do it.
Dealing with some of the backup methods (e.g. off-site copies of backup codes) is tedious, and I wouldn't be willing to do it for less important sites. If I had 2FA on Gitlab, I'd probably turn it off now. (Actually, just saw they don't have an option to add a phone number - I'd definitely turn it off.)
I may have misread the announcement, but it sounds like upgrading to a paid account recovers (npi) the ability to recover your account.
Or rather, at least as straightforward as the process is meant to be for existing paid-up customers, as per TFA.
They were willing to help me - took a week but I got my account back
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
As far as cloud storage goes, standard notes might be a good option, I don't use it for 2FA, but it's an extension they provide.
https://github.com/krisu5/aegis-icons
Just extract the zip, and you can input any photo to the Aegis app
I keep my keys in analog form - I print QR code for every service. We know how to handle valuables stored on paper.
The app puts a no screenshot request, so you have to scan the qr code from another phone.
Without it, he has 30 seconds to login and put the code by just opening the app and looking at the code.
Not much of a feature, but might help some users
* when setting up 2FA, a website shows a QR code
* I screenshot the QR code, and print it out on an A4 sheet, with an annotation of what service it is for
* I scan the QR code from the A4 sheet on two different phones.
* Back on the website, I continue 2FA setup process only after the A4 sheet is printed, and both phones show the same codes
* The A4 sheet goes in a folder for safe keeping
* One phone goes in my desk drawer for daily use
* The other phone goes in my "go" bag that I take with me on short trips etc.
Both phones are used exclusively for Google Authenticator:
* they have no extra apps
* they have a screen lock
* they are always in flight mode
Started doing this when I got burned by having to extract GA's sqlite file from mostly-dead Nexus One over adb.
You can store the TOTP seeds in more compact form by converting QR code screenshots to alphanumeric using zbar barcode tools.
In my experience it has difficulty parsing some QR codes created using CSS due to tiny borders between blocks. Those can be fixed by applying a small gaussian blur followed by sharpening (use imagemagick for maximum automation) to fill out the borders.
Edit: packages available in Ubuntu (zbar-tools) & Fedora (zbar), source code at https://github.com/mchehab/zbar
I'm saying this as I'm looking at my 1Password database which also contains all my 2FA keys because, yes, all 2FA apps I tried so far treat these keys as way too valuable and the risk of losing them as I move from device to device is just too high.
Do as I say, not as I do I guess :p
I feel confident to rely on the security of my machine and 1Password specifically, though I am aware that I can't really claim my accounts to be secured by 2FA.
> If you would like to turn a site’s offering of TOTP into true two-factor security, you should not store your TOTP secret in 1Password (or in anything that will synchronize across systems).
They mention multiple times that if you want true 2FA the second factor needs to be on a different device or a physical key like a YubiKey.
Then they say that “two-step” security offered by 1PW + 2FA is probably enough for most use cases, and that 2FA in 1PW still has additional value because (a) some sites require 2FA and (b) one-time passwords offer protection against sniffing passwords over insecure networks.
https://blog.1password.com/totp-for-1password-users/
The fact that 1PW even auto-copies the code to your clipboard after auto-filling a password so that you can paste it in when prompted raised my eyebrows when I first used the feature, though. It's very convenient but it's obvious at that point that you're throwing away the protection that storing the key on a second device would offer, even if 1PW requires you to authenticate before the app will open.
When I set up TOTP on a site, I save the QR code as a PNG file (via the Grab application on my Mac) and the text version of the code in a text file. (If the site provided some one-time use recovery codes, those all go in the text file). Those two files go into a directory, that directory gets made into a tarball, which then gets encrypted, then stored in my "recovery" directory which later gets saved in an encrypted backup.
That's all after I scan the QR code into an authenticator app on my phone.
Moving codes to a new device is then just a matter of decrypting and extracting them from my recovery directory and scanning them on the new device.
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.
I would argue that this is a negative thing. Sites should at least give the option to disable password reset.
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)
Password reset email is great if you forgot your password, but this just means you can't make it more secure than your email account.
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.
For important accounts I wonder if we should have the ability to tie them to a physical address or something else possible to verify.
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.
Having only one copy of the MFA device is of course a bad idea.
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.
The post I responded to basically did:
> 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
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.
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.
Can you explain any solution for any problem that is reasonable for ALL of the billion+ people that login to some kind of cloud service? ;)
Where do you get free groceries, fee petrol/gas or anything else?
How secure would it be to use a QR code as a password, and scan it with a phone camera?
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.
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)
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.
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.
The only correct response to this is for companies to make it against internal policy for developers to enable 2FA. Which is sad.
[0] “What if this is a work account?“ FAQ header in OP
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.
Why did you try to make this personal by attempting to insult me?
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?
damn, that's a tall horse!