6 ms·

Ask HN: Can Browsers Have a Universal Hotkey for Website Login?

31 points by ghastmaster 4y ago

I am tired of finding the login button for various websites I visit. A universal browser hotkey would be fantastic. I suppose there would need to be a change to html as well?

yuppie_scum 4y ago
I hate when “sign up” is a bigger button than “log in”
- kyleyeats 4y ago
  Or far away. Or using some "clever" non-signup word like "Already in the beta? Click here."
- jimmytidey 4y ago
  A real middle finger to existing customers. It's so instantly and visibly rude.
- Calamitous 4y ago
  Or when “log in” Is hidden in a menu, while “sign up” Is a nice clear button on the home page.
- BuyMyBitcoins 4y ago
  I started using uBlock Origin’s picker tool to block those buttons and other signup/engagement prompts on websites I frequently visit or already have accounts with. Manually hiding certain elements can make a big difference and I highly encourage trying it out.
andrewfromx 4y ago
The whole concept of being logged in (cookied with some user_id) or not is so fundamental to web apps I wonder… If we were making the HTML spec today… can you image a world where the login sign up and forgot password features were in the GUI of the browser itself? Completely independent of the rendered HTML and no web developer would ever have to work those buttons into the design. They would be like the HOME or BACK buttons.
- nicoburns 4y ago
  > If we were making the HTML spec today… can you image a world where the login sign up and forgot password features were in the GUI of the browser itself? This kinda exists as "basic auth". The UI is just terrible so nobody uses it. It's not a button though. A button would be pretty nice to be fair.
  - eterm 4y ago
    I think the security of basic auth killed it off. 1. Usernames and passwords sent clear text in URLs. 2. Hijacking is worse than cookie hijacking because you get the permanent credentials with no way to force session invalidation 3. Credentials would be cached (and visible) in browser history It was a byproduct of the early web and isn't fit for purpose.
    - yamtaddle 4y ago
      Credentials are sent in headers, and http-auth supports a bunch of schemes other than basic. Browsers have (shitty) UI for taking the username and pass, you don't have to put it in the address bar (and that's been discouraged for years and years). There's no reason whatsoever the feature couldn't have been improved and promoted over the years such that there would rarely be a reason to use anything else. The Web's failure here has been a remarkably expensive misstep for the software economy.
      - qbasic_forever 4y ago
        There's no concept of forgot my password or ID with browser auth. People tried using it years and years ago and it just never evolved into something usable by the general public.
        yamtaddle 4y ago
        Yes, it definitely should have been maintained and improved over the years.
- 4y ago
fnordian_slip 4y ago
It would be lovely, but considering most website aren't even accessible to visually impaired users, I wouldn't expect a consensus on something like this in the next decade. The beauty of decentralisation can also lead to rather long wait times for new standards to establish themselves.
- qbasic_forever 4y ago
  Proper semantic HTML with aria tags (which are easily checked using tools like lighthouse, and actually factor into Google SEO ranking now) work great with screen readers.
  - fnordian_slip 4y ago
    That is correct, but a lot of websites still use poorly implemented elements like carousels which cause screen readers to start at the beginning every couple of seconds, for example. It took meeting a blind developer at work for me to realize how bad parts of the web still are for the visually impaired. And many of the barriers are prevented simply by putting some thought into accessibility in the planning stage.
juujian 4y ago
I could imagine a browser plugin that has some hard-coded stuff for the most commonly used websites. Since Firefox autofills account information, automating the whole process should be quite feasible.
lakomen 4y ago
Isn't that kind of what webauthn is supposed to be?
input_sh 4y ago
Password managers can kind of get you there half the time. My password manager saves login URL, so if I click on an item it opens it and fills in login info. If it's on the same page I'm looking at it puts the fields in focus. Where it fails is when websites implement separate pages for username and password (making me have to autofill twice), and where the login is behind a dropdown. Depending on a browser and password manager, there must be some way to trigger it via keyboard shortcut.
- b0afc375b5 4y ago
  Is there any reason, technical or otherwise, for separating username and password to two pages? Gmail does this and it's a bit frustrating not being able to use my password manager effortlessly.
  - ncallaway 4y ago
    The use case I’ve generally seen that leads to this design is supporting SSO from different providers. So, you ask for email first, then you can look up the user and see if the use a password to login, or if they need to be redirected to some other system to manager authentication.
    - mynameisvlad 4y ago
      That can be done on a single page. I've had quite a few SaaSes do a lookup as I tab out of the username/email field and then redirect me.
      - cratermoon 4y ago
        It can be, but it's pretty heavyweight for a client-side feature, if the username/email to auth provider mapping is complex.
        mynameisvlad 4y ago
        That wouldn't need to be a client side feature; a call can easily be made, and likely is in most of these cases.
