15 ms·

HTTP Basic Auth could be so much better with a little help from browsers. If it was a bit better, most websites wouldn't need to implement login pages over and

HTTP Basic Auth could be so much better with a little help from browsers. If it was a bit better, most websites wouldn't need to implement login pages over and over again. Plus it would be more secure since the popup is in its own security context. * Add a button to log out. Logout never really worked across browsers with basic auth. * Allow to inject a logo or a tiny bit of customization for branding. The default popup looks too ugly. * Improve the Digest auth to modern crypto standards. Stop passing plain passwords over the wire. That's it. It's not a massive amount of work and it could enable to simplify a lot of the Internet.

slim 5y ago
Stop passing plain passwords over the wire this is already solved by https
- deleted 5y ago
  [deleted]
- lukevp 5y ago
  Only partially. If the client and server have an agreement on a hashing protocol, there’s no reason that the browser shouldn’t be able to hash as well and prevent the password from ever leaving memory on the client system. HTTPS is still vulnerable to many man in the middle attacks, and many corporate and business networks do deep packet inspection to decrypt https (they control the machines so intercepting the cert issuance and installing their own root CA is easily doable). Another issue is that improper logging on the server (or depending on the implementation, even intermediate load balancers) could accidentally leak the plaintext password. Client side hashing is a much better solution to this, and if it’s a native browser supported protocol, it would even work without JS.
  - ncann 5y ago
    How do you do client side hashing without the server sending the salt/pepper to the client, which is a really bad thing?
    - notfed 5y ago
      There are answers to this. I asked myself this a few years ago, which led recursively to new tricky questions. I eventually solved the tree of the questions: I designed myself into a solution that I later realized was essentially an asymmetric PAKE (e.g., analogous to OPAQUE). So, an attempt to solve your question eventually leads to using an asymetric PAKE. But, this is way, way more complex. You'd really have to squint your eyes to believe that the diminishing returns are worth it.
  - axiosgunnar 5y ago
    Your suggestion is vulnerable to the https://en.m.wikipedia.org/wiki/Pass_the_hash https://en.m.wikipedia.org/wiki/Pass_the_hash attack. Your suggestion is basically going back to the days where databases stored plaintext passwords in the database, just that the plaintext happens to be a hash.
  - lixtra 5y ago
    > If the client and server have an agreement on a hashing protocol, there’s no reason that the browser shouldn’t be able to hash as well and prevent the password from ever leaving memory on the client system. Shouldn’t it be a proper challenge/response? Otherwise the hash is barely better than the password.
  - jeroenhd 5y ago
    What does it matter? If a criminal gains the hash, they can log in and be malicious anyway. If a criminal can do a MitM, they can substitute the Javascript that's hashing your password with all the nonces and salts and peppers you add to it and send the password anyway. If you just hash the password, the hash becomes the password. You're not solving the problem that way, you're just switching around definitions. There is an alternative that's supported in most platforms, and that's WebAuthn. Not even a need for a password automatic secure handshakes and with the right protocols, the keys differ per site so they're very hard to spoof through phishing. You can achieve much of the same thing with client TLS certificates, but the UX for that is even worse than the UX for HTTP Basic.
    - staticassertion 5y ago
      > What does it matter? If a criminal gains the hash, they can log in and be malicious anyway. To that one site. But users reuse passwords and if a criminal only has a hash they can't reuse it across sites.
      - jeroenhd 5y ago
        But the attacker controls the TLS connection already, so they'll just strip out the hashing functionality or send a piece of JS to steal the password directly from the password field. It's not that I don't understand where you're coming from (I once almost started writing such a library a few years back!), but I just can't think of a threat model where this makes sense. That's also what moved me away from working on such a system. To me, this approach feels like an attempt to recreate software-only U2F, but outside the browser. I don't think client side code can fix these problems. It can make stealing passwords more difficult for criminals if every website uses their own bespoke password processing script, but that'll also add a huge attack surface to your code and it'll be a burden to maintain.
        staticassertion 5y ago
        I don't know why people are assuming the attacker: A) Controls the code running the auth API B) Controls the javascript As if that's the common attack. The common attack is that the attacker has a read on the hash, either through injection vulnerabilities or other leaks. Your attacker, as described, has remote code execution on a server that hosts the auth API and the Javascript in one place. That is a very specific, powerful attacker! > but I just can't think of a threat model where this makes sense 1. An attacker has CSRF and can trick your code into sending the hash to them. This significantly reduces the harm of that attack. 2. An attacker has an injection vulnerability giving them read access to hashes ie: sql injection, perhaps the most significant and relevant attack to discuss with passwords. 3. An attacker takes advantage of a timing attack, bruteforcing the server and measuring response times to leak its value. They can now only leak the hashed value, which is going to take way longer to leak and doesn't expose their password. And more! This defense tackles what are very very arguably the major threats to consider with regards to password security (they're the big ones in OWASP top 10). > It can make stealing passwords more difficult for criminals if every website uses their own bespoke password processing script, but that'll also add a huge attack surface to your code and it'll be a burden to maintain. You can significantly reduce harm and attack surface with all of 3 lines in your frontend code. salt = hash(username + static_salt) password_hash = pbkdf2(plaintext_password, salt) it's trivial to implement this. I'll grant you that PAKEs may be more complex to implement today, but even if we talk about a very basic implementation of client side hashing I think there's obvious value.
- StefanKarpinski 5y ago
  The password is still revealed to the server. There are password verification protocols where the password is not revealed to the server either, which is much more secure as it means that you’re not at the mercy of whether the sever operator follows good security practices about not saving your password in plain text somewhere.
  - thaumasiotes 5y ago
    > There are password verification protocols where the password is not revealed to the server either, which is much more secure as it means that you’re not at the mercy of whether the sever operator follows good security practices about not saving your password in plain text somewhere. Well, the most common such protocol is TOTP, which still requires the server to store your full password. In that sense it's worse than a naive password exchange, which only requires the server to store your hashed password. There are other password protocols that require neither transmission nor server retention of the full password, but it seems worth noting that the protocol we actually have didn't bother with that.
    - teekert 5y ago
      Does it matter if the pw is stored salted and hashed?
      - thaumasiotes 5y ago
        Yes, that's why we do that. I'm not sure what you want to ask.
  - LinAGKar 5y ago
    >The password is still revealed to the server. And with digest auth, the server must have the plain text password already. But sure, maybe there is a third option.
  - alerighi 5y ago
    As every other login form does. In this situation basic authentication is no different from every other authentication mechanism that uses passwords...
gjsman-1000 5y ago
"Stop passing plain passwords over the wire." If you are using HTTPS, you are equally as good as any other login form. Some have suggested using JavaScript to encrypt passwords before send - but in my opinion, this is generally stupid because it breaks support on browsers without JavaScript, and this doesn't protect you from the server at all because a hacker could just change the JavaScript to send plaintext copies somewhere. You are reliant on the server being a source of truth either way.
- oconnore 5y ago
  No, it would be much better to use a zero knowledge proof (typically called a PAKE — password authenticated key agreement) to demonstrate that the user knows their password without sending that password over the channel. Sending the password over HTTPS doesn’t expose the password to passive observers, but it does unnecessarily expose the password to the server. https://en.m.wikipedia.org/wiki/Password-authenticated_key_agreement https://en.m.wikipedia.org/wiki/Password-authenticated_key_a...
  - thrashh 5y ago
    But most login forms don’t do that anyway so it wouldn’t be any worse than how things are already done.
  - gjsman-1000 5y ago
    > "but it does unnecessarily expose the password to the server" Yes - it does - but I am having a hard time thinking that this actually matters in the real world. I can understand why not sending the password to the server, would be theoretically more secure. However in practice, what hacking attempts does this actually prevent? If I was a hacker, I can add JavaScript to send plaintext somewhere. If I was a hacker, I could change the login form to stop hashing them client-side and instead send them over to the server for hashing and inspection. It's theoretically more secure... but against what? Accidental logging? I mean, I guess, but then just set up your logs correctly instead of breaking login for anyone without JavaScript. In my opinion, client-side hashing is security theater. It sounds impressive, but it doesn't really stop any real-world attacks, and the attacks it does prevent can be prevented using simpler methods. Ironically, the other methods (i.e. making sure your logs are clean) are so much simpler to implement it's probably more secure than trying to build a secure client-hashing implementation in the first place.
vbezhenar 5y ago
I don't really see it simplifying a lot of internet. Everyone will make his custom login page anyway, you need to add links to registration, password recovery and so on. And sending password on every request, hashed or not, is just bad security, you need session token anyway.
- adolph 5y ago
  I think second party controls are probably the reason why browser intermediated login was never pursued until the present era of password management--the browser is a third party that can facilitate/intermediate communication between the first party (user) and second party (website). It would be foolish for a website operator to hand their users over to Microsoft back in the day, just as "social login" is a convenience/optimization trap today.
- ClumsyPilot 5y ago
  "you need to add links to registration, password recovery and so on" All of which could be easilly standardized
adamzochowski 5y ago
One of my favourite auth is the NTLM/SSPI which came out of the the windows NTLM world. Users don't even see they are being asked to be authenticated, they are either logged in, or told they don't have access. Works great in corporate world.
- RedShift1 5y ago
  I love it too, when it works... When it doesn't, the users get the login prompt like the basic auth one, which can be confusing because you have no opportunity to add information to that prompt.
- marcosdumay 5y ago
  Yeah, users aren't asked about anything, the browser just sends their passwords to whoever asks. The SSPI part is good, it just uses kerberos. But the full set can be downgraded at any time by the server.
- deleted 5y ago
  [deleted]
deleted 5y ago
[deleted]
merlinscholz 5y ago
Please do not add logo customization. This will end with prompts asking you for your Apple and Microsoft passwords which are difficult to differentiate from official prompts (at least for end users).
- cobbzilla 5y ago
  What if the icons are NFTs with automated browser verification? I’m only half joking— could this actually be doable?
  - Kalium 5y ago
    Verification of what, precisely? That it's authorized for the domain it's on? This seems like a re-implementation of existing access control systems, with the same weakness of being vulnerable to being copied. Unless you're somehow able to get everyone to transition at once, never support a non-NFT fallback and, ensure that no sufficiently visually similar logo ever gets registered... which IMO sounds both challenging and like a hacky re-implementation of a trademark system.
    - cobbzilla 5y ago
      This would be verification that any branding on the HTTP Basic Auth popup represents the company it claims to. This would be optional — any site that didn’t use this would still have the default (generic/unbranded) browser behavior. The stated (and valid) concern is that malicious actors would use fraudulent branding on those browser auth popups — let’s tell the user we are MSFT or AAPL and steal their password. One solution is for the branding to consist entirely of NFT assets that can all be tracked to a definitive owner, and use some DNS-based glue (ala DKIM/SPIF for email) to link the NFT to the TLD. Then your browser can refuse to show the MSFT logo (and show a big red fraud alert page) if the owner of the branding can’t be reliably traced back to Microsoft (owner of the site).
      - Kalium 5y ago
        At this point you're talking about checking a signature. Naively, it seems to me like you could skip the NFT entirely and embed a verifiable sig in a securely delivered DNS record. Then it's linked to the domain. You can do this now, with tooling that already exists and is deployable today. You'd need to deliver the record securely to avoid attacks on the glue anyway. Of course, neither the NFT nor the sig-in-DNS approach actually solves the problem of a visually identical but technically different image (use a slightly different color in a few places, etc.) being used to trick people. I'm not sure what we've gained. The malicious use case would seem like it's not effectively prevented.
fzzt 5y ago
There's a lot more to that. A bank doesn't want the "back" button to work forever; they want to control the lifetime of your session, ideally on the server. Google wants to let you sign into multiple accounts on the same origin. Many others want to have seamless single sign-on across several of their web properties. Sometimes, you want the change of your password to invalidate other sessions (say, when recovering a compromised account); other times, you don't want to kick out your smart thermostat and have to set it up from scratch. Admittedly, there are some simple use cases where HTTP auth is all you need, but it's just way too inflexible, unless you turn it into some mammoth spec that is never going to be as flexible and tempting as managing user identity yourself. Especially since HTTP auth doesn't actually mean you can stop doing that anyway. You're still handling account creation, password checking, all the abuse / bot detection bits... all you're getting rid of is the sign-on and logout functionality, which is really not that complicated to begin with.
- madacol 5y ago
  Maybe we don't want them to be able to do any of that And I think you are missing the point, the goal it's not to standardize logins, it's about making impossible for servers to know my password, hence impossible passwords leaks That would allow people to reuse strong passwords, and not need passwords managers, because that's what they are doing anyway!
  - fzzt 5y ago
    > Maybe we don't want them to be able to do any of that "We" who? Application owners want that, browser vendors want that (their greatest fear is that mobile will eat the web, so they don't want to make the platform less flexible)... and users generally don't mind. > impossible for servers to know my password, hence impossible passwords leaks That would require deeper architectural changes to HTTP auth, but is probably a reasonable goal. That said, it's more readily approximated with unique passwords + having a good password manager. The main risk of password leaks is not that they make that particular breach worse (since the attackers can just grab your data), but that passwords are reused too often. Federated login is another approximation, where the password is only known to your identity provider, not to every identity consumer. It's modestly successful for some lower-value services.
