4 ms·
> What's wrong with adding a simple challenge-response protocol for FIDO2/U2F USB drives? Or a TOTP popup if you don't have a physical security key? Infrastruc
by 0x457 4y ago
> What's wrong with adding a simple challenge-response protocol for FIDO2/U2F USB drives? Or a TOTP popup if you don't have a physical security key?
Infrastructure to handle authentication on the web already exists. This is a massive benefit for providers and client developers. Whatever you propose does not. Good luck convincing big email providers to agree on a new standard like that.
GitHub alone has like 5 different ways to handle 2FA. Google has, I think, 3? Using a browser to handle this simplifies things a lot.
b) While it's not fixed by Oauth it greatly limits what can happen:
— First, you only need to store a refresh token that can expire and that expiration can be controlled by administrator
— Second, that token has limited scope: password provides access to entire account
— Third, it's clear where it came from — if token gets compromised, you will know where it happened. With password, it's unclear.
- jsnell 4y ago> Google has, I think, 3? There's at least: 1. SMS 2. TOTP 3. Google Prompt (on Android / iOS) 4. Offline security codes (distinct thing from TOTP, generated from Android settings) 5. Backup codes 6. Security Key
- magicalhippo 4y agoDo you have some documentation for this? All I could find[1] pointed to them only supporting OAuth, similar to Microsoft. [1]: https://developers.google.com/gmail/imap/imap-smtp https://developers.google.com/gmail/imap/imap-smtp
- jsnell 4y agoI didn't mean that they had native IMAP support for those, but that these are the 2FA methods they support in general. With browser-based OAuth, it's viable to build support for a new 2FA method in just one place. Needing to build each of these into a protocol + get all popular IMAP clients to implement that support? It'd take an eternity; we'd probably still be stuck on just TOTP.
- magicalhippo 4y agoAh yes, my misunderstanding. Indeed, OAuth makes it easy to swap out the actual authentication step. Which is nice, because the service shouldn't really care about that, only that the user is authenticated and authorized.
- 0x457 4y agoThe security Key could also be a Bluetooth-enabled security key or pixel phone.
- Karellen 4y ago> Infrastructure to handle authentication on the web already exists. Email does not run over the web, it runs over the internet. It uses a completely different set of protocols from the web, which were all invented at least 5 years before the first web protocol. Why should email clients be required to add HTTP support in order to make email work? Maybe we should take heed of Zawinski's Law, and make all web browsers implement native email clients instead. Yeah, that's probably it. The Netscape Communicator/Mozilla Suite model should never have been dropped, and it was a mistake to separate Firefox and Thunderbird as separate projects! /s
- 0x457 4y agoWell, because it already exists? All email clients need to do: - Open a link in a browser (don't you dare open it in an embedded browser, I will find you and force you to type 100 characters as I dictate it to you) - Handle callback. That's all. That's the entire authentication. There is probably not a single platform (language and maybe a framework) that is used to build an email client and has no library to handle this with a few lines of code. I think that's a much better and easier solution than make developers of email clients handle the very possible authentication method email providers could come up with (see reply to my comment about 2FA with Google). Also, old opera with torrent client, calendar, compressing proxy, email client was the best.