5 ms·
I agree that the assumption of email is problematic. I would love to hear some constructive suggestions for alternatives to email as a token delivery channel. T
by stanleydrew 13y ago
I agree that the assumption of email is problematic. I would love to hear some constructive suggestions for alternatives to email as a token delivery channel. The reality is that password reset already runs over email, so we are already in pretty deep.
1. It isn't that inconvenient once you get used to it. I've been setting a completely random password for all services and not storing it anywhere for awhile now. I do password reset every time. It's a small price to pay.
2. Again we should not assume email. What are some alternatives? Are there none?
- tptacek 13y agoYou mean, like 2-factor authentication? I like 2FA. Use a TOTP/HOTP scheme, for instance.
- stanleydrew 13y agoI love 2FA as well, and always set it up when I can. But if you are going to argue that it is "tremendously inconvenient" to have users fetch a token from email or some other channel, I don't see how 2FA does any better. The argument is that if you are not implementing full 2FA, at least implement your single factor as "something you have" rather than "something you know". Adding a password as an optional second factor instead of vice versa seems preferable to me.
- BWStearns 13y agoIt could be done as a desktop application or a browser extension. Reduce the password burden to one password and then generate keys for a PKI based on that (and maybe some other data to make it less guessable) If you sign up for something using this imaginary extension it would simply send your browser a token encrypted with your public key and your browser would decrypt it and would redirect to whatever.com/welcome/<gianttokenhere>. This would put the burden on the user not to accidentally trash their extension and lose their keys, but you could do key-reset the same way that we currently do with password resets.