jstummbillig 5y ago
> It's not a massive amount of work Oh, sweet summer child
mooreds 5y ago
> Add a button to log out. Logout never really worked across browsers with basic auth. In my experience, the way to logout is to close the browser. Is this standardized anywhere? > Allow to inject a logo or a tiny bit of customization for branding. The default popup looks too ugly. I think that this would be nice, but most anyone who wants customization will want to control everything, and wouldn't be a fit for the limits of basic auth. > Improve the Digest auth to modern crypto standards. Stop passing plain passwords over the wire. As others have mentioned, TLS helps with this, but I agree that it would be a good idea to hash it anyway. Have you thought about submitting these improvements to chromium and firefox (as feature requests)?
LinAGKar 5y ago
Digest auth is fundamentally less secure, as it requires the server to have access to the plain text password, whereas with basic auth you can store it salted and hashed. And you should be using HTTPS regardless.
alerighi 5y ago
Agree with everything beside the third point. The argument of passing plain password over the wire doesn't make sense: every login form when you submit it passes username and password over the wire! Nobody encrypts the passwords client side.
mmcnl 5y ago
I agree. And also deprecate basic auth over unencrypted connections.
drdaeman 5y ago
> Improve the Digest auth to modern crypto standards There is https://datatracker.ietf.org/doc/html/draft-yusef-httpauth-srp-scheme-01 https://datatracker.ietf.org/doc/html/draft-yusef-httpauth-s... but looks like it had never gained any traction. And most likely won't, because browser vendors seem to be extremely reluctant to do anything but deprecate all those standard UIs in favor of messed up JS APIs.
dpweb 5y ago
Upon account creation or reset, can't the user select a password, that hashed as the private key for a keypair and just the public sent to the server? Then when logging in they just sign a challenge on the client. Only thing stored is a users public key on the server.
1vuio0pswjnm7 5y ago
Perhaps it would be even more useful if so-called "modern" browsers implemented SRP support. Some would agree SRP is better than HTTP Basic Authentication. https://web.archive.org/web/20210422025330if_/http://srp.stanford.edu/analysis.html https://web.archive.org/web/20210422025330if_/http://srp.sta... SRP allows for TLS without server (or client) certificates. The presence of the verifier on the server provides authentication. No passwords are sent over the wire. The conventional use for SRP is a replacement for weak passwords (e.g., HTTP Authentication), but what would stop SRP from being used in some cases as a replacement for server certificates even where a website is public (no passwrd required). With SRP, the user becomes the one who is in control of "trust", not a third party certificate issuer or browser vendor. The user decides whether to send a verifier to a website operator.
p4bl0 5y ago
Another thing that's missing is multiple credentials stored in by the browser. With HTML login forms browsers can offer multiple choice of autocompletion with stored credentials. With Basic HTTP auth it doesn't work, it only offers the first one and you have to type both the login and the password manually for other accounts even if your browsers knows about them.
nirui 5y ago
Is there any chance to go even further than this? I'm imaging a public key based authentication scheme. The user submit their public key to the server first, then in the feature logins, server will generate a challenge for client to decrypt and respond. Of course the browser can apply some UX magic at the client end, for example displaying a pop window to allow user to select a public key for the authentication process, etc.
- andreareina 5y ago
  Isn't that basically client certificates?
