11 ms·

Using www-authenticate for user authentication

75 points by blmayer 5y ago

ale42 5y ago
Funny that old things like basic HTTP auth are regularly rediscovered by developers. There are also other flavours of authentication that can be used in this context, like Digest, supported by all major browsers and only sending hashed passwords (even on plain http connections).
- boondaburrah 5y ago
  I looked it up and the apache manual apparently recommends HTTP basic over SSL instead of Digest these days since apparently the extra protection isn't considered as worth it relative to just HTTPS-ing the connection.
- jamespwilliams 5y ago
  Digest auth itself isn't very good though really, even ignoring the obvious problems of not using HTTPS. In the most secure configuration of digest auth, the server stores MD5(username:realm:password), and to authenticate, the server sends server_nonce, and the client sends back client_nonce and MD5(MD5(username:realm:password):server_nonce:client_nonce). The nonces are used to avoid a replay attack. The server MD5s its stored hash with server_nonce:client_nonce and checks if it matches against what the client sent. But if those stored hashes get leaked, an attacker can use them to authenticate. You're in a better position than storing plaintext passwords, because the underlying cleartext probably won't be leaked (they're hashed with MD5, so it's not certain), so your users' credentials can't be used in future credential stuffing attacks, etc. But the attacker still has their credentials on your site. In the other configurations of digest auth, the server ends up storing plaintext passwords (or reversably-encrypted passwords, which is just as bad). See also https://en.wikipedia.org/wiki/Digest_access_authentication#Disadvantages https://en.wikipedia.org/wiki/Digest_access_authentication#D... Using HTTPS + Basic Auth is far more secure, and (arguably) easier at this point.
  - bullen 5y ago
    I don't understand your point, if the database is leaked the security is compromised... well yes red is red, and green is green and HTTPS improves NOTHING of that. HTTPS is a huge waste of electricity. A more frugal way of securing logins is to use this RFC: https://datatracker.ietf.org/doc/html/rfc2289 https://datatracker.ietf.org/doc/html/rfc2289 Registrations would need additional security but HTTPS with centralized root certificates is NOT one of them.
    - jamespwilliams 5y ago
      Do you agree that storing passwords in plain text is a problem? My point is that storing passwords in a way compatible with using Digest authentication is essentially equivalent to storing your passwords in plain text, at least with respect to your own site’s authentication.
      - bullen 5y ago
        You don't store them as plain text, you store them as hashes. And then you send a server salt/nonce and the browser hashes the plain text password with the salted hash in your database and then with the server salt/nonce. Still HTTPS solves nothing of that. I don't even know what Digest is... I'm talking this RFC: https://datatracker.ietf.org/doc/html/rfc2289 https://datatracker.ietf.org/doc/html/rfc2289
    - thayne 5y ago
      You shouldn't store a password in plaintext in your database. So if your database is leaked, they don't have the user's actual passwords. But with the digest scheme, you can't store a hash of the digest, because if all you have is Hash2(Hash1(username:realm:password)) and the nonces, then you can't compute Hash1(Hash1(username:realm:password):server_nonce:client_nonce), assuming that Hash2 is irreversible, which you want it to be.
      - bullen 5y ago
        > Hash1(Hash1(username:realm:password):server_nonce:client_nonce) client_nonce? This is how the RFC works: Hash(Hash(username:password):server_nonce) What is the difference between Hash1 and Hash2? Hash(username:password) is what you store in the database != plain text. Also what is realm?
- deleted 5y ago
  [deleted]
- bullen 5y ago
  A long time ago we had to work around disabled cookies by appending the session to every request URL... that was a fun time adding the session to all those <a href>... But for the simple hashing it's an old RFC that I like to quote to HTTPS fools: https://datatracker.ietf.org/doc/html/rfc2289 https://datatracker.ietf.org/doc/html/rfc2289 Way better login than moving your whole site, including cat pictures, to encryption.
  - AtlasBarfed 5y ago
    OMG, do you know how hard it was back in the early cHTML/WML/HDML days and dozens of different browsers? Glad that was a temporary state of things.
