2 ms·

> This step is commonly something like “enter the code in an email we just sent” when trying to login. Because email is insecure, and there is zero guarantee t

by crote 3y ago

> This step is commonly something like “enter the code in an email we just sent” when trying to login. Because email is insecure, and there is zero guarantee that your login email will arrive before the token expires. Your token does expire, right? > We are literally living through the gradual phase-out of third-party cookie. Yes, and a "remember this device" uses a first-party cookie, so it isn't affected. > My own browser erases all cookies from an origin immediately after the last tab from that origin is closed So you are intentionally breaking the web and complaining that things are cumbersome? Gee, I wonder why. > [..] yet that same website is happy to let me authenticate using an API key for API access as a single authentication step. No “2FA” here. Yes, because that API key is often used to sign the request, contains enough entropy to make guessing impossible, and because the URL is hardcoded in the app phishing is impossible. > guaranteed use of a high-entropy secret obviates the need for additional authentication No, it does not. See: phishing. Forcing the use of website-generated passwords is cute, but doing basic entropy checks on a user-provided password pretty much solves the issue anyways. Why bother alienating a significant fraction of your user base? Authentication is pretty much a solved problem. Use a password locker encrypted using a single remembered key for the "something you know" part, and use a physical Webauthn token for the "something you have" part. Stop trying to reinvent the wheel, it'll only end up annoying your users.

justsomeadvice0 3y ago
> doing basic entropy checks on a user-provided password pretty much solves the issue anyways. No it does not. Users will find one high-enough-entropy variant of their password, and reuse it across all sites for life. > Authentication is pretty much a solved problem Hrm. It might be solved for you and users like you - but it depends on your site's demographics: most internet users on the whole will not know anything about encrypted "password lockers" and "physical Webauthn tokens". Browser-managed passkeys, on the other hand, stand some chance of being easy enough to use while enforcing good security and high entropy secrets, but lack widespread adoption so far.
deleted 3y ago
[deleted]
ec109685 3y ago
The idea that email isn’t secure but is a key link in the registration and password reset flow always strikes me as odd. Passkeys can’t come soon enough, and email providers better make sure they are never compromised.
ghusto 3y ago
> Because email is insecure, and there is zero guarantee that your login email will arrive before the token expires. Your token does expire, right? That's a bit like saying laptops aren't secure. Well okay, laptops are not inherently secure, but my instance of laptop is secure (enough). Same with e-mail; there's nothing inherent in e-mail that would make it secure, but the way my e-mails have been set is secure (again, "enough" for practical reasons). >> My own browser erases all cookies from an origin immediately after the last tab from that origin is closed >So you are intentionally breaking the web and complaining that things are cumbersome? Gee, I wonder why. Clearing cookies isn't breaking the web. Some of your websites functionality may require things to happen again if I clear cookies, but a) that seems like a you problem, and b) doesn't seem broken to me. > Yes, because that API key is often used to sign the request, contains enough entropy to make guessing impossible, and because the URL is hardcoded in the app phishing is impossible. Not sure where you're seeing this "often", but most services I have API keys for work _exactly_ like passwords. I have to jump through a few hoops to get a working key, true, but once I have it, it's essentially a password, and used in the same way. > Authentication is pretty much a solved problem. Use a password locker encrypted using a single remembered key for the "something you know" part, and use a physical Webauthn token for the "something you have" part. Stop trying to reinvent the wheel, it'll only end up annoying your users. I don't feel like it's a solved problem if normal people refuse to do that. That's a solution in the same way that the advice "Everybody be nice to each other" is going to make the world a better place.

by crote 3y ago

justsomeadvice0 3y ago

> doing basic entropy checks on a user-provided password pretty much solves the issue anyways. No it does not. Users will find one high-enough-entropy variant of their password, and reuse it across all sites for life. > Authentication is pretty much a solved problem Hrm. It might be solved for you and users like you - but it depends on your site's demographics: most internet users on the whole will not know anything about encrypted "password lockers" and "physical Webauthn tokens". Browser-managed passkeys, on the other hand, stand some chance of being easy enough to use while enforcing good security and high entropy secrets, but lack widespread adoption so far.

deleted 3y ago

[deleted]

ec109685 3y ago

The idea that email isn’t secure but is a key link in the registration and password reset flow always strikes me as odd. Passkeys can’t come soon enough, and email providers better make sure they are never compromised.

ghusto 3y ago

> Because email is insecure, and there is zero guarantee that your login email will arrive before the token expires. Your token does expire, right? That's a bit like saying laptops aren't secure. Well okay, laptops are not inherently secure, but my instance of laptop is secure (enough). Same with e-mail; there's nothing inherent in e-mail that would make it secure, but the way my e-mails have been set is secure (again, "enough" for practical reasons). >> My own browser erases all cookies from an origin immediately after the last tab from that origin is closed >So you are intentionally breaking the web and complaining that things are cumbersome? Gee, I wonder why. Clearing cookies isn't breaking the web. Some of your websites functionality may require things to happen again if I clear cookies, but a) that seems like a you problem, and b) doesn't seem broken to me. > Yes, because that API key is often used to sign the request, contains enough entropy to make guessing impossible, and because the URL is hardcoded in the app phishing is impossible. Not sure where you're seeing this "often", but most services I have API keys for work _exactly_ like passwords. I have to jump through a few hoops to get a working key, true, but once I have it, it's essentially a password, and used in the same way. > Authentication is pretty much a solved problem. Use a password locker encrypted using a single remembered key for the "something you know" part, and use a physical Webauthn token for the "something you have" part. Stop trying to reinvent the wheel, it'll only end up annoying your users. I don't feel like it's a solved problem if normal people refuse to do that. That's a solution in the same way that the advice "Everybody be nice to each other" is going to make the world a better place.