- jannes 5y ago
  Sounds like client certificates. I guess you have never used those. All major browsers support them. In Firefox you can find them here: Settings -> Privacy & Security -> View Certificates -> Your Certificates
  - nirui 5y ago
    Yes, but the advantage is that the user sends their own public keys and they can switch it freely (and preferably easily, user click "login", a window pop up, user select a public key, done) at will. While client certificates is currently managed fully by the browser, and you need to adjust your HTTPS infrastructure in order to enable the feature.
IgorPartola 5y ago
Don’t even stop there. Instead of typing in a username and password, have my browser give me a drop down with my identities so I can use just one of them. Then have the browser sync my (encrypted with my pass phrase) identities across all my browsers/devices. No more passwords.
- speedgoose 5y ago
  I think this is already implemented with HTTPS but very rarely used.
moltar 5y ago
* password manager support
cookiengineer 5y ago
Imagine a HTTP Basic Auth workflow that has another "Token: ..." header that is based on TOTP. This would help make things so much better compared to what's the situation right now. The stuff we see nowadays is mostly hacks that upgrade legacy systems with things like "the password is actually your-password#token" and "oh yeah, if you use # in your password, it crashes the server ... so don't do that". Something like a standardized HTTP-based authentication workflow (Basic Auth + maybe parts of the Web AuthN spec) could make things so much easier in regards to maintainability. Then we could finally get rid of stupid workarounds like JWT which weren't designed for this purpose.
- fulafel 5y ago
  That wouldn't be basic authentication any more which is by definition username+password. HTTP currently already supprots other authentication types besides basic auth, such as digest and bearer authentication. Bearer is rather close to what you describe.