simonw 5y ago
I always thought you couldn't implement logout with HTTP basic auth, but according to this: > logging out is done by simply returning a 401 without www-authenticate header I did not know that worked!
0xbadcafebee 5y ago
I see an authentication pop-up and groan. If I leave it there it'll time out, if I hit 'escape' or my login fails I'll get some generic HTTP server error screen. No password reset box, no contact form, no OAuth/SSO login button.
- lil_dispaches 5y ago
  Hm, why have browser vendors neglected the UX for this standard, no-cookie auth method? Why is there no corresponding markup in HTML5?
  - thesuitonym 5y ago
    It happens in HTTP, before any HTML5 is rendered or even sent. Why have browser vendors neglected it? I suppose it's a chicken/egg problem. Nobody really uses it, so why spend effort on it? No effort is spent on it, so it's stuck in the 90s, why would anyone use it?
  - munk-a 5y ago
    There isn't anything in the standard to support a "Go here to reset your password" link or a "Go over here to create an account" - I really appreciate HTTP auth for somethings - but it's not great if you don't have a user base that is registered for your site through some non-web based interaction. It's certainly possible to have a user creation flow that ends up auth'ing with Basic Auth but it's not particularly user friendly.
    - jeroenhd 5y ago
      The browser could redirect the user to a form after cancellation or a certain amount of failures (say, 3 or 5) with recovery options. Add a nice retry button on there and you've got yourself a very simple login flow. Stock nginx/apache configurations will basically let the user retry infinitely or show a plain error page after user authentication fails too often, but these pages are configurable and don't need to be handled by the web server itself. One thing this mechanism doesn't provide is brute force protection through systems like CAPTCHAs.
asadawadia 5y ago
what a coincidence I just wrote about this last night on my blog - https://blog.aawadia.dev/2022/02/17/basic-auth-with-javalin/ https://blog.aawadia.dev/2022/02/17/basic-auth-with-javalin/
irq-1 5y ago
If this is new to you, you can also include the username and password in the url: https://user@example.com/page https://user@example.com/page https://user:pass@example.com/page https://user:pass@example.com/page
- djbusby 5y ago
  I've noticed many times the browser won't send those from the link. I was trying that with services where I owned both sides and my pre-authenticated links weren't sending the credentials. But using the same URL via curl was authenticated.
  - jjice 5y ago
    I believe the major browsers deprecated this a little while ago. You can still use basic auth and everything, just not via a URL like this.
  - remram 5y ago
    On Firefox, I just get a warning: "You are about to log in to the site “news.ycombinator.com” with the username “test”" I'm not entirely sure what the concern is to be honest. If it's tracking, this doesn't provide anything on top of query parameters e.g. ?utm_campaign=
    - sethaurus 5y ago
      The concern is about phishing via URL spoofing. For example, a user might see a URL like `google.com@mycoolphishingsite.se` and believe that "google.com" is the domain. The warning is intended to point out that "mycoolphishingsite.se" is the real domain.
- gwbas1c 5y ago
  The problem is that many proxies will log passwords sent this way.
  - caylus 5y ago
foreigner 5y ago
Why is this preferable to authentication using cookies?
- mrtesthah 5y ago
  The web server can directly handle your authentication and accounting system rather than needing to include more huge middleware frameworks.
  - n0w 5y ago
    Why would `Authentication` be any different to `Cookie` in this regard? They're both HTTP headers. They both require server side support/implementation. Neither explicitly requires JavaScript. The only difference I can see is that the browser has a native control for one of them, though that control cannot be customised by the site.
  - munk-a 5y ago
    Just to clarify - are you calling cookie support a huge middleware framework? Both BasicAuth and Cookie reception are features included in nearly every browser offering - it's generally how you actually check resource authorization that's the hard part of Auth - the actual technical "Get a cookie from a browser" and "Check the BasicAuth headers" portions are pretty simple - in fact getting a cookie is arguably easier in most cases. Especially since a popular serverside programming language (PHP) has streamlined session handling to the point that most programmers going from it to other serverside languages get confused when there isn't a $_SESSION equivalent that you just inspect with the tap of a button.
    - mrtesthah 5y ago
      Note that I said “authentication and accounting system”. You just described a very small part of that functionality. It’s the reason people adopt large frameworks like Django, and why PHP’s session management alone is insufficient. You can look at functionality like Apache’s mod_authnz_ldap as an example of built in account management that integrates with HTTP basic auth. https://httpd.apache.org/docs/2.4/mod/mod_authnz_ldap.html https://httpd.apache.org/docs/2.4/mod/mod_authnz_ldap.html
