Raising the bar for software security: next steps for GitHub.com 2FA | Hacker News Reader

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

github.blog

27 pointsjohnnyapol4 comments

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...

As far as friction, I would like to see email 2FA if they deem SMS 2FA sufficiently secure.

But really, there should be a way to recover your account if you “lose” everything except what’s stored in your head.

The health service application my doctors use, MyChart powered by Epic has that functionality. I get the option of using SMS or email, and I think they allow email because it's information the doctor's office confirms when I visit. I can imagine 2FA being approved for emails, but only for providers that have proper 2FA for email login. Otherwise it's just pushing the problem to a different place. Maybe email 2FA isn't used because email that doesn't enforce it for email login can't be assume to have it.

I don't think there's a way to allow recovery based on only information because then recovery become the primary method to take control of your account. Once you start adding limits to recovery attempts, you end up back where we already were before 2FA become popular. And what's stored in your head becomes a very easy target, especially for those less tech literate.

I really liked Facebook's idea of trusted contacts based recovery. It would allow a complete true loss of everything based on who and what you know and doesn't rely on a company having any information other than who your friends are. Which Facebook already knew since you were friends with them. Facebook's single identity model made that easy but for Gmail or Instagram it's common to have multiple that you don't check often.

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.

Reply on news.ycombinator.com