slim 5y ago

Stop passing plain passwords over the wire this is already solved by https

deleted 5y ago
[deleted]
lukevp 5y ago
Only partially. If the client and server have an agreement on a hashing protocol, there’s no reason that the browser shouldn’t be able to hash as well and prevent the password from ever leaving memory on the client system. HTTPS is still vulnerable to many man in the middle attacks, and many corporate and business networks do deep packet inspection to decrypt https (they control the machines so intercepting the cert issuance and installing their own root CA is easily doable). Another issue is that improper logging on the server (or depending on the implementation, even intermediate load balancers) could accidentally leak the plaintext password. Client side hashing is a much better solution to this, and if it’s a native browser supported protocol, it would even work without JS.
- ncann 5y ago
  How do you do client side hashing without the server sending the salt/pepper to the client, which is a really bad thing?
  - notfed 5y ago
    There are answers to this. I asked myself this a few years ago, which led recursively to new tricky questions. I eventually solved the tree of the questions: I designed myself into a solution that I later realized was essentially an asymmetric PAKE (e.g., analogous to OPAQUE). So, an attempt to solve your question eventually leads to using an asymetric PAKE. But, this is way, way more complex. You'd really have to squint your eyes to believe that the diminishing returns are worth it.
- axiosgunnar 5y ago
  Your suggestion is vulnerable to the https://en.m.wikipedia.org/wiki/Pass_the_hash https://en.m.wikipedia.org/wiki/Pass_the_hash attack. Your suggestion is basically going back to the days where databases stored plaintext passwords in the database, just that the plaintext happens to be a hash.