jeroenhd 5y ago
Looking at the MDN page [1], I noticed that SHA2-256 digest authentication was added relatively recently to Firefox (and Firefox for Android). I wonder why they added it, as no other browser manufacturer seems to care and the added benefit of using digest rather than basic auth is only minimal now that every decent website has TLS. Also, interestingly, the support matrix suggests that Firefox for Android supports Kerberos and NTLM authentication. I guess I never expected Kerberos for websites to show up outside of desktop browsers. [1]: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/WWW-Authenticate https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/WW...
TonyTrapp 5y ago
I won't get tired of mentioning this - the basic authentication dialog should show a message from the server that is supposed to inform you what kind of credentials to enter. This is super useful for intranets, spam prevention systems and other stuff. Chrome removed this message years ago because of a dubious security report, and Firefox appears to have finally given in and removed it as well. All because someone could MITM your connection and present a login prompt à la "please enter your YouTube credentials" (completely ignoring that if they MITM you, they could serve you a page that really looks like a login page). This change completely ruined the usability of basic authentication.
- deleted 5y ago
  [deleted]
- Kwpolska 5y ago
  I found the bug you’re talking about: https://bugs.chromium.org/p/chromium/issues/detail?id=544244 https://bugs.chromium.org/p/chromium/issues/detail?id=544244 The MITM part is, in my opinion, an unimportant invention of the original reporter. The change was made because the basic auth dialog is part of the browser chrome (i.e. UI not part of web pages). This UI often looks like part of the browser/OS (especially in legacy IE, but modern browsers also show it differently, with the dialog partially obscuring the bookmarks toolbar. You don’t need a MITM attack for this to go wrong, all you need is a rogue ad or something redirecting you to the attacker’s site. Users might think “the dialog is asking me for my Google password, and it’s presented by the Google Chrome browser, so it’s got to be legitimate.”
  - TonyTrapp 5y ago
    That is true, but let's also not forget that the bug title is "HTTP basic auth credentials prompt should make the origin stand out more" and nothing has been done about this in the last 7 years. Instead of making it stand out that the text is coming from the server, they just removed it completely. I found the original prompt to be pretty clear already ("the server asks for a username and password, it says: ...") but I'm sure in all these years they could have brought it back and made it more obvious that it's not Chrome asking for these things.
cjm42 5y ago
The big problem with this is that mobile Safari on iOS won't autofill passwords for sites using WWW-Authenticate. It used to, but that feature got dropped years ago, which really ticks me off, as I regularly use a couple of sites that use it.
jonahbenton 5y ago
Having to do an authentication check on every request is suboptimal, but ok in many cases. It's just very unfortunate that more protocol explicitly directing secure interactions between the user and the user-agent in managing identity and authentication never really emerged.
remram 5y ago
I don't understand why "no cookies" is listed under "pros". This works exactly like a session cookie (a header attached to every request to the domain), the only difference is that the header contains your actual plain-text credentials instead of a token. It is at most as secure/safe/non-invasive as a cookie, and in a lot of situation, a lot less. The obvious way to improve it would be to offer a way for the browser to load a custom form to authenticate and get the (hashed) credentials to present to the original website in the header. And then you have recreated session cookies in full.
password4321 5y ago
There's also NTLM and Negotiate (Kerberos). https://caniuse.com/?search=www-authenticate https://caniuse.com/?search=www-authenticate
cirrus3 5y ago
What is the deal with no capitalization? It is distracting because it is almost as if the writer went out of their way to do this while leaving most other grammar intact.

