161–170 of 228 posts
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.
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.
Earlier quoted context omitted.
yes, i agree completely. 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.
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.
Earlier quoted context omitted.
> 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 l…
yes, i agree completely. 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.
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.
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.
Earlier quoted context omitted.
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 selec…
As per the post, this policy change only affects free users (so, users who aren’t using a credit card to pay GitLab). They also do support multiple FIDO2 tokens as well as recovery codes.
GitLab should respect the trust that users place in it and account account for the kind of life events which happen to people every day: houses get flooded or burned, safes are burgled, people have to leave abusive situations in a hurry and may be escaping household members who actively try to sabotage them, people die without having made perfect handover plans (especially relevant this year), etc. Of particular interest, consider why the browser manufacturers reversed course on HTTPS key pinning after seeing attackers successfully use it to prevent legitimate users from regaining control — if implemented, this would make it extremely risky to use GitLab because everyone would be one compromise away from an attacker having permanent control of your account — and that would make GitLab look extremely bad for having put themselves in the position of supporting the attacker _unless_ you pay GitLab money (I am certain this is not the _intention_ but it is definitely how it would look to say that FOSS developers are second-class).
There are a number of fallback techniques which can make most of those situations recoverable, and it's okay if they're slow or inconvenient — nobody complains that their airbags are messy. Some ideas:
1. Have a process where someone can use a trusted third-party to verify identity: for example, register identifiers (drivers license, passport, etc.) and have a form which can be notarized after checking ID and mailed in. It's slow but that works even in the “I lost everything I wasn't wearing” scenario — and if you did just lose your house to a natural disaster or flee an abusive ex, you probably have bigger concerns than getting control of your GitLab identity back in less than a week.
2. Configure next-of-kin / trusted friends who can approve a reset request, perhaps requiring more than one.
3. Allow the user to configure some number of IdPs to approve an unlock, increasing the level of compromise that an attacker would need to hit before getting the ability to perform a reset. There are drawbacks to this approach but most people do not have threat models which are meaningfully resistant against someone who can compromise multiple of {Apple, Google, Facebook, Microsoft, login.gov, etc.} and could be pretty effective combined with a time-delay (e.g. send notifications for n days before actually resetting MFA.