- lixtra 5y ago
  > If the client and server have an agreement on a hashing protocol, there’s no reason that the browser shouldn’t be able to hash as well and prevent the password from ever leaving memory on the client system. Shouldn’t it be a proper challenge/response? Otherwise the hash is barely better than the password.
- jeroenhd 5y ago
  What does it matter? If a criminal gains the hash, they can log in and be malicious anyway. If a criminal can do a MitM, they can substitute the Javascript that's hashing your password with all the nonces and salts and peppers you add to it and send the password anyway. If you just hash the password, the hash becomes the password. You're not solving the problem that way, you're just switching around definitions. There is an alternative that's supported in most platforms, and that's WebAuthn. Not even a need for a password automatic secure handshakes and with the right protocols, the keys differ per site so they're very hard to spoof through phishing. You can achieve much of the same thing with client TLS certificates, but the UX for that is even worse than the UX for HTTP Basic.
  - staticassertion 5y ago
    > What does it matter? If a criminal gains the hash, they can log in and be malicious anyway. To that one site. But users reuse passwords and if a criminal only has a hash they can't reuse it across sites.
    - jeroenhd 5y ago
      But the attacker controls the TLS connection already, so they'll just strip out the hashing functionality or send a piece of JS to steal the password directly from the password field. It's not that I don't understand where you're coming from (I once almost started writing such a library a few years back!), but I just can't think of a threat model where this makes sense. That's also what moved me away from working on such a system. To me, this approach feels like an attempt to recreate software-only U2F, but outside the browser. I don't think client side code can fix these problems. It can make stealing passwords more difficult for criminals if every website uses their own bespoke password processing script, but that'll also add a huge attack surface to your code and it'll be a burden to maintain.
      - staticassertion 5y ago
        I don't know why people are assuming the attacker: A) Controls the code running the auth API B) Controls the javascript As if that's the common attack. The common attack is that the attacker has a read on the hash, either through injection vulnerabilities or other leaks. Your attacker, as described, has remote code execution on a server that hosts the auth API and the Javascript in one place. That is a very specific, powerful attacker! > but I just can't think of a threat model where this makes sense 1. An attacker has CSRF and can trick your code into sending the hash to them. This significantly reduces the harm of that attack. 2. An attacker has an injection vulnerability giving them read access to hashes ie: sql injection, perhaps the most significant and relevant attack to discuss with passwords. 3. An attacker takes advantage of a timing attack, bruteforcing the server and measuring response times to leak its value. They can now only leak the hashed value, which is going to take way longer to leak and doesn't expose their password. And more! This defense tackles what are very very arguably the major threats to consider with regards to password security (they're the big ones in OWASP top 10). > It can make stealing passwords more difficult for criminals if every website uses their own bespoke password processing script, but that'll also add a huge attack surface to your code and it'll be a burden to maintain. You can significantly reduce harm and attack surface with all of 3 lines in your frontend code. salt = hash(username + static_salt) password_hash = pbkdf2(plaintext_password, salt) it's trivial to implement this. I'll grant you that PAKEs may be more complex to implement today, but even if we talk about a very basic implementation of client side hashing I think there's obvious value.
StefanKarpinski 5y ago
The password is still revealed to the server. There are password verification protocols where the password is not revealed to the server either, which is much more secure as it means that you’re not at the mercy of whether the sever operator follows good security practices about not saving your password in plain text somewhere.
- thaumasiotes 5y ago
  > There are password verification protocols where the password is not revealed to the server either, which is much more secure as it means that you’re not at the mercy of whether the sever operator follows good security practices about not saving your password in plain text somewhere. Well, the most common such protocol is TOTP, which still requires the server to store your full password. In that sense it's worse than a naive password exchange, which only requires the server to store your hashed password. There are other password protocols that require neither transmission nor server retention of the full password, but it seems worth noting that the protocol we actually have didn't bother with that.
  - teekert 5y ago
    Does it matter if the pw is stored salted and hashed?
    - thaumasiotes 5y ago
      Yes, that's why we do that. I'm not sure what you want to ask.
- LinAGKar 5y ago
  >The password is still revealed to the server. And with digest auth, the server must have the plain text password already. But sure, maybe there is a third option.
- alerighi 5y ago
  As every other login form does. In this situation basic authentication is no different from every other authentication mechanism that uses passwords...

gjsman-1000 5y ago

"Stop passing plain passwords over the wire." If you are using HTTPS, you are equally as good as any other login form. Some have suggested using JavaScript to encrypt passwords before send - but in my opinion, this is generally stupid because it breaks support on browsers without JavaScript, and this doesn't protect you from the server at all because a hacker could just change the JavaScript to send plaintext copies somewhere. You are reliant on the server being a source of truth either way.

oconnore 5y ago
No, it would be much better to use a zero knowledge proof (typically called a PAKE — password authenticated key agreement) to demonstrate that the user knows their password without sending that password over the channel. Sending the password over HTTPS doesn’t expose the password to passive observers, but it does unnecessarily expose the password to the server. https://en.m.wikipedia.org/wiki/Password-authenticated_key_agreement https://en.m.wikipedia.org/wiki/Password-authenticated_key_a...
- thrashh 5y ago
  But most login forms don’t do that anyway so it wouldn’t be any worse than how things are already done.
- gjsman-1000 5y ago
  > "but it does unnecessarily expose the password to the server" Yes - it does - but I am having a hard time thinking that this actually matters in the real world. I can understand why not sending the password to the server, would be theoretically more secure. However in practice, what hacking attempts does this actually prevent? If I was a hacker, I can add JavaScript to send plaintext somewhere. If I was a hacker, I could change the login form to stop hashing them client-side and instead send them over to the server for hashing and inspection. It's theoretically more secure... but against what? Accidental logging? I mean, I guess, but then just set up your logs correctly instead of breaking login for anyone without JavaScript. In my opinion, client-side hashing is security theater. It sounds impressive, but it doesn't really stop any real-world attacks, and the attacks it does prevent can be prevented using simpler methods. Ironically, the other methods (i.e. making sure your logs are clean) are so much simpler to implement it's probably more secure than trying to build a secure client-hashing implementation in the first place.

vbezhenar 5y ago

I don't really see it simplifying a lot of internet. Everyone will make his custom login page anyway, you need to add links to registration, password recovery and so on. And sending password on every request, hashed or not, is just bad security, you need session token anyway.

adolph 5y ago
I think second party controls are probably the reason why browser intermediated login was never pursued until the present era of password management--the browser is a third party that can facilitate/intermediate communication between the first party (user) and second party (website). It would be foolish for a website operator to hand their users over to Microsoft back in the day, just as "social login" is a convenience/optimization trap today.
ClumsyPilot 5y ago
"you need to add links to registration, password recovery and so on" All of which could be easilly standardized

adamzochowski 5y ago

One of my favourite auth is the NTLM/SSPI which came out of the the windows NTLM world. Users don't even see they are being asked to be authenticated, they are either logged in, or told they don't have access. Works great in corporate world.

RedShift1 5y ago
I love it too, when it works... When it doesn't, the users get the login prompt like the basic auth one, which can be confusing because you have no opportunity to add information to that prompt.
marcosdumay 5y ago
Yeah, users aren't asked about anything, the browser just sends their passwords to whoever asks. The SSPI part is good, it just uses kerberos. But the full set can be downgraded at any time by the server.
deleted 5y ago
[deleted]

deleted 5y ago

[deleted]

merlinscholz 5y ago

Please do not add logo customization. This will end with prompts asking you for your Apple and Microsoft passwords which are difficult to differentiate from official prompts (at least for end users).

cobbzilla 5y ago
What if the icons are NFTs with automated browser verification? I’m only half joking— could this actually be doable?
- Kalium 5y ago
  Verification of what, precisely? That it's authorized for the domain it's on? This seems like a re-implementation of existing access control systems, with the same weakness of being vulnerable to being copied. Unless you're somehow able to get everyone to transition at once, never support a non-NFT fallback and, ensure that no sufficiently visually similar logo ever gets registered... which IMO sounds both challenging and like a hacky re-implementation of a trademark system.
  - cobbzilla 5y ago
    This would be verification that any branding on the HTTP Basic Auth popup represents the company it claims to. This would be optional — any site that didn’t use this would still have the default (generic/unbranded) browser behavior. The stated (and valid) concern is that malicious actors would use fraudulent branding on those browser auth popups — let’s tell the user we are MSFT or AAPL and steal their password. One solution is for the branding to consist entirely of NFT assets that can all be tracked to a definitive owner, and use some DNS-based glue (ala DKIM/SPIF for email) to link the NFT to the TLD. Then your browser can refuse to show the MSFT logo (and show a big red fraud alert page) if the owner of the branding can’t be reliably traced back to Microsoft (owner of the site).
    - Kalium 5y ago
      At this point you're talking about checking a signature. Naively, it seems to me like you could skip the NFT entirely and embed a verifiable sig in a securely delivered DNS record. Then it's linked to the domain. You can do this now, with tooling that already exists and is deployable today. You'd need to deliver the record securely to avoid attacks on the glue anyway. Of course, neither the NFT nor the sig-in-DNS approach actually solves the problem of a visually identical but technically different image (use a slightly different color in a few places, etc.) being used to trick people. I'm not sure what we've gained. The malicious use case would seem like it's not effectively prevented.

fzzt 5y ago

There's a lot more to that. A bank doesn't want the "back" button to work forever; they want to control the lifetime of your session, ideally on the server. Google wants to let you sign into multiple accounts on the same origin. Many others want to have seamless single sign-on across several of their web properties. Sometimes, you want the change of your password to invalidate other sessions (say, when recovering a compromised account); other times, you don't want to kick out your smart thermostat and have to set it up from scratch. Admittedly, there are some simple use cases where HTTP auth is all you need, but it's just way too inflexible, unless you turn it into some mammoth spec that is never going to be as flexible and tempting as managing user identity yourself. Especially since HTTP auth doesn't actually mean you can stop doing that anyway. You're still handling account creation, password checking, all the abuse / bot detection bits... all you're getting rid of is the sign-on and logout functionality, which is really not that complicated to begin with.

madacol 5y ago
Maybe we don't want them to be able to do any of that And I think you are missing the point, the goal it's not to standardize logins, it's about making impossible for servers to know my password, hence impossible passwords leaks That would allow people to reuse strong passwords, and not need passwords managers, because that's what they are doing anyway!
- fzzt 5y ago
  > Maybe we don't want them to be able to do any of that "We" who? Application owners want that, browser vendors want that (their greatest fear is that mobile will eat the web, so they don't want to make the platform less flexible)... and users generally don't mind. > impossible for servers to know my password, hence impossible passwords leaks That would require deeper architectural changes to HTTP auth, but is probably a reasonable goal. That said, it's more readily approximated with unique passwords + having a good password manager. The main risk of password leaks is not that they make that particular breach worse (since the attackers can just grab your data), but that passwords are reused too often. Federated login is another approximation, where the password is only known to your identity provider, not to every identity consumer. It's modestly successful for some lower-value services.

