Raising the bar for software security: next steps for GitHub.com 2FA

by johnnyapolon 12/14/22, 5:18 PMwith 4 comments
by knaik94on 12/15/22, 5:26 AM

I am very happy about Github's clear and upfront 2FA policy to rely on TOTP and only allow passkeys as a secondary method. This feels like the most reasonable way to manage logins and security moving forward.

I am not sure where friction exists for an audience of, presumably, tech literate people deploying TOTP 2FA. I understand the concern in a more diverse group, but I'd assume developers have a better understanding of security.

I can understand reservations about using a non open source service, but with apps like Aegis on Android and Ravio OTP on iOS. I have an encrypted backup of my secrets synced from my Android phone to Dropbox and Google severs. The encryption is based on a password I chose. I lost my device and restoring my 2FA was as smooth as I expected.

I am very annoyed by Google constant push to try to get me to start using my phone like a WebAuthn passkey and it's pushing me further and further from the technology. I don't believe security exists if I don't control my secrets. I hope they shift their approach to the same as what Github's currently is. Google nags users to login with the passkey every once in a while if it's registered, regardless of what primary 2FA you want to use.

"Authentication with a security key is secondary to authentication with a TOTP application or a text message. If you lose your security key, you'll still be able to use your phone's code to sign in."

https://docs.github.com/en/authentication/securing-your-acco...

by grifficiouson 12/15/22, 4:46 AM

https://www.microsoft.com/en-us/research/publication/so-long... was an interesting paper by Microsoft on the rational rejection of security advice by users, on the basis that the costs outweigh the risk.

How much does this raise the bar of software security, and what are the costs?

User effort isn't free.