Can Browsers Have a Universal Hotkey for Website Login?

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.

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.

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

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.

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.

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/

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

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.

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.

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...

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.

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!