75 points by blmayer 5y ago

Funny that old things like basic HTTP auth are regularly rediscovered by developers. There are also other flavours of authentication that can be used in this context, like Digest, supported by all major browsers and only sending hashed passwords (even on plain http connections).

boondaburrah 5y ago
I looked it up and the apache manual apparently recommends HTTP basic over SSL instead of Digest these days since apparently the extra protection isn't considered as worth it relative to just HTTPS-ing the connection.
jamespwilliams 5y ago
Digest auth itself isn't very good though really, even ignoring the obvious problems of not using HTTPS. In the most secure configuration of digest auth, the server stores MD5(username:realm:password), and to authenticate, the server sends server_nonce, and the client sends back client_nonce and MD5(MD5(username:realm:password):server_nonce:client_nonce). The nonces are used to avoid a replay attack. The server MD5s its stored hash with server_nonce:client_nonce and checks if it matches against what the client sent. But if those stored hashes get leaked, an attacker can use them to authenticate. You're in a better position than storing plaintext passwords, because the underlying cleartext probably won't be leaked (they're hashed with MD5, so it's not certain), so your users' credentials can't be used in future credential stuffing attacks, etc. But the attacker still has their credentials on your site. In the other configurations of digest auth, the server ends up storing plaintext passwords (or reversably-encrypted passwords, which is just as bad). See also https://en.wikipedia.org/wiki/Digest_access_authentication#Disadvantages https://en.wikipedia.org/wiki/Digest_access_authentication#D... Using HTTPS + Basic Auth is far more secure, and (arguably) easier at this point.
- bullen 5y ago
  I don't understand your point, if the database is leaked the security is compromised... well yes red is red, and green is green and HTTPS improves NOTHING of that. HTTPS is a huge waste of electricity. A more frugal way of securing logins is to use this RFC: https://datatracker.ietf.org/doc/html/rfc2289 https://datatracker.ietf.org/doc/html/rfc2289 Registrations would need additional security but HTTPS with centralized root certificates is NOT one of them.
  - jamespwilliams 5y ago
    Do you agree that storing passwords in plain text is a problem? My point is that storing passwords in a way compatible with using Digest authentication is essentially equivalent to storing your passwords in plain text, at least with respect to your own site’s authentication.
    - bullen 5y ago
      You don't store them as plain text, you store them as hashes. And then you send a server salt/nonce and the browser hashes the plain text password with the salted hash in your database and then with the server salt/nonce. Still HTTPS solves nothing of that. I don't even know what Digest is... I'm talking this RFC: https://datatracker.ietf.org/doc/html/rfc2289 https://datatracker.ietf.org/doc/html/rfc2289
  - thayne 5y ago
    You shouldn't store a password in plaintext in your database. So if your database is leaked, they don't have the user's actual passwords. But with the digest scheme, you can't store a hash of the digest, because if all you have is Hash2(Hash1(username:realm:password)) and the nonces, then you can't compute Hash1(Hash1(username:realm:password):server_nonce:client_nonce), assuming that Hash2 is irreversible, which you want it to be.
    - bullen 5y ago
      > Hash1(Hash1(username:realm:password):server_nonce:client_nonce) client_nonce? This is how the RFC works: Hash(Hash(username:password):server_nonce) What is the difference between Hash1 and Hash2? Hash(username:password) is what you store in the database != plain text. Also what is realm?
deleted 5y ago
[deleted]
bullen 5y ago
A long time ago we had to work around disabled cookies by appending the session to every request URL... that was a fun time adding the session to all those <a href>... But for the simple hashing it's an old RFC that I like to quote to HTTPS fools: https://datatracker.ietf.org/doc/html/rfc2289 https://datatracker.ietf.org/doc/html/rfc2289 Way better login than moving your whole site, including cat pictures, to encryption.
- AtlasBarfed 5y ago
  OMG, do you know how hard it was back in the early cHTML/WML/HDML days and dozens of different browsers? Glad that was a temporary state of things.