dzek69 4y ago
Browsers could use `.well-known` file if defined by a website and if there would be one standard defined in the first place (like there is one for changing password!): https://en.wikipedia.org/wiki/Well-known_URI https://en.wikipedia.org/wiki/Well-known_URI I wish well-known would be actually more... known and used by both websites owners and browsers
- ziml77 4y ago
  Fastest way to get the well-known file used would be to get people to believe that not having one or having an inaccurate or incomplete one will cause Google to downrank you.
yamtaddle 4y ago
One of the greatest tragedies of the Web is that all its basic building blocks have been stagnant for decades. Browsers have a built-in auth system for HTTP-auth—there's no reason it couldn't have been improved over the years, such that it's actually a decent choice for login. Why no built-in sorting HTML tables, and easy hooks into them for custom sorting? Why no robust, highly capable built-in payment system (can you imagine the person-hours wasted writing payment screens over and over again, and the user frustration and lost time due to so many of those having problems)? Why were features like frames left to rot rather than improved? They're a common element in UI toolkits, and we're using the Web to make "apps" now! The waste of developer and user time due to the Web platform seeming to just abandon tons of its own functionality and failing to address common and high-cost use cases head-on, is truly staggering.
- mynameisvlad 4y ago
  > Why no robust, highly capable built-in payment system (can you imagine the person-hours wasted writing payment screens over and over again, and the user frustration and lost time due to so many of those having problems)? I agree with your premise, but this is a bad example. Universal payment systems are not a simple task. Even remotely. Go out to any American city, for instance, and as you walk through the stores, catalog the various credit card terminals you see. Not even the PoS system as a whole, but just the credit card interface. You will see dozens of different designs and play on designs by dozens of different manufacturers. If it's hard to do in the physical world, what makes you think it'd be easy in a browser? Everyone wants a share of the pie and that means fragmentation all the way down.
  - yamtaddle 4y ago
    There are enough common elements that it's absolutely do-able. There's no reason the payment methods would have to be hardcoded or anything, they could easily be dynamic but still let the browser supply the UI for greater security, accessibility, and user confidence. Covering 99% of use-cases is far from intractable.
    - 4y ago
temporallobe 4y ago
Kind of related, but slightly off-topic, I would estimate that at least 20% of my work day is spent authenticating or re-authenticating to various services and accounts, in addition to password management. Constant and aggressive timeouts, MFA, dealing with highly-layered and convoluted security schemes, VPNs, multiple certificates, multiple independent accounts, etc. SSO is a thing of the past and it has become the “sludge” of the IT world. Not offering a solution, just complaining.
- nine_k 4y ago
  Partly this is the price of defense in depth, so that a compromise of one account does not affect other accounts. Partly it's poor ergonomics: a password manager should fill in the credentials for you, and 2FA could be a one-touch token. I wonder what industry are you in with such intense security requirements.
- earthling8118 4y ago
  I agree with this. It's still bad, but it was absolutely worse before I upgraded my PC. That easily reduced the amount of time for this by 80%, but it still takes a very long time each day