jstummbillig 5y ago

> It's not a massive amount of work Oh, sweet summer child

mooreds 5y ago

> Add a button to log out. Logout never really worked across browsers with basic auth. In my experience, the way to logout is to close the browser. Is this standardized anywhere? > Allow to inject a logo or a tiny bit of customization for branding. The default popup looks too ugly. I think that this would be nice, but most anyone who wants customization will want to control everything, and wouldn't be a fit for the limits of basic auth. > Improve the Digest auth to modern crypto standards. Stop passing plain passwords over the wire. As others have mentioned, TLS helps with this, but I agree that it would be a good idea to hash it anyway. Have you thought about submitting these improvements to chromium and firefox (as feature requests)?

LinAGKar 5y ago

Digest auth is fundamentally less secure, as it requires the server to have access to the plain text password, whereas with basic auth you can store it salted and hashed. And you should be using HTTPS regardless.

alerighi 5y ago

Agree with everything beside the third point. The argument of passing plain password over the wire doesn't make sense: every login form when you submit it passes username and password over the wire! Nobody encrypts the passwords client side.

mmcnl 5y ago

I agree. And also deprecate basic auth over unencrypted connections.

drdaeman 5y ago

> Improve the Digest auth to modern crypto standards There is https://datatracker.ietf.org/doc/html/draft-yusef-httpauth-srp-scheme-01 https://datatracker.ietf.org/doc/html/draft-yusef-httpauth-s... but looks like it had never gained any traction. And most likely won't, because browser vendors seem to be extremely reluctant to do anything but deprecate all those standard UIs in favor of messed up JS APIs.