simonw 5y ago

I always thought you couldn't implement logout with HTTP basic auth, but according to this: > logging out is done by simply returning a 401 without www-authenticate header I did not know that worked!

0xbadcafebee 5y ago

I see an authentication pop-up and groan. If I leave it there it'll time out, if I hit 'escape' or my login fails I'll get some generic HTTP server error screen. No password reset box, no contact form, no OAuth/SSO login button.

lil_dispaches 5y ago
Hm, why have browser vendors neglected the UX for this standard, no-cookie auth method? Why is there no corresponding markup in HTML5?
- thesuitonym 5y ago
  It happens in HTTP, before any HTML5 is rendered or even sent. Why have browser vendors neglected it? I suppose it's a chicken/egg problem. Nobody really uses it, so why spend effort on it? No effort is spent on it, so it's stuck in the 90s, why would anyone use it?
- munk-a 5y ago
  There isn't anything in the standard to support a "Go here to reset your password" link or a "Go over here to create an account" - I really appreciate HTTP auth for somethings - but it's not great if you don't have a user base that is registered for your site through some non-web based interaction. It's certainly possible to have a user creation flow that ends up auth'ing with Basic Auth but it's not particularly user friendly.
  - jeroenhd 5y ago
    The browser could redirect the user to a form after cancellation or a certain amount of failures (say, 3 or 5) with recovery options. Add a nice retry button on there and you've got yourself a very simple login flow. Stock nginx/apache configurations will basically let the user retry infinitely or show a plain error page after user authentication fails too often, but these pages are configurable and don't need to be handled by the web server itself. One thing this mechanism doesn't provide is brute force protection through systems like CAPTCHAs.

asadawadia 5y ago

what a coincidence I just wrote about this last night on my blog - https://blog.aawadia.dev/2022/02/17/basic-auth-with-javalin/ https://blog.aawadia.dev/2022/02/17/basic-auth-with-javalin/

irq-1 5y ago

If this is new to you, you can also include the username and password in the url: https://user@example.com/page https://user@example.com/page https://user:pass@example.com/page https://user:pass@example.com/page

djbusby 5y ago
I've noticed many times the browser won't send those from the link. I was trying that with services where I owned both sides and my pre-authenticated links weren't sending the credentials. But using the same URL via curl was authenticated.
- jjice 5y ago
  I believe the major browsers deprecated this a little while ago. You can still use basic auth and everything, just not via a URL like this.
- remram 5y ago
  On Firefox, I just get a warning: "You are about to log in to the site “news.ycombinator.com” with the username “test”" I'm not entirely sure what the concern is to be honest. If it's tracking, this doesn't provide anything on top of query parameters e.g. ?utm_campaign=
  - sethaurus 5y ago
    The concern is about phishing via URL spoofing. For example, a user might see a URL like `google.com@mycoolphishingsite.se` and believe that "google.com" is the domain. The warning is intended to point out that "mycoolphishingsite.se" is the real domain.
gwbas1c 5y ago
The problem is that many proxies will log passwords sent this way.
- caylus 5y ago

foreigner 5y ago

Why is this preferable to authentication using cookies?

mrtesthah 5y ago
The web server can directly handle your authentication and accounting system rather than needing to include more huge middleware frameworks.
- n0w 5y ago
  Why would `Authentication` be any different to `Cookie` in this regard? They're both HTTP headers. They both require server side support/implementation. Neither explicitly requires JavaScript. The only difference I can see is that the browser has a native control for one of them, though that control cannot be customised by the site.