hyperupcall 4y ago
This is the kind of stuff I describe in my semantic hotkeys[1] piece. There isn't a really good way to define hotkeys for web apps across websites. In lieu of a browser spec (for now), or a non-normative recommendation, there needs to be convention under no uncertain terms about which keys do what. We already have Ctrl+K and Ctrl+/, I think it's time to formalize these conventions, and more! There is a gap of semantic interoperability across websites that needs some fixin'. [1] https://hyperupcall.github.io/blog/posts/semantic-hotkeys/ https://hyperupcall.github.io/blog/posts/semantic-hotkeys/
- mcculley 4y ago
  What do Ctrl+K and Ctrl+/ do?
  - hyperupcall 4y ago
    Ctrl+K is often used to perform any kind of action. On Discord, Slack, GitHub, etc. let you perform any action with this hotkey. It's also a generic search, as website searches implemented with Algolia use this by default. Ctrl+/ is usually used to show all the keyboard shortcuts, or at least the most common ones. Usable on Discord, Slack, VSCode, etc.
cookiengineer 4y ago
Technically, nothing prevents you from extending Basic Auth and to make it a usable better auth protocol. You could write an extension and make a case for login/logout/session management and/or generalized hotkeys and go with that into the w3c or ietf to propose an auth mechanism. I mean, it can be something as simple as having more meaningful aria-attributes on the HTML tags that you parse out and make usable via hotkeys. It's hard to talk about an idea not yet finished enough so that it can be specified, but I'm sure there is a HUGE need for accessibility improving browser extensions to begin with.
jodoherty 4y ago
Mutual TLS is pretty cool. You can install client certificates into your browser issued from a CA that a server accepts, and the server can then use the details in your client certificate to authenticate you to an application specific user. When you visit a server using mutual TLS, you'll get a prompt showing all your client certificates that match CAs that the server accepts. Once you select one, all your future requests will use that client certificate and be associated with that identity. The client certificates can even be placed into smart card hardware devices (which can be USB or actual smart cards) that require a PIN or some other factor to use. Because it's all built on public/private key encryption, the server has no credentials to lose in a data breach. Nobody can steal your credentials and reuse them to attack your other accounts. And this is supported by all browsers today.
- ghastmaster 4y ago
  That would put a lot of responsibility on the user. It is analogous to keeping medical records yourself and taking them with you to the hospital every time you visit. In the event of a fire or other catastrophe, your credentials would be lost forever, correct? Either way, I usually do not want to login or be prompted to login to sites I visit. When I do want to login, either via Mutual TLS or by entering my credentials, I would like to have a hotkey I can push that brings me to the login page, pushes the login button, or inserts my TLS cert.
  - LawTalkingGuy 4y ago
    > In the event of a fire or other catastrophe, your credentials would be lost forever, correct? If you intentionally did the hard path of owning all your keys then didn't back them up - yes. But most users would be subscribing to some auth service (Google, their bank, etc) and that organization would have recovery issues. > I would like to have a hotkey I can push that This is already super simple with no new tech - just make your login button of class "LoginButton" or something we pick, and the plugin will just click it via code. The UI really is slick. When the site requests auth the browser pops up a window with the help of the system's secret storage and shows you your identities. This could be automated to avoid even that single popup if desired.