dpweb 5y ago

Upon account creation or reset, can't the user select a password, that hashed as the private key for a keypair and just the public sent to the server? Then when logging in they just sign a challenge on the client. Only thing stored is a users public key on the server.

1vuio0pswjnm7 5y ago

Perhaps it would be even more useful if so-called "modern" browsers implemented SRP support. Some would agree SRP is better than HTTP Basic Authentication. https://web.archive.org/web/20210422025330if_/http://srp.stanford.edu/analysis.html https://web.archive.org/web/20210422025330if_/http://srp.sta... SRP allows for TLS without server (or client) certificates. The presence of the verifier on the server provides authentication. No passwords are sent over the wire. The conventional use for SRP is a replacement for weak passwords (e.g., HTTP Authentication), but what would stop SRP from being used in some cases as a replacement for server certificates even where a website is public (no passwrd required). With SRP, the user becomes the one who is in control of "trust", not a third party certificate issuer or browser vendor. The user decides whether to send a verifier to a website operator.

p4bl0 5y ago

Another thing that's missing is multiple credentials stored in by the browser. With HTML login forms browsers can offer multiple choice of autocompletion with stored credentials. With Basic HTTP auth it doesn't work, it only offers the first one and you have to type both the login and the password manually for other accounts even if your browsers knows about them.