- munk-a 5y ago
  Just to clarify - are you calling cookie support a huge middleware framework? Both BasicAuth and Cookie reception are features included in nearly every browser offering - it's generally how you actually check resource authorization that's the hard part of Auth - the actual technical "Get a cookie from a browser" and "Check the BasicAuth headers" portions are pretty simple - in fact getting a cookie is arguably easier in most cases. Especially since a popular serverside programming language (PHP) has streamlined session handling to the point that most programmers going from it to other serverside languages get confused when there isn't a $_SESSION equivalent that you just inspect with the tap of a button.
  - mrtesthah 5y ago
    Note that I said “authentication and accounting system”. You just described a very small part of that functionality. It’s the reason people adopt large frameworks like Django, and why PHP’s session management alone is insufficient. You can look at functionality like Apache’s mod_authnz_ldap as an example of built in account management that integrates with HTTP basic auth. https://httpd.apache.org/docs/2.4/mod/mod_authnz_ldap.html https://httpd.apache.org/docs/2.4/mod/mod_authnz_ldap.html

jeroenhd 5y ago

Looking at the MDN page [1], I noticed that SHA2-256 digest authentication was added relatively recently to Firefox (and Firefox for Android). I wonder why they added it, as no other browser manufacturer seems to care and the added benefit of using digest rather than basic auth is only minimal now that every decent website has TLS. Also, interestingly, the support matrix suggests that Firefox for Android supports Kerberos and NTLM authentication. I guess I never expected Kerberos for websites to show up outside of desktop browsers. [1]: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/WWW-Authenticate https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/WW...

TonyTrapp 5y ago

I won't get tired of mentioning this - the basic authentication dialog should show a message from the server that is supposed to inform you what kind of credentials to enter. This is super useful for intranets, spam prevention systems and other stuff. Chrome removed this message years ago because of a dubious security report, and Firefox appears to have finally given in and removed it as well. All because someone could MITM your connection and present a login prompt à la "please enter your YouTube credentials" (completely ignoring that if they MITM you, they could serve you a page that really looks like a login page). This change completely ruined the usability of basic authentication.

deleted 5y ago
[deleted]
Kwpolska 5y ago
I found the bug you’re talking about: https://bugs.chromium.org/p/chromium/issues/detail?id=544244 https://bugs.chromium.org/p/chromium/issues/detail?id=544244 The MITM part is, in my opinion, an unimportant invention of the original reporter. The change was made because the basic auth dialog is part of the browser chrome (i.e. UI not part of web pages). This UI often looks like part of the browser/OS (especially in legacy IE, but modern browsers also show it differently, with the dialog partially obscuring the bookmarks toolbar. You don’t need a MITM attack for this to go wrong, all you need is a rogue ad or something redirecting you to the attacker’s site. Users might think “the dialog is asking me for my Google password, and it’s presented by the Google Chrome browser, so it’s got to be legitimate.”
- TonyTrapp 5y ago
  That is true, but let's also not forget that the bug title is "HTTP basic auth credentials prompt should make the origin stand out more" and nothing has been done about this in the last 7 years. Instead of making it stand out that the text is coming from the server, they just removed it completely. I found the original prompt to be pretty clear already ("the server asks for a username and password, it says: ...") but I'm sure in all these years they could have brought it back and made it more obvious that it's not Chrome asking for these things.

cjm42 5y ago

The big problem with this is that mobile Safari on iOS won't autofill passwords for sites using WWW-Authenticate. It used to, but that feature got dropped years ago, which really ticks me off, as I regularly use a couple of sites that use it.

jonahbenton 5y ago

Having to do an authentication check on every request is suboptimal, but ok in many cases. It's just very unfortunate that more protocol explicitly directing secure interactions between the user and the user-agent in managing identity and authentication never really emerged.

remram 5y ago

I don't understand why "no cookies" is listed under "pros". This works exactly like a session cookie (a header attached to every request to the domain), the only difference is that the header contains your actual plain-text credentials instead of a token. It is at most as secure/safe/non-invasive as a cookie, and in a lot of situation, a lot less. The obvious way to improve it would be to offer a way for the browser to load a custom form to authenticate and get the (hashed) credentials to present to the original website in the header. And then you have recreated session cookies in full.

password4321 5y ago

There's also NTLM and Negotiate (Kerberos). https://caniuse.com/?search=www-authenticate https://caniuse.com/?search=www-authenticate

cirrus3 5y ago

What is the deal with no capitalization? It is distracting because it is almost as if the writer went out of their way to do this while leaving most other grammar intact.