grepfru_it 4y ago
I went to login to twitter the other day and the login button was at the bottom of the page. I don't know why that made me rage so much, but because of that I fully second this request, but there is a top level comment here pointing out mutual TLS and I think that is the solution
fabrice_d 4y ago
That could have been built with BrowserID (https://hacks.mozilla.org/2011/07/introducing-browserid-easier-and-safer-authentication-on-the-web/ https://hacks.mozilla.org/2011/07/introducing-browserid-easi...) but surprisingly (or not!) the big platforms didn't embrace a user-centric login protocol.
_8j50 4y ago
I'd go more than that and say browsers need to have builtin standards compliant credential managememt. They already manage form login passwords and support stuff like webauthn. What needs to happen is for digital signatures need to replace session cookies which can be stolen and are the last frontier in web authentication insecurity. Both passwords and long term private signing keys would be backed by an encrypted backup for moving identity between devices but for runtime usage TPM or FIDOx would store them, far from the reaches of malware. There would be no "login" but rather "identity selection" where you have to type in a password to access the private key (1st factor of auth) after which periodically updated challenge tokens by the site are signed by the TPM or FIDOx device for every request. "Registration" would mean enrolling your public key, that's it. What settings you pick like an account name would be out of scope for the standard. A browser prompt would ask if you want to enroll with a site and have you store the password and related private keys under a named identifier for having multiple accounts. Account recovery is also handled by browsers. They can backup the backup file in their own or someone else's service along optionally with an alternate key for it. That recovery service would let you manage how to do recovery: just email, some other messaging account, offline keys, a different account,etc... users can also opt-out and backup their keys on a separate FIDOx device theu manually sync. Now, what I just suggested means cookies for auth will not be needed. Email will not be needed for security/recovery (or hopefully anything else) and mostly eliminate credential theft/phishing including MFA bypass by way of cookie/token theft. Existing authentication threat models also have you out of scope and unprotected in the event you have operating system malware. This would offer significant risk reduction there. There is a technique now where you "vnc" stream a remote desktop and webusb for usb devices and authenticate to the real site with even a yubikey and the attacker still gets your session cookie and runs off with it to do what they want. This would force them to have you maintain an active session with them with new signed challenges to maintain access. If the challenge is renewed every minute then at most they have access to your account for one minute after you get phished and close the tab. But more than that, the usual auth prompt is by your browser outside of any tab so even ina full screen tab they would need to make the remote vnc in the tab look like your browser UI which can have a security picture associated with it to prevent just this type of phishing. What I am against is drastically changing auth workflows without re-thinking auth workflow/UX. With my idea you kill many birds with one stone. Even the most unaware user can't get phished or easily lose access to their account or have to figure out the right auth UX on a site. And site/app owners just have to get their code to issue new challenge tokens and verify them with their own signing key. No more having to manage and securely store user secrets or support registration/login UI. Better security and risk burdens for everyone!
sgoto 4y ago
Some of us are proactively working on this problem [1]. Not trivial, but I think we are making forward progress to reconcile and mediate login in browser UX. [1] https://github.com/fedidcg/FedCM/blob/main/meetings/2021/Web%20Identity%20API.pdf https://github.com/fedidcg/FedCM/blob/main/meetings/2021/Web...
seydor 4y ago
Mozilla had Persona but it somewhat mysteriously got abandoned even though it would be a good pragmatic solution that would be integrated to the browser.

31 points by ghastmaster 4y ago

I am tired of finding the login button for various websites I visit. A universal browser hotkey would be fantastic. I suppose there would need to be a change to html as well?

yuppie_scum 4y ago

I hate when “sign up” is a bigger button than “log in”

kyleyeats 4y ago
Or far away. Or using some "clever" non-signup word like "Already in the beta? Click here."
jimmytidey 4y ago
A real middle finger to existing customers. It's so instantly and visibly rude.
Calamitous 4y ago
Or when “log in” Is hidden in a menu, while “sign up” Is a nice clear button on the home page.
BuyMyBitcoins 4y ago
I started using uBlock Origin’s picker tool to block those buttons and other signup/engagement prompts on websites I frequently visit or already have accounts with. Manually hiding certain elements can make a big difference and I highly encourage trying it out.

andrewfromx 4y ago

The whole concept of being logged in (cookied with some user_id) or not is so fundamental to web apps I wonder… If we were making the HTML spec today… can you image a world where the login sign up and forgot password features were in the GUI of the browser itself? Completely independent of the rendered HTML and no web developer would ever have to work those buttons into the design. They would be like the HOME or BACK buttons.

nicoburns 4y ago
> If we were making the HTML spec today… can you image a world where the login sign up and forgot password features were in the GUI of the browser itself? This kinda exists as "basic auth". The UI is just terrible so nobody uses it. It's not a button though. A button would be pretty nice to be fair.
- eterm 4y ago
  I think the security of basic auth killed it off. 1. Usernames and passwords sent clear text in URLs. 2. Hijacking is worse than cookie hijacking because you get the permanent credentials with no way to force session invalidation 3. Credentials would be cached (and visible) in browser history It was a byproduct of the early web and isn't fit for purpose.
  - yamtaddle 4y ago
    Credentials are sent in headers, and http-auth supports a bunch of schemes other than basic. Browsers have (shitty) UI for taking the username and pass, you don't have to put it in the address bar (and that's been discouraged for years and years). There's no reason whatsoever the feature couldn't have been improved and promoted over the years such that there would rarely be a reason to use anything else. The Web's failure here has been a remarkably expensive misstep for the software economy.
    - qbasic_forever 4y ago
      There's no concept of forgot my password or ID with browser auth. People tried using it years and years ago and it just never evolved into something usable by the general public.
      - yamtaddle 4y ago
        Yes, it definitely should have been maintained and improved over the years.