nirui 5y ago

Is there any chance to go even further than this? I'm imaging a public key based authentication scheme. The user submit their public key to the server first, then in the feature logins, server will generate a challenge for client to decrypt and respond. Of course the browser can apply some UX magic at the client end, for example displaying a pop window to allow user to select a public key for the authentication process, etc.

andreareina 5y ago
Isn't that basically client certificates?
jannes 5y ago
Sounds like client certificates. I guess you have never used those. All major browsers support them. In Firefox you can find them here: Settings -> Privacy & Security -> View Certificates -> Your Certificates
- nirui 5y ago
  Yes, but the advantage is that the user sends their own public keys and they can switch it freely (and preferably easily, user click "login", a window pop up, user select a public key, done) at will. While client certificates is currently managed fully by the browser, and you need to adjust your HTTPS infrastructure in order to enable the feature.

IgorPartola 5y ago

Don’t even stop there. Instead of typing in a username and password, have my browser give me a drop down with my identities so I can use just one of them. Then have the browser sync my (encrypted with my pass phrase) identities across all my browsers/devices. No more passwords.

speedgoose 5y ago
I think this is already implemented with HTTPS but very rarely used.

moltar 5y ago

* password manager support

cookiengineer 5y ago

Imagine a HTTP Basic Auth workflow that has another "Token: ..." header that is based on TOTP. This would help make things so much better compared to what's the situation right now. The stuff we see nowadays is mostly hacks that upgrade legacy systems with things like "the password is actually your-password#token" and "oh yeah, if you use # in your password, it crashes the server ... so don't do that". Something like a standardized HTTP-based authentication workflow (Basic Auth + maybe parts of the Web AuthN spec) could make things so much easier in regards to maintainability. Then we could finally get rid of stupid workarounds like JWT which weren't designed for this purpose.

fulafel 5y ago
That wouldn't be basic authentication any more which is by definition username+password. HTTP currently already supprots other authentication types besides basic auth, such as digest and bearer authentication. Bearer is rather close to what you describe.