201–210 of 228 posts
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.
That does somewhat presuppose access to a printer.
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…
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…
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.
Earlier quoted context omitted.
Support Manager for GitLab here. I appreciate this feedback, and you're right. We don't want folks to get themselves in a position where they lose access. Our current language when you enable MFA is here: https://gitlab.com/gitlab-org/gitlab/-/blob/adc7dbeb387adc69... > Should you ever lose your phone or access to your one time password secret, each of these recovery codes can be used one time each to regain access t…
I made this post on the forums: https://forum.gitlab.com/t/gitlab-support-is-no-longer-proce... In summary: Please consider some kind of exemption for non-commercial open source projects over a certain size. This change would force me to choose between unacceptable risk to my users, or severe impact on my hobby/life balance and mental health due to the extreme personal responsibility I would have to take to mitigate…
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 qu…
Earlier quoted context omitted.
Don’t lose your recovery codes and you should be fine, right?
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.
Earlier quoted context omitted.
If I lose all the keys to my car or they are destroyed, I can pay a dealership to create new ones for me, I don't just have to forfeit the car.
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?
For important accounts I wonder if we should have the ability to tie them to a physical address or something else possible to verify.
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.
damn, that's a tall horse!
Earlier quoted context omitted.
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.
...Neither my work nor personal laptops have a fingerprint sensor.
Earlier quoted context omitted.
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.
What happens if your phone gets crushed by a runaway elephant?
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.