4y ago

fnordian_slip 4y ago

It would be lovely, but considering most website aren't even accessible to visually impaired users, I wouldn't expect a consensus on something like this in the next decade. The beauty of decentralisation can also lead to rather long wait times for new standards to establish themselves.

qbasic_forever 4y ago
Proper semantic HTML with aria tags (which are easily checked using tools like lighthouse, and actually factor into Google SEO ranking now) work great with screen readers.
- fnordian_slip 4y ago
  That is correct, but a lot of websites still use poorly implemented elements like carousels which cause screen readers to start at the beginning every couple of seconds, for example. It took meeting a blind developer at work for me to realize how bad parts of the web still are for the visually impaired. And many of the barriers are prevented simply by putting some thought into accessibility in the planning stage.

juujian 4y ago

I could imagine a browser plugin that has some hard-coded stuff for the most commonly used websites. Since Firefox autofills account information, automating the whole process should be quite feasible.

lakomen 4y ago

Isn't that kind of what webauthn is supposed to be?

input_sh 4y ago

Password managers can kind of get you there half the time. My password manager saves login URL, so if I click on an item it opens it and fills in login info. If it's on the same page I'm looking at it puts the fields in focus. Where it fails is when websites implement separate pages for username and password (making me have to autofill twice), and where the login is behind a dropdown. Depending on a browser and password manager, there must be some way to trigger it via keyboard shortcut.

b0afc375b5 4y ago
Is there any reason, technical or otherwise, for separating username and password to two pages? Gmail does this and it's a bit frustrating not being able to use my password manager effortlessly.
- ncallaway 4y ago
  The use case I’ve generally seen that leads to this design is supporting SSO from different providers. So, you ask for email first, then you can look up the user and see if the use a password to login, or if they need to be redirected to some other system to manager authentication.
  - mynameisvlad 4y ago
    That can be done on a single page. I've had quite a few SaaSes do a lookup as I tab out of the username/email field and then redirect me.
    - cratermoon 4y ago
      It can be, but it's pretty heavyweight for a client-side feature, if the username/email to auth provider mapping is complex.
      - mynameisvlad 4y ago
        That wouldn't need to be a client side feature; a call can easily be made, and likely is in most of these cases.

dzek69 4y ago

Browsers could use `.well-known` file if defined by a website and if there would be one standard defined in the first place (like there is one for changing password!): https://en.wikipedia.org/wiki/Well-known_URI https://en.wikipedia.org/wiki/Well-known_URI I wish well-known would be actually more... known and used by both websites owners and browsers

ziml77 4y ago
Fastest way to get the well-known file used would be to get people to believe that not having one or having an inaccurate or incomplete one will cause Google to downrank you.

yamtaddle 4y ago

One of the greatest tragedies of the Web is that all its basic building blocks have been stagnant for decades. Browsers have a built-in auth system for HTTP-auth—there's no reason it couldn't have been improved over the years, such that it's actually a decent choice for login. Why no built-in sorting HTML tables, and easy hooks into them for custom sorting? Why no robust, highly capable built-in payment system (can you imagine the person-hours wasted writing payment screens over and over again, and the user frustration and lost time due to so many of those having problems)? Why were features like frames left to rot rather than improved? They're a common element in UI toolkits, and we're using the Web to make "apps" now! The waste of developer and user time due to the Web platform seeming to just abandon tons of its own functionality and failing to address common and high-cost use cases head-on, is truly staggering.

