Ask HN: Can Browsers Have a Universal Hotkey for Website Login?
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?
17 comments
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.
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.
> 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.
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.
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.
But until most of my users update I’m stuck with still maintaining the old implementation anyways.
Moving these libraries into the on-demand userspace was done intentionally for a long list of reasons, but by far the biggest advantage to me as a developer is control over the updates.
the credit card shape, mag stripe, number, and security code ARE standardized. but every website wants you to enter that separately into a different form that autocompletes some fields but not others, etc etc.
your objection is short-sighted; there are steps.
your objection is short-sighted; there are steps.
> Payment card numbers are composed of 8 to 19 digits
https://en.m.wikipedia.org/wiki/Payment_card_number
They are usually 16 digits. Except when they're 15 like Amex.
Security codes are 3 digits... Except when they're 4 digits like Amex.
Magnetic stripes have two separate tracks with two different encoding schemes developed by different organizations, and some point of sale readers will read one, the other, or both.
But yes, tell me more about how all these things are standardized.
> your objection is short-sighted; there are steps.
My point was that everyone wants a piece of the action, meaning standardized interfaces are disincentivized. This is true in the real world and is true in browsers. Do you have any actual rebuttal to that?
https://en.m.wikipedia.org/wiki/Payment_card_number
They are usually 16 digits. Except when they're 15 like Amex.
Security codes are 3 digits... Except when they're 4 digits like Amex.
Magnetic stripes have two separate tracks with two different encoding schemes developed by different organizations, and some point of sale readers will read one, the other, or both.
But yes, tell me more about how all these things are standardized.
> your objection is short-sighted; there are steps.
My point was that everyone wants a piece of the action, meaning standardized interfaces are disincentivized. This is true in the real world and is true in browsers. Do you have any actual rebuttal to that?
My credit card is stored somewhere on my iPad and the browser fills out payment forms correctly almost all the time.
If you have a store and discover people are aborting the purchasing process because your UI is unique, you're going to fix it.
If you have a store and discover people are aborting the purchasing process because your UI is unique, you're going to fix it.
What does this have to do with standardized payment systems?
There are standardized HTML elements for autocomplete forms, including attributes for credit cards. If you follow these on your website, it will be easier for the customer to make their purchase. Combine with Apple Pay / Google Pay and something that used to be an annoying chore is just a couple of clicks.
> One of the greatest tragedies of the Web is that all its basic building blocks have been stagnant for decades.
Improving the web hurts app store commissions. Apple/Google can't monetize your super awesome fancy web app, but they can snipe 15-30% of your revenue through their stores.
Improving the web hurts app store commissions. Apple/Google can't monetize your super awesome fancy web app, but they can snipe 15-30% of your revenue through their stores.
This is the Semantic Web. A big problem is that a lot of people like to do things their way.
First, there will always be edge cases. What about platforms which use OAuth? What about platforms which use another third-party authentication service? Weird password requirements? 2fa? 3fa? As a result the login implementation will be bulky, making the browser even more huge and creating new CVEs.
Second, even accounting for these edge cases, many websites will simply not participate. Which means that now you have 2 types of login forms: ones that use the new API and ones that don’t. And orthogonally you already have n types of login methods that are OAuth, Yubikey, Ledger, …, username/password. So, the login interface itself will also become bulky and old people will be even more confused.
With that out of the way, I 100% support a unified login interface, unified sorting, unified payment, unified content embedding, etc. I still think it’s worth it to develop the Semantic Web. But, I’m not counting on Google and Mozilla to work on this.
Maybe we should create a Semantic Web community and implement these systems ourselves, as JavaScript libraries with common conventions and a “Semantic Web approved” sticker. And maybe we should develop a Semantic Web browser that can intercept and implement these libraries itself, making them a fallback for traditional Web browsers. If we build up enough support eventually we’ll get new browser competition and regular browsers to start actually adopting the Semantic Web.
But…that creates n + 1 different libraries/protocols that all accomplish the same thing…which is ironic considering “a big problem with the Semantic Web is that a lot of people like to do things their own way”.
It could be worse: we have username/password autofill which has been around for decades so it actually works for 99% of websites.
First, there will always be edge cases. What about platforms which use OAuth? What about platforms which use another third-party authentication service? Weird password requirements? 2fa? 3fa? As a result the login implementation will be bulky, making the browser even more huge and creating new CVEs.
Second, even accounting for these edge cases, many websites will simply not participate. Which means that now you have 2 types of login forms: ones that use the new API and ones that don’t. And orthogonally you already have n types of login methods that are OAuth, Yubikey, Ledger, …, username/password. So, the login interface itself will also become bulky and old people will be even more confused.
With that out of the way, I 100% support a unified login interface, unified sorting, unified payment, unified content embedding, etc. I still think it’s worth it to develop the Semantic Web. But, I’m not counting on Google and Mozilla to work on this.
Maybe we should create a Semantic Web community and implement these systems ourselves, as JavaScript libraries with common conventions and a “Semantic Web approved” sticker. And maybe we should develop a Semantic Web browser that can intercept and implement these libraries itself, making them a fallback for traditional Web browsers. If we build up enough support eventually we’ll get new browser competition and regular browsers to start actually adopting the Semantic Web.
But…that creates n + 1 different libraries/protocols that all accomplish the same thing…which is ironic considering “a big problem with the Semantic Web is that a lot of people like to do things their own way”.
It could be worse: we have username/password autofill which has been around for decades so it actually works for 99% of websites.
Actually there is discussion about improving the auth experience happening at the w3c. This is driven partly out of privacy concerns.
Here's one of the groups: https://www.w3.org/community/fed-id/
Here is their meeting notes/use case flows, etc: https://github.com/fedidcg/
> The waste of developer and user time due to the Web platform
I think this is because the development is happening at a higher abstraction level (in JS frameworks, mostly). Why? Because those iterate a ton faster. Browsers are slower moving because of complexity, backwards compatibility and distribution. This is similar to the place the browser put the operating system in the 1990s and 2000s.
"The Wheel of Time turns and Ages come and pass."
Here's one of the groups: https://www.w3.org/community/fed-id/
Here is their meeting notes/use case flows, etc: https://github.com/fedidcg/
> The waste of developer and user time due to the Web platform
I think this is because the development is happening at a higher abstraction level (in JS frameworks, mostly). Why? Because those iterate a ton faster. Browsers are slower moving because of complexity, backwards compatibility and distribution. This is similar to the place the browser put the operating system in the 1990s and 2000s.
"The Wheel of Time turns and Ages come and pass."
How much of this do you think is caused by legacy browsers? If you view the browser as a general purpose OS then it makes sense the features are pretty pared down on it.
There is also a layering concern here. Login is not the problem of a presentation layer.
We ranted so much when Chrome added Google Login half a decade ago.
We ranted so much when Chrome added Google Login half a decade ago.
> Why no built-in sorting HTML tables, and easy hooks into them for custom sorting
Because as soon as you do this <table> is no longer a layout element, now it is specifically made for displaying and sorting csv style data.
Because as soon as you do this <table> is no longer a layout element, now it is specifically made for displaying and sorting csv style data.
No true at all, just have a "sortable" flag on the th element (which is absent in most layout-focused use of <table> anyway)
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.
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.
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.
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.
> 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.
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.
Also, the prompt is uniform and immediate anywhere you need authenticated. With a single client certificate that meets the server's criteria, most browsers can be configured to automatically apply your certificate so you never even see the prompt.
Furthermore, browsers support different kinds of storage for client certificates. You could, in theory, make a cloud hosted client certificate store that you unlock once per session to use with your browser.
Ultimately, it addresses the whole "finding the login button" concern by eliminating login flows from the application completely. If you have no certificate, then you can't access the service at a protocol level, period.
Furthermore, browsers support different kinds of storage for client certificates. You could, in theory, make a cloud hosted client certificate store that you unlock once per session to use with your browser.
Ultimately, it addresses the whole "finding the login button" concern by eliminating login flows from the application completely. If you have no certificate, then you can't access the service at a protocol level, period.
It's more like keeping your ID card with you. The hospital would still have your records but wouldn't give you access to them until you present your ID card.
If you lose your ID card, you have to go back to the issuer of ID cards and request a new one. Similarly, with client certificates, you go back to the Certificate Authority to get a new client certificate.
If you lose your ID card, you have to go back to the issuer of ID cards and request a new one. Similarly, with client certificates, you go back to the Certificate Authority to get a new client certificate.
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
I wish well-known would be actually more... known and used by both websites owners and browsers
I wish well-known would be actually more... known and used by both websites owners and browsers
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.
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.
Not offering a solution, just complaining.
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.
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.
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
That could have been built with BrowserID (https://hacks.mozilla.org/2011/07/introducing-browserid-easi...) but surprisingly (or not!) the big platforms didn't embrace a user-centric login protocol.
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.
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.
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.
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.
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.
This is correct. It's called "identifier first", and it's a feature I've seen organizations request pretty often when they have to support multiple providers and auth schemes.
I worked at a company that supported authentication with any of the InCommon Consortium members, and the solution was to provide a drop-down[1] where the user could select their institution (mostly academic or academic-adjacent) and then be directed to the provider to authenticate. As you might imagine, this only worked when there were a handful of institutions and the users were somewhat sophisticated. As of now there are nearly 600 institutions. With that many selection in the dropdown and less sophisticated users, that UX was unsustainable.
1 for example: https://spaces.at.internet2.edu/download/attachments/1686917...
I worked at a company that supported authentication with any of the InCommon Consortium members, and the solution was to provide a drop-down[1] where the user could select their institution (mostly academic or academic-adjacent) and then be directed to the provider to authenticate. As you might imagine, this only worked when there were a handful of institutions and the users were somewhat sophisticated. As of now there are nearly 600 institutions. With that many selection in the dropdown and less sophisticated users, that UX was unsustainable.
1 for example: https://spaces.at.internet2.edu/download/attachments/1686917...
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.
It can be, but it's pretty heavyweight for a client-side feature, if the username/email to auth provider mapping is complex.
That wouldn't need to be a client side feature; a call can easily be made, and likely is in most of these cases.
Keepassxc browser plugin can seamlessly handle multipage logins, TOTPs, and very soon credit card information.
It also has keyboard shortcuts for filling out login details.
It also has keyboard shortcuts for filling out login details.
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/
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/
What do Ctrl+K and Ctrl+/ do?
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.
Ctrl+/ is usually used to show all the keyboard shortcuts, or at least the most common ones. Usable on Discord, Slack, VSCode, etc.
I hate when “sign up” is a bigger button than “log in”
Or when “log in” Is hidden in a menu, while “sign up” Is a nice clear button on the home page.
A real middle finger to existing customers. It's so instantly and visibly rude.
Or far away. Or using some "clever" non-signup word like "Already in the beta? Click here."
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.
Manually hiding certain elements can make a big difference and I highly encourage trying it out.
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.
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.
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.
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.
> 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.
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.
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.
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.
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.
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.
Yes, it definitely should have been maintained and improved over the years.
Identity is hard. What is the ID you'd mandate for every website on the internet? Your bank might use your email, but your retirement accounts probably use SSN. Your message board might use a made up handle (and you don't even want it to know an email associated with you). Modern services might be using a passkey/webauthn hardware device. Some sites even have multiple identity fields, like I have bank accounts that I have to specify id/email and type of account (personal, professional, etc.) to login. The point is there isn't any single concept of identification or principle that can work for everything on the web.
You can still handle all those cases but just with three new buttons in the browser itself. Users would never have to find the login link buried in the footer or forget password only available after you fail a login. Web developers would implement where to go on each button click and unimplemented clicks on these three buttons would be like a 404 and considered broken.
Forgot password isn't enough, what if I forgot my login ID? But then it circles back to my point--what _is_ an identity? Would the button say 'forgot email'? But not every site uses email as principle ID...
It gets even more complicated when I have multiple accounts. Who lets me pick what account I want to use? Is the site responsible for that, or does the browser now need a concept of storing multiple IDs (whatever they might be) and managing them?
It gets extremely complicated extremely fast.
It gets even more complicated when I have multiple accounts. Who lets me pick what account I want to use? Is the site responsible for that, or does the browser now need a concept of storing multiple IDs (whatever they might be) and managing them?
It gets extremely complicated extremely fast.
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...
[1] https://github.com/fedidcg/FedCM/blob/main/meetings/2021/Web...
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
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.
The beauty of decentralisation can also lead to rather long wait times for new standards to establish themselves.
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.
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.
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.
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.
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.
Isn't that kind of what webauthn is supposed to be?
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!
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!