So, they forced me to use 2FA, and I dutifully printed out the recovery codes (don't write down your passwords, that's bad practice, but here's 20 recovery codes that stand between you and losing your account forever, so you know, manage that somehow).
When I bought a new iPhone, apparently none of my stored information got copied over. The apps did, but none of the information for those apps (for example, the TOTP info maintained by the authenticator I used). So, I went to log in to Github, opened up my authenticator app, and it was blank.
Thankfully I had the codes...back at home, in a drawer, guarded by a cat, so I wasn't completely doomed, but it ruined the day to be sure until I could get home and recover it and recalibrate my TOTP app.
Oh, guess who has a photo of their recovery codes on their phone now?
I don't fw TOTP now. There are other apps, but I'm done. I'll only use it if the iPhone Keychain has built-in support some day.
When a QR code is present on screen that resolves to a TOTP seed, an additional context menu option should be present to "Add Verification Code in Passwords" or "Set Up Verification Code" or similar.
Here's a screenshot I nabbed from a way-too-wordy article on the subject: https://tidbits.com/uploads/2021/10/Add-Verification-Code-15...
0: https://apps.apple.com/us/app/2fa-authenticator-2fas/id12177...
Also, your Yubikey is probably less likely to be stolen or break, but I figure it's much easier to lose it, which is why you might want to have two, just in case. And that's where it gets really inconvenient.
Half the time I choose for TOTP authentication over Yubikey because "Oh god it's in the living room I don't want to go get it."
I do have a backup key mind, but that's USB-C instead of A. Maybe I should make another USB A backup.
On the other hand, you know the second one works and haven't spontaneously bitrotted.
My nerdy preferred version would have been (pre-passkey) to have a hardware token where the root secret is generated out-of-device and exist on e.g a paper backup or something. Then I could just buy a new hardware token and inject the same token if the device dies.
Even if I do have keys, they are safe in my pocket, not sticking out the side of a fragile USB port.
There's then the whole mobile problem -- yubikeys are perhaps fine with my laptop, but how about when I'm using a mobile and my laptop is in my bag, or at home?
And OK, lets say I solve all that. How do I add a second key?
The beauty of SMS for 2FA is that my phone number sticks with me. If my phone is lost or stolen, a new sim card is sent to my home and I have access to all my 2FA authenticaitons. It also ties in well with my phone -- if I get an SMS with a number 123456, it appears as an automatic insert option on the form, no need to go to another app to copy a number and switch back to paste.
TOTP and Yubikeys do not match the usability of SMS.
Even if I do have keys, they are safe in my pocket, not sticking out the side of a fragile USB port.
but how about when I'm using a mobile and my laptop is in my bag, or at home?
And OK, lets say I solve all that. How do I add a second key?
The beauty of SMS for 2FA is that my phone number sticks with me. If my phone is lost or stolen, a new sim card is sent to my home and I have access to all my 2FA authenticaitons.
I've done it in Aegis multiple times. They even allow you to export the 'database' (which iirc is just an encrypted json file)
If I ever want to set up a TOTP app on a new device it is not hard to decrypt all my saved QR codes, open them all at the same time in Preview on my Mac, select the option to show one page at a time, and then get into a nice rhythm using one hand to scan on the new device and the other to hit "page down" on the Mac keyboard.
If the site also gives a text form of the shared secret from the QR code I save that too. Having the text form around is handy in case I need to login but for some reason don't have the devices where I have the TOTP apps. Given the text form of the code, this command, from the oathtool package, will give the current login code:
$ oathtool --totp -b "secret"
If the site doesn't give a text form of the shared secret I read the QR code to get it. If you do that be careful. Some QR code reader apps do the processing server side which you probably don't want...and they don't necessarily make that clear in the description. I had to try a couple of apps from the Mac app store before finding one that did it client side. (Then I found out that Mathematica's BarcodeRecognize function can do it, and deleted the QR code reader app. Now I just open Mathematica, type BarcodeRecognize[], drag and drop an image file that has the QR code between the brackets, and hit shift-return).
Personally, I email the backup codes to myself. Yes it's less secure in theory, but the only time I'm using totp is against my will.
The QR code is on the screen of my desktop Mac. The camera is right above the screen facing me and can't see what is on the screen.
I could read it with the built in camera app on my iPhone or iPad, but that just tells me it is a QR code for the TOTP authenticator app I use and opens that if I tap. I don't see a way to get it to tell me the content of the QR code in text form. Even if it had a way that would be on the phone and I want the text to save it on the Mac.
Same reason Microsoft forces Windows updates so aggressively - because if some kind of security breach makes the news, even if it's clearly due to poor user choices (poor password choices and/or security; repeatedly opting out of critical security updates), it's always the vendor/service provider that looks bad.
Because your hobby-project can emerge to be the backbone of someone's multibillion dollar-business, or a small gear in a million other projects, and you will get targeted for a supply-chain-attack.
Forcing everyone to raise their security and gain awareness about those things is a huge win for everyone, and only a little problem for the individual user. And it seems to be only a phase anyway, as most people & services are moving to more comfortable solutions over time.
Or they can use hobbyist-written software for free, which is just fine, but don’t expect the hobbyist to support it for free.
By the users of the software I publish noticing the license that states that while I hope this software is useful to them, it is provided with `"NO WARRANTY, NOT EVEN FOR FITNESS OF PURPOSE" and planning accordingly.
If you're an entity that wants to ensure that software you use from a source that you have approximately zero power over (and has explicitly provided NO warranty for that software) is and continues to be fit for purpose, you're going to have to inspect that software at a point in time, determine if it is fit for your purposes, and carefully inspect every future version of that software that you're considering using.
There really are no shortcuts. Requiring one to drink a Confirmation Can to log in doesn't change the math here.
Fork and change the readme to reflect that this version is hardened for big business.
Turning providing source code into promising you'll follow other's desires on how it should be worked on is a recipe for disaster while simultaneously not really making hobby projects low risk to rely on anyways.
The only thing that can compete with password managers on user experience is just actually remembering they're logged in instead of pointlessly logging them out every single day for no reason.
Passkeys will be faster.
Seems to me, and I may not understand it, but it seems to me that Passkeys are more of a way to eliminate having to constantly re-enter you password, but do not eliminate passwords.
For example, if I set up a Passkey, that's bound to a specific machine/browser/phones/whatever. But if I log in from another device, there are no Passkeys, so I just need to use my password. If my lose my machine/browser/phone, I'm in the same boat -- new device, and I need to login. Thus the password.
I don't use any syncing system, I'm not on iCloud, or use apps, or anything like that, so there's no mechanic for distribution of passkeys. Plus that wouldn't work if I wanted to log from my friends laptop, or something like that.
Am I mistaken in how this works? How does enabling Passkeys eliminate 2FA?
My issues with 2FA aren't so much the 2FA part (yea, it's a pain in the neck, "one more step", etc., but, it is what it is). My issue is that if my 2FA is lost, and my recovery codes are lost, I'm toast. There's no other way to recover. No other mechanic, at least for Github.
iOS and Android can also just keep local Passkeys where you scan a QR code, though of course if you don't backup anything anywhere you will always have a redundancy problem with any 2FA mechanism.
Passkeys are supposed to not be a single authenticator either, so you can enroll another Phone or a Yubikey (or also your local TPM, binding to your user account, for convenience), but not all services support that in practice.
This way, free users are less likely to use github while paying corporations will stay.
In that case, presumably I could embed the totp key in a bookmarklet in the conveniently-sized 'public bio' field on my profile so I can complete it on whatever device I happen to be using, and effectively opt out?
But I'm really not convinced they aren't fuckwits and wouldn't treat the 'second factor' as an authoritative single factor in some circumstances (e.g. password reset) which wouldn't be unauthenticated if 2fa wasn't set up.
I'm also not convinced one can even contact anyone at GitHub clueful enough to answer that question authoritatively nowadays rather than reading off a script.
2FA increases risk of the account owner losing access to their account. There are a huge amount of posts online from people livid about getting locked out of their account because of some mundane reason like their phone breaking. That risk rarely seems to be considered by the crowd pushing 2FA everywhere and anywhere, probably because it happens most often to non-techies.
Things that seem easy or obvious to folks working in tech are often a huge hurdle for regular users, who make up the majority of users for many products. Many tech companies could do a much better job of considering the needs of their users, rather than building what the devs and product managers personally think is cool.
With my one not really as you still have to enter a simple password to do anything - six letters, no dumb requirements for capitals and odd symbols.
There is something to be said for simple passwords that people can actually remember. They don't work in situations where hackers can try loads of attempts electronically but where you have to type them if they are quite good really.
Not that long time ago there was a discussion about 23andMe data leak through user accounts that reused emails/passwords on some other compromised site. I was surprised how many people here argued that 23andMe should be responsible for this data breach because it's common knowledge that people reuse passwords all the time and yet 23ndMe didn't make 2FA mandatory until after the leak.
Personally I prefer to have a choice on whether 2FA should be enabled or not but I also understand companies that don't want to be blamed for something that is entirely user's fault so it's much easier for them to make 2FA mandatory, even though with phone apps it's not really 2FA since it's the same device.
Why do I need to activate mandatory 2FA in services like GitHub repositories for hobby projects? It's a lot of extra effort for a questionable security improvement, and anyway, if someone impersonates me there, it's not the end of the world. If they care about end users (which my projects mostly don't even have) mark me as "unverified" or something, but let me avoid the hassle.
And in more serious services, like banking... since there is no such thing about 100% security (and in particular 2FA is far from it, e.g. if your phone is stolen with the banking app open, you're screwed), actually the most important thing is that the bank responds and can refund the money if fraud is committed, which it inevitably will for some percentage of unlucky customers. I view 2FA as a way to pass responsability to the customer ("we have very secure systems, so if someone transferred $X out of your account it's surely your fault"). Personally, I feel safer with less security and the bank worrying about fraud than the other way around, so I don't think they're protecting me when they implement this kind of stuff.