mynameisvlad 4y ago
> Why no robust, highly capable built-in payment system (can you imagine the person-hours wasted writing payment screens over and over again, and the user frustration and lost time due to so many of those having problems)? I agree with your premise, but this is a bad example. Universal payment systems are not a simple task. Even remotely. Go out to any American city, for instance, and as you walk through the stores, catalog the various credit card terminals you see. Not even the PoS system as a whole, but just the credit card interface. You will see dozens of different designs and play on designs by dozens of different manufacturers. If it's hard to do in the physical world, what makes you think it'd be easy in a browser? Everyone wants a share of the pie and that means fragmentation all the way down.
- yamtaddle 4y ago
  There are enough common elements that it's absolutely do-able. There's no reason the payment methods would have to be hardcoded or anything, they could easily be dynamic but still let the browser supply the UI for greater security, accessibility, and user confidence. Covering 99% of use-cases is far from intractable.
  - 4y ago

temporallobe 4y ago

Kind of related, but slightly off-topic, I would estimate that at least 20% of my work day is spent authenticating or re-authenticating to various services and accounts, in addition to password management. Constant and aggressive timeouts, MFA, dealing with highly-layered and convoluted security schemes, VPNs, multiple certificates, multiple independent accounts, etc. SSO is a thing of the past and it has become the “sludge” of the IT world. Not offering a solution, just complaining.

nine_k 4y ago
Partly this is the price of defense in depth, so that a compromise of one account does not affect other accounts. Partly it's poor ergonomics: a password manager should fill in the credentials for you, and 2FA could be a one-touch token. I wonder what industry are you in with such intense security requirements.
earthling8118 4y ago
I agree with this. It's still bad, but it was absolutely worse before I upgraded my PC. That easily reduced the amount of time for this by 80%, but it still takes a very long time each day

hyperupcall 4y ago

This is the kind of stuff I describe in my semantic hotkeys[1] piece. There isn't a really good way to define hotkeys for web apps across websites. In lieu of a browser spec (for now), or a non-normative recommendation, there needs to be convention under no uncertain terms about which keys do what. We already have Ctrl+K and Ctrl+/, I think it's time to formalize these conventions, and more! There is a gap of semantic interoperability across websites that needs some fixin'. [1] https://hyperupcall.github.io/blog/posts/semantic-hotkeys/ https://hyperupcall.github.io/blog/posts/semantic-hotkeys/

mcculley 4y ago
What do Ctrl+K and Ctrl+/ do?
- hyperupcall 4y ago
  Ctrl+K is often used to perform any kind of action. On Discord, Slack, GitHub, etc. let you perform any action with this hotkey. It's also a generic search, as website searches implemented with Algolia use this by default. Ctrl+/ is usually used to show all the keyboard shortcuts, or at least the most common ones. Usable on Discord, Slack, VSCode, etc.

cookiengineer 4y ago

Technically, nothing prevents you from extending Basic Auth and to make it a usable better auth protocol. You could write an extension and make a case for login/logout/session management and/or generalized hotkeys and go with that into the w3c or ietf to propose an auth mechanism. I mean, it can be something as simple as having more meaningful aria-attributes on the HTML tags that you parse out and make usable via hotkeys. It's hard to talk about an idea not yet finished enough so that it can be specified, but I'm sure there is a HUGE need for accessibility improving browser extensions to begin with.

jodoherty 4y ago

Mutual TLS is pretty cool. You can install client certificates into your browser issued from a CA that a server accepts, and the server can then use the details in your client certificate to authenticate you to an application specific user. When you visit a server using mutual TLS, you'll get a prompt showing all your client certificates that match CAs that the server accepts. Once you select one, all your future requests will use that client certificate and be associated with that identity. The client certificates can even be placed into smart card hardware devices (which can be USB or actual smart cards) that require a PIN or some other factor to use. Because it's all built on public/private key encryption, the server has no credentials to lose in a data breach. Nobody can steal your credentials and reuse them to attack your other accounts. And this is supported by all browsers today.

ghastmaster 4y ago
That would put a lot of responsibility on the user. It is analogous to keeping medical records yourself and taking them with you to the hospital every time you visit. In the event of a fire or other catastrophe, your credentials would be lost forever, correct? Either way, I usually do not want to login or be prompted to login to sites I visit. When I do want to login, either via Mutual TLS or by entering my credentials, I would like to have a hotkey I can push that brings me to the login page, pushes the login button, or inserts my TLS cert.
- LawTalkingGuy 4y ago
  > In the event of a fire or other catastrophe, your credentials would be lost forever, correct? If you intentionally did the hard path of owning all your keys then didn't back them up - yes. But most users would be subscribing to some auth service (Google, their bank, etc) and that organization would have recovery issues. > I would like to have a hotkey I can push that This is already super simple with no new tech - just make your login button of class "LoginButton" or something we pick, and the plugin will just click it via code. The UI really is slick. When the site requests auth the browser pops up a window with the help of the system's secret storage and shows you your identities. This could be automated to avoid even that single popup if desired.

grepfru_it 4y ago

I went to login to twitter the other day and the login button was at the bottom of the page. I don't know why that made me rage so much, but because of that I fully second this request, but there is a top level comment here pointing out mutual TLS and I think that is the solution

fabrice_d 4y ago

That could have been built with BrowserID (https://hacks.mozilla.org/2011/07/introducing-browserid-easier-and-safer-authentication-on-the-web/ https://hacks.mozilla.org/2011/07/introducing-browserid-easi...) but surprisingly (or not!) the big platforms didn't embrace a user-centric login protocol.

_8j50 4y ago

I'd go more than that and say browsers need to have builtin standards compliant credential managememt. They already manage form login passwords and support stuff like webauthn. What needs to happen is for digital signatures need to replace session cookies which can be stolen and are the last frontier in web authentication insecurity. Both passwords and long term private signing keys would be backed by an encrypted backup for moving identity between devices but for runtime usage TPM or FIDOx would store them, far from the reaches of malware. There would be no "login" but rather "identity selection" where you have to type in a password to access the private key (1st factor of auth) after which periodically updated challenge tokens by the site are signed by the TPM or FIDOx device for every request. "Registration" would mean enrolling your public key, that's it. What settings you pick like an account name would be out of scope for the standard. A browser prompt would ask if you want to enroll with a site and have you store the password and related private keys under a named identifier for having multiple accounts. Account recovery is also handled by browsers. They can backup the backup file in their own or someone else's service along optionally with an alternate key for it. That recovery service would let you manage how to do recovery: just email, some other messaging account, offline keys, a different account,etc... users can also opt-out and backup their keys on a separate FIDOx device theu manually sync. Now, what I just suggested means cookies for auth will not be needed. Email will not be needed for security/recovery (or hopefully anything else) and mostly eliminate credential theft/phishing including MFA bypass by way of cookie/token theft. Existing authentication threat models also have you out of scope and unprotected in the event you have operating system malware. This would offer significant risk reduction there. There is a technique now where you "vnc" stream a remote desktop and webusb for usb devices and authenticate to the real site with even a yubikey and the attacker still gets your session cookie and runs off with it to do what they want. This would force them to have you maintain an active session with them with new signed challenges to maintain access. If the challenge is renewed every minute then at most they have access to your account for one minute after you get phished and close the tab. But more than that, the usual auth prompt is by your browser outside of any tab so even ina full screen tab they would need to make the remote vnc in the tab look like your browser UI which can have a security picture associated with it to prevent just this type of phishing. What I am against is drastically changing auth workflows without re-thinking auth workflow/UX. With my idea you kill many birds with one stone. Even the most unaware user can't get phished or easily lose access to their account or have to figure out the right auth UX on a site. And site/app owners just have to get their code to issue new challenge tokens and verify them with their own signing key. No more having to manage and securely store user secrets or support registration/login UI. Better security and risk burdens for everyone!

sgoto 4y ago

Some of us are proactively working on this problem [1]. Not trivial, but I think we are making forward progress to reconcile and mediate login in browser UX. [1] https://github.com/fedidcg/FedCM/blob/main/meetings/2021/Web%20Identity%20API.pdf https://github.com/fedidcg/FedCM/blob/main/meetings/2021/Web...

seydor 4y ago

Mozilla had Persona but it somewhat mysteriously got abandoned even though it would be a good pragmatic solution that would be integrated to the browser.