25 ms·

Using HTTP Basic Auth in 2022

524 points by codazoda 5y ago

kij 5y ago
I am very happy with the this caddy extension: https://github.com/greenpau/caddy-auth-portal https://github.com/greenpau/caddy-auth-portal. Sorts this precise use case for me, need for common login provider. Without the banality of basic auth.
- santa_boy 5y ago
  thank you! this gave me an idea to look for something similar for nginx ... https://github.com/vouch/vouch-proxy https://github.com/vouch/vouch-proxy lots of my issues on authentication for various apps can perhaps be handled now!
combatentropy 5y ago
Apache has had form-based authentication for about 10 years: https://httpd.apache.org/docs/2.4/mod/mod_auth_form.html https://httpd.apache.org/docs/2.4/mod/mod_auth_form.html
ithkuil 5y ago
How do you logout?
- sdze 5y ago
  You can still apply a session id to the client and destroy the session after the user clicked on logout…
  - bobkazamakis 5y ago
    I'm storing sessions now? jesus what a disaster.
- codazoda 5y ago
  Great question. This is a downside, there is no built-in method, but there are some tricks. If I remember correctly you can send headers with incorrect credentials. I’ll have to do some research and add that to my template.
  - yosamino 5y ago
    If I remember this correctly, you send a request with incorrect credentials either via javascript, or by sending the user to a "/logout"-endpoint where you disallow any authentication credentials, causing the browser to prompt the user for a new username and password. This not great in terms of UX and depending on something implicit for something as important as logging out does not seem great for security. Why browsers do not have better functionality built in for authentication is something that's always been a bit baffling...
- mrweasel 5y ago
  While your point is correct: It's not design with a logout in mind, but you can do it. For instance clicking link that will send invalid credentials, that will return a 401 and work like a logout. Mostly I just close my browser, that clear everything in my setup.
  - throwawayboise 5y ago
    I don't see anything wrong with a convention "to log out, close your browser" especially for little internal utility pages.
    - pmontra 5y ago
      People could have many open tabs with work in them. Maybe they would have to login again in some of them. Other could come back in a different state, especially with SPA.
- deepersprout 5y ago
  Send an ajax request to your api with invalid credentials. The response returns a 401 and loggs the user out. Then redirect to the pre-login page.
  - zemo 5y ago
    if all the client needs is to see a 401, can't you just make a static /logout page that always renders a 401?
- deleted 5y ago
  [deleted]
- theamk 5y ago
  Last time I used HTTP basic auth, we've had a page which would unconditionally send 401 error code -- it'd invalidate credentials cache (effectively logging out the user) and then pop up new credentials dialog. I am not sure how standard-complaint this was, but it seemed to work in most browsers. One downside is that in trivial implementation (/logout page returning 401), you'll end up with credential prompt where no credentials work, and this can be pretty confusing if someone leaves the compute in that state. I think it can be worked around with "expiration" URL parameter or a cookie, but this is somewhat finicky to setup.
- pmontra 5y ago
  With Firefox, from the Preferences, select only "Active logins" in the Clear History dialog [1]. Very odd that it belongs to history and far from ideal. However it's not something a lot of people use nowadays so I'm not surprised that they tucked it under the carpet. I use Basic Authentication for a few web services running on a server of mine and that I'm the only user of. It saves me a lot of work. I set the user and password in a file on the server and let nginx deal with it. [1] https://security.stackexchange.com/questions/192828/firefox-not-deleting-http-basic-authentication-credentials-although-being-instru/214062#214062 https://security.stackexchange.com/questions/192828/firefox-...
sdze 5y ago
This is perfectly fine. Nothing to be ashamed of. At least you don’t need to create a logon form
- SavantIdiot 5y ago
  But if you are rolling your own auth, you still need to create the signup, change password, reset password, confirm account, delete account, etc. pages. What's one more? Given that a logon form is >5% of the total amount of work to roll auth, seems kinda pointless to use this.
  - Jolter 5y ago
    Author mentions internal tools, so I assume they already have a user database they integrate with on the back-end? LDAP or similar.
  - amelius 5y ago
    But still, why reinvent the wheel? There are plenty of libraries, even services available that do what you want.
    - SavantIdiot 5y ago
      I recently re-rolled a password auth protocol because Auth0 and AWS Cognito were just so goddamn complicated. Ages ago I used stormpath because it was so simple, I realize there are many options today for federated logins, 2FA, SMS / phone password resets ... i just wanted an old-school password system for my dumbass personal site.
  - jeofken 5y ago
    Implementing magic email sign in links is more straightforward and secure. You implement a login route which takes an email address. You symmetrically encrypt the email with a secret key from an environment variable, and send a link to /login?secret=<email-ciphertext>. This route handler checks that the ciphertect decrypts into the email, and if true, save the ciphertext as a cookie and check that it decrypts to the right email every time you require auth
billpg 5y ago
Wouldn't you need to the substantial workload of PBKDF2 (et al) for each and every HTTP request? Maybe have the images, JS, CCS etc handled by a separate server, but there's still going to be many requests that need to be authenticated for.
- klodolph 5y ago
  I don't see why that couldn't be cached.
  - TedDoesntTalk 5y ago
    You can also enforce HTTP Basic Auth on only sensitive URLS while allowing images and css, for example, to be downloaded without auth.
  - billpg 5y ago
    Your "is this password valid" cache would need to be indexed by the clear-text password. That's a separate security issue.
    - klodolph 5y ago
      Why would you need to index it by the clear-text password? You don't need to retrieve the clear-text password, it doesn't have to be stored in the cache at all. The cache itself would be in the memory of a process which had access to cleartext passwords anyway, so presumably an exploit which allowed you to read the cache would be damning no matter what.
      - diarrhea 5y ago
        The parent commenter possibly meant: with an incoming request, sending a password in clear-text, how do you cache it? You hash it, then store the fact that authentication was valid with some expiry. Once the next request, again with clear-text password, comes in you need to look up its validity. You want to check without hashing, that's the entire point. If you look up whether the hash is validly cached, you gained nothing. Hashing was required. To look up without hashing, you will need to use the clear-text password somehow. Hence it has to be part of the cache somehow, i.e. its index. If that's all in memory in a memory-safe language, I guess it can be argued that's not unsafer than before, but I'm no expert.
nuccy 5y ago
I find HTTP basic auth very useful to "protect" gitlab, wiki, forum, et al. internal resources exposed to the internet. With a simple apache/nginx config it is possible effectively to hide those from the intenet and in addition to their built-in authentications (ldap-based) have a fense reliable enough to prevent zero-day vulnerabilities of these populular web applications. Having them as sub-folders of a single web-domain (with proper rewrites added to apache/nginx) prevents numerous HTTP basic auth requests so authentication is required just once after the browser has been restarted.
- mbreese 5y ago
  I have a few webpages that have to be protected this way, due to an external client that only supports HTTP Auth. I’ve actually been pretty happy with this setup. I have nginx configured to use subauth authentication so I can still have external username/passwords stored in LDAP, etc. It’s been a surprisingly good combination.
- showerst 5y ago
  I do the same thing; really nice for those things you just can’t put behind a VPN for one reason or another.
  - nuccy 5y ago
    A nice alternative to VPN (especially when you don't have a root to set it up) is using ssh tunnels: ssh user@server -D 1234 and Firefox with socks proxy set to 127.0.0.1:1234 (e.g. using Foxyproxy addon, though possible without it via the Firefox network settings). Then all Firefox trafic is exiting on the server side (including DNS requests).
    - znpy 5y ago
      > including DNS requests Don't be sure about that! There's an additional setting to check to be sure dns goes through the proxy. Can't recall the details now, but it's there! Or maybe it was due to dns over tls not being proxied?
- 5y ago
yuliyp 5y ago
This has many flaws that make it impractical beyond hobby projects or projects with a small set of users: - It's trickier to throttle credential checks as every request is a login request, effectively - It's hard to easily build account recovery flows or captchas into the login process. - The UX of logging in/out is browser-dependent and confusing for users - it can't integrate well with other auth systems - Sending a password on every request requires care to avoid accidentally logging passwords - Every request needs to do password validation, presenting additional load on the authentication systems/datastores
- codazoda 5y ago
  Probably true. I’m not suggesting it for your enterprise project. I’m just trying to remove personal roadblocks so I can test an MVP before I invest too much development time.
- hiptobecubic 5y ago
  Did you even read the post?
  - yuliyp 5y ago
    Yes, I did. Hence why I pointed out one of the characteristics that made it work fine in the scenario mentioned (that it has a relatively small set of users that can be trained), and many of the concerns I mentioned are not particularly applicable to the situation which the OP presented. I was making the point that the OP's success is not necessarily transferable to large scale applications.
- gjsman-1000 5y ago
  I wonder if there would be an audience for an HTTP Basic Auth 2.0 spec. Some of your criticisms aren't exactly accurate though. "Sending a password on every request requires care to avoid accidentally logging passwords" applies to almost every login system ever made. Unless you use browser-based hashing with JavaScript, but that has significant known flaws and doesn't add much security. And "Every request needs to do password validation, presenting additional load on the authentication systems/datastores" also applies to almost every login system ever made and HTTP Basic Auth doesn't make this better or worse.
cadence- 5y ago
This is great for small projects and services that have just a few users and an easy way to change passwords and create/delete accounts directly in the backend. It’s secure (although you must use HTTPS) and is very easy and fast to use, especially if you have a password manager that automatically fills out the login form.
forgotmypw17 5y ago
I use it as a captcha. It's great for keeping crawler bots out, and easy enough for humans to get past. Once a user logs in, I set a cookie, and the user is not prompted for the auth again. The beautiful thing about this scheme is that the cookie is always sent, so I can create a rule which bypasses auth when the cookie is present. Basic Auth is one of the most supported features of HTTP, supported even by Mosaic. There's one Chrome release, I think 65.x, which screws it up when used together with gzip and requires a page reload after authenticating, but that's the only exception I know.
- zinekeller 5y ago
  > There's one Chrome release, I think 65.x, which screws it up when used together with gzip and requires a page reload after authenticating Fortunately, that Chrome version is dead in the water (unlike Chrome 49, which is the last version for XP and Vista)
  - diarrhea 5y ago
    > unlike Chrome 49, which is the last version for XP and Vista Oh God.
    - mooreds 5y ago
      Agreed. My sympathies that the GP even needs to know this.
      - zinekeller 5y ago
        No need, I just angrily redirect users to FF52 (Firefox tends to be the last major browser maintained for older systems anyways). Plus, requiring a minimum of TLS 1.2 with specific PFS ciphers is now the requirement, nuking even the Windows Embedded POS version of Windows XP for Chrome (Firefox brings its own cryptographic libraries).
  - forgotmypw17 5y ago
    Thanks for the tip about Chrome 49. I'll add it to my list of browsers to test with more frequently. 65.x happens to be the last version added to Ubuntu 13.x, which is what one of my devices came installed with and I'm not motivated to change.
Waterluvian 5y ago
Something I’m practicing more often is to keep something dead simple and then later adopt a library or some higher abstraction when necessary. For example, just handling a websocket myself before later using some sort of library for it. In the past my concern was that I’ll have to make breaking changes to some protocol or message structure. But I’m learning now that it’s actually a good thing: it makes me think about how I’ll evolve and grow without the answer being “just preemptively grow it so you don’t have to think about it.” And naturally I’m discovering that the basic tools go far further than I expect and sometimes I never need to pay for that abstraction at all.
- klysm 5y ago
  I find a lot of libraries don’t make the underlying systems easier to use per se, they just map a lot of use cases to configuration instead of code. I would rather just use the code hiding behind that static configuration.
  - Waterluvian 5y ago
    After years and years of production experience with thousands of mobile robots that use this weird xml + yaml as configuration, I am 100% in the “just use code as configuration” camp.
    - smitty1e 5y ago
      I put stuff in config.py Then I just `import` at will. The need for a separate configuration format was what, again?
      - Waterluvian 5y ago
        My probably wrong belief is that it was a misguided but noble idea of abstracting complexity.
      - gedy 5y ago
        Compiled languages had a harder time with this.
smasher164 5y ago
I found that sites (like fb messenger) which block URLs to certain sites can be easily bypassed by using HTTP Basic Auth with empty credentials. I built a small service (https://rot13.akhil.cc https://rot13.akhil.cc) that takes in a rot 13'd URL and redirects it to the original with HTTP Basic Auth. The nice part is that the credentials are cached, so visiting it again won't show the dialog.
- tdeck 5y ago
  That's really clever!
yegle 5y ago
It's always easy to add Oauth flow to a website that uses basic auth, by using an identity aware reverse proxy (e.g. https://pomerium.io https://pomerium.io).
kogir 5y ago
My big problem with HTTP basic auth in 2022 (squints at Netgear router) is that in Edge/Chrome 1Password can’t auto complete it. It gets really annoying really quickly.
- xnaas 5y ago
  Bitwarden has 0 issues 'autofilling' basic auth. It just passes the login credentials on connection and you never see a basic auth prompt.
  - jeroenhd 5y ago
    That's actually a gripe I have with Bitwarden, because you can't turn that feature off. If an attacker can take over a single endpoint, Bitwarden will happily send your credentials to an iframe from a malvertiser without ever telling you. It's a fine feature and the WebExtension API won't let them solve basic auth in any other way, but it's a security risk in my opinion. I'd much rather see browsers provide an API to HTTP Basic auth prompts instead so the user can select an identity from the list if they've got a saved username/password combo that matches a given set of requirements.
  - watermelon0 5y ago
    It only supports a single user/pass pair for each site. There are many cases where you would want to use multiple identifies and switch between them.
- progforlyfe 5y ago
  100% this! At least Firefox with 1password seems to handle it okay.
- Maxburn 5y ago
  Yes, this is one of my major grapes. I’m using LastPass though. The comment below about bitwarden is interesting and I will have to give that a try.
zimbatm 5y ago
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?
jerf 5y ago
HTTP Basic Auth was deprecated a long time ago, back when HTTPS was a very expensive exotic thing that only large sites used. I'm not sure it would be worth deprecating freshly today if it came up, now that anyone who wants HTTPS can get it easily. It may not be the perfect solution to everything but it does fill in a nice space, even in its current form. If browsers would just pay a bit more attention to it it could become very nice; most of its worst quirks are technically in the browsers, not the protocol.
kjaftaedi 5y ago
You should take a closer look at AppWrite, AzureB2C, or Google's Firebase. You can even have Azure or Google connect to your own custom identity provider. It's only a few lines of code to implement user management using identities you control. I get not wanting to get locked into these things, but once you learn how they function, you can switch between identity providers in minutes. I do get the sentiment though, but for something like this my vote would be for certificates instead of basic auth.
nichochar 5y ago
I love simplicity. the reasons you provide for using it are really strong, and I think it's a much superior option to prototyping leveraging oauth 3rd parties (which has tons of downsides). It would be good to have a hard rule as to when you migrate, and what the reasons are (if a project has more than N users, if you store field X which is pretty sensitive, etc..)
1vuio0pswjnm7 5y ago
https://www.ietf.org/rfc/rfc7617.txt https://www.ietf.org/rfc/rfc7617.txt
mholt 5y ago
Caddy comes with basic auth support because it's still useful for a lot of use cases. IMO the biggest weakness of basicauth (when deployed over TLS) is the fact that most server configurations store the passwords in plaintext, usually in a config file. This is like storing passwords in plaintext in a database. Caddy does not allow this. You have to use a secure hash on the password before adding it to your config: https://caddyserver.com/docs/modules/http.authentication.providers.http_basic https://caddyserver.com/docs/modules/http.authentication.pro... Of course, password hashes are slow, so KDF'ing a plaintext string at every HTTP request can grind even powerful servers to a halt. So Caddy can optionally cache hash results in memory (we do expect memory to be safer than a config file -- and Go is a memory-safe language in this regard). And while this can introduce nuanced timing variances (fast if recently hashed), they do not necessarily correspond to correct passwords. If you think this stuff is interesting and want to help make Caddy's basic auth even better, feel free to contribute or sponsor: https://github.com/caddyserver/caddy https://github.com/caddyserver/caddy
- LAC-Tech 5y ago
  happy new year. Caddy is such a great piece of software. It has great defaults 'out of the box' but at the same time doesn't feel like I'm drowning in incomprehensible magic. We need more software like this!
  - mholt 5y ago
    Thanks for the kind words!
  - lgvld 5y ago
    Yeah caddy is such an awesome server! ;-)
- hasel 5y ago
  Is this supposed to be used to put entire domains behind basic auth or should you use it for specific end points?
  - 5y ago
throwaway984393 5y ago
Spend an hour to set up an OAuth2 Proxy (https://oauth2-proxy.github.io/oauth2-proxy/ https://oauth2-proxy.github.io/oauth2-proxy/) instead. You can use the one proxy for entire subdomains / unlimited number of apps. No plaintext passwords, scales well, open source, industry standard, and you get SSO for free. Hell, you don't even have to manage accounts! It makes your life simpler and it's more secure. You can't say that often.
skywal_l 5y ago
Stupid question: why not use nginx? Configuring basic auth is about 4 lines of config. Nginx is fairly simple and is overkill only for dev setup for which you don't need auth anyway.
- Valord 5y ago
  This is what I've been doing for simple projects, easy.
prpl 5y ago
oauth2-proxy is as simple as HTTP Basic Auth (and can also accept HTTP Basic as well) - no great reason to not use it, along with REMOTE_USER header
- RedShift1 5y ago
  HTTP basic auth RFC is 14 pages. The OAuth2 RFC is 76 pages, and that's only the framework. Perhaps we have a different understanding of what "simple" means...
devmunchies 5y ago
I like basic auth (Header of `Authorization: Basic username:password`) but for persistent session auth I prefer the Bearer tokens[1][2] (Header of `Authorization: Bearer my_token_here`). It's easy to generate a hash after the user logs in and then just store it in a cookie. The user doesn't have to store their password locally and I can delete the token from the database to force them to re-login. You can reuse the same token generation infra for APIs too so its pretty dynamic. I've basically moved away from JWTs in favor of this simpler approach. [1]: (list of auth schemes) https://developer.mozilla.org/en-US/docs/Web/HTTP/Authentication#authentication_schemes https://developer.mozilla.org/en-US/docs/Web/HTTP/Authentica... [2]: (Bearer auth spec) https://datatracker.ietf.org/doc/html/rfc6750 https://datatracker.ietf.org/doc/html/rfc6750
- creeble 5y ago
  Surprised there aren’t more comments here - does everyone agree that this is equivalent (in security terms) to using JWT? I would very like to never use JWTs again.
  - devmunchies 5y ago
    i listen to a few cryptography podcasts and cryptography is an interest of mine[1]. most security engineers agree that JWT has too much of a surface area and takes a lot of care from the implementer that it can lead to security holes[2]. Another reason i like just generating a securiity token when the user logs in is that i can require a join on the table for any query so that its extra secure. e.g. if fetching "posts" for a "user" and i have 3 tables (users, posts, and user_tokens) i can do an inner join like this (if the `posts` table has `user_id`): select p.* from posts p inner join user_tokens ut using (user_id) where p.user_id = $1 and ut.token = $2 -- `users` table wasn't needed for this join since am not selecting from it with JWTs the security happens once when you verify the JWT signature, but then security is less of a focus when making queries, which would complicate queries anyway since you have to make sure the same user who owns the JWT has access to the data (it handles authentication but not authorization). You still need to hit the database anyway for fetching any data so the headless approach for JWTs isn't really saving me much, so I like to just bake in security for the queries. [1]: I recommend new book "Real World Cryptography" by David Wong [2]: (podcast about JWTs from cryptographer, august 2021) https://securitycryptographywhatever.buzzsprout.com/1822302/9020991-what-do-we-do-about-jwt-feat-jonathan-rudenberg https://securitycryptographywhatever.buzzsprout.com/1822302/... -- EDIT: would probably want a few more predicates in that query to account for token status. e.g. where p.user_id = $1 and ut.token = $2 and ut.is_revoked = false and ut.is_expired = false
ufmace 5y ago
I like the reminder that this is out there and mostly available. I think many of the comments here are missing the point - they're saying it's useful for small-time projects with one or a few users and not needing to be integrated into a sophisticated infrastructure. No need to worry too much about hashing, logouts, the full chain of account management, etc. Use a full-featured solution if you need that, keep Basic Auth for a thing with a few admin pages where anything unusual gets handled over SSH. This also reminds me - Gemini uses client certs for a similar purpose. Gemini doesn't seem to have much going on, but it does make a good case for using client certs better. Right now, they're technically supported, but the UI for both browsers and server support is really clunky. Build a decent UI on both sides, and it could be a nice simple solution for higher-security authentication.
ChrisMarshallNY 5y ago
I just use it once, to generate an API key, then use the key, and a server secret (in the basic auth header), after that. The key could be generated by something like Sign In With Apple. Not Fort Knox, but fairly good. Because of FastCGI, I have to have an option to pass login creds in the URL, but that is not by default.
smitty1e 5y ago
One non-technical advantage is prototyping. Going this route says to the consulting client: this is NOT the full solution. This is only work-in-progress. If you treat this as the final delivery and deploy this to prod, you're making a big mistake. Not that I've ever seen that happen, mind you.
worik 5y ago
What is authentication for? What is it protecting? Sometimes the effort and expense protecting a thing is more than the value of the thing protected. Often there is nothing really to protect, "authentication" is just administrative convenience. So simple is best. Cheep and cheerful!
tunesmith 5y ago
I don't know if it really holds up to scrutiny, but I use http basic auth for a semi-public website. It has members (like less than twenty) that I don't know personally other than through the website, but I don't want the website public because I don't want to deal with with TOC, GDPR, legal stuff in general. Once you're past basic auth, it actually does have a login/registration flow, but it seems like I'd need to see a lawyer if I ever wanted to make a member-driven website public and I just haven't gotten around to it yet, so... http basic auth. Is this sound thinking? I don't know.
- emj 5y ago
  The GDPR/Cookie rules are just the same common courtesy that all projects I've been invovled with always has had. No ad trackers and no personal data stored about what I did on the site unless necessary for the function provided. There is no exemption for personal sites. Point being, I'm from the EU but some times that has not always been important and only come up after working with someone online a couple of years. Basically; HTTP Basic auth does not make you website anymore private than a login page. Just treat you users fair and be straight forward with what you do with the data, and you won't need any lawyers.
bdcravens 5y ago
I use it for an internal API that needs credentials to make additional calls. It lets me keep the HTTP semantics super clean.
efitz 5y ago
I died a little inside reading this article. Clearly we have a lot farther to go with secure development lifecycle evangelism.
tzahifadida 5y ago
The problem is not with small projects. Who cares if it gets hacked. The problem is with real life SSO. If you used a 100 apps and 1 gets hacked then you have to change the other 99 passwords. Sound bad right? That is why you should not use basic auth and use openid connect or similar tech. Sometimes it is a bank, and no SSO involved. It is not well understood but SSL has termination points. E.g. the gateway and each gateway all thru the last layers. SSL becomes vulnerable at these termination points. If basic auth is used, then you just lost a whole lot of cash. Otherwise use challenge response, encrypted passwords within the SSL, and all kind of out of this world tech for risk assessment. Basic auth? Really?
tlrobinson 5y ago
I used to use Basic Auth for small personal/internal services, but these days I prefer a proxy like Traefik/NGINX with a simple authentication service like Authelia or Traefik Forward Auth. It’s a little more work to setup but not much and there are a bunch of benefits: SSO across multiple services, control over session expiration, works better with password managers, 2FA, etc.
deleted 5y ago
[deleted]
incanus77 5y ago
I don't recall seeing a lot of good info on how to use HTTP Basic Auth back in the day, to the extent that in 1998 I wrote my first technical how-to to post on my own website. It still lives on here: https://codesorcery.net/old/authentication/ https://codesorcery.net/old/authentication/
thorum 5y ago
As a counterpoint, learning the basics of a good OAuth library or service like oauth2-proxy, auth0, next-auth or keycloak is well worth your time as a developer. Once you get over the initial learning curve, it’s almost as easy to add to a project as basic auth. You don’t need to reinvent the wheel with each project, building login pages and database code - other people have done the work for you - and you can create a more usable and professional experience for your users.
kevincox 5y ago
I have always wondered how feasible it would be to use the basic auth URL syntax for thinks like API tokens and email validation. Ideally these values would not be logged but if you want a user to click them they basically need to be in the URL. So either you don't log URLs or you need to redact all of these parameters. Most systems are smart enough to avoid logging passwords so if you could just use URLs like randomtoken@example.com/confirm-email. However it seems like browsers usually put up scary warnings and most email providers will consider this a spammy/scammy pattern. Of course another problem here is that you just want it for one URL, whereas basic auth is usually preserved for the session.
Shadonototra 5y ago
HTTPS is a mess, certificates are a mess Not everything needs it and yet it is mendatory for everything you want to do Just had get throught all of that mess for a simple websocket This is beyond sad
LinuxBender 5y ago
I still use basic auth as a quick and dirty way to protect a link when emailing files to friends that are still on gmail. It keeps the Google bots off my files.
- pronoiac 5y ago
  I've been considering basic auth for projects I spin up on subdomains, as I think there could be bots watching https registrations.
geenat 5y ago
Easiest way to defend against brute force attack? How does one rate limit? The only thing putting me off using HTTP auth is this. Seems like you need NGINX configured to hold state and be the rate limiter.
- hnick 5y ago
  You can use a slow validation function (bcrypt) to naturally rate limit login attempts, or log login attempts somewhere and do it based on that in the code layer. Most login schemes will have at least a basic database with a users table so it isn't much extra effort to check during validation.
r1ch 5y ago
Basic Auth has become increasingly difficult to use as a generic way to protect a web app. Many apps these days have endpoints that respond with 401 when a user isn't logged in, which if you're fronting the application with basic auth, results in the user being "logged out" as the browser thinks the credentials are no longer valid. The hijacking of HTTP status codes by client-side apps wanting to interpret them in their own way makes me think we need a new range of codes for user-defined statuses.
ChuckMcM 5y ago
Also has the benefit of discouraging crawlers.
jacobsenscott 5y ago
It seams firefox caches bad basic auth creds. It is so annoying because there are several sites where I can only do a basic auth login from a private window. If I go there in a regular window I just get the invalid authentication error, and no option to enter a new username/password. It isn't clear where this is cached either, so it is very difficult to clear that cache.
andrethegiant 5y ago
Looking at that screenshot I bet the password is 1234
jijji 5y ago
a good example of doing Auth-Basic in PHP is https://www.php.net/manual/en/features.http-auth.php https://www.php.net/manual/en/features.http-auth.php
fullstackchris 5y ago
Easiest auth I've found is Netlify identity: https://docs.netlify.com/visitor-access/identity/ https://docs.netlify.com/visitor-access/identity/ It's usually a one liner to add to apps. Reach for Auth0 when you need authentication a bit more down to the metal.
wraptile 5y ago
FYI Python can server http basic auth straight out of the box! I wrote this tiny wrapper Sauth[1] that has been a real life saver for delivering minor WIP stuff to clients who are not in the whole cloud ecosystem - just type in url and put in your credentials to see the latest files. 1 - https://github.com/Granitosaurus/sauth https://github.com/Granitosaurus/sauth
ChicagoDave 5y ago
The primary flaw isn't BASIC AUTH. It's the password itself. Brute force attacks are easy. The only good way of securing anything is through an Authenticator app.
- anaganisk 5y ago
  And all that takes to break it is a compromised version floating around in WhatsApp groups saying Authenticator plus would give u blue theme.
- lucb1e 5y ago
  You can still have the server trigger an authentication confirmation when using basic auth. Web servers not coming with authentication apps is not a flaw, it is a completely separate component and scope.
a-dub 5y ago
i kinda miss .htaccess
ungerik 5y ago
Surprise of 2022: you get to the top of HN by telling the world about HTTP Basic Auth ...I am getting old ;-)
- codazoda 5y ago
  You and me both. I’m just as surprised as you. Nice way to start the year off though. :)
outloudvi 5y ago
I think that Basic Auth is still working as is, so actually... why not?
pabs3 5y ago
I wish browsers supported client TLS certs better, the UI is usually terrible and client-side key generation got dropped from some browsers.

524 points by codazoda 5y ago

kij 5y ago

I am very happy with the this caddy extension: https://github.com/greenpau/caddy-auth-portal https://github.com/greenpau/caddy-auth-portal. Sorts this precise use case for me, need for common login provider. Without the banality of basic auth.

santa_boy 5y ago
thank you! this gave me an idea to look for something similar for nginx ... https://github.com/vouch/vouch-proxy https://github.com/vouch/vouch-proxy lots of my issues on authentication for various apps can perhaps be handled now!

combatentropy 5y ago

Apache has had form-based authentication for about 10 years: https://httpd.apache.org/docs/2.4/mod/mod_auth_form.html https://httpd.apache.org/docs/2.4/mod/mod_auth_form.html

ithkuil 5y ago

How do you logout?

sdze 5y ago
You can still apply a session id to the client and destroy the session after the user clicked on logout…
- bobkazamakis 5y ago
  I'm storing sessions now? jesus what a disaster.
codazoda 5y ago
Great question. This is a downside, there is no built-in method, but there are some tricks. If I remember correctly you can send headers with incorrect credentials. I’ll have to do some research and add that to my template.
- yosamino 5y ago
  If I remember this correctly, you send a request with incorrect credentials either via javascript, or by sending the user to a "/logout"-endpoint where you disallow any authentication credentials, causing the browser to prompt the user for a new username and password. This not great in terms of UX and depending on something implicit for something as important as logging out does not seem great for security. Why browsers do not have better functionality built in for authentication is something that's always been a bit baffling...
mrweasel 5y ago
While your point is correct: It's not design with a logout in mind, but you can do it. For instance clicking link that will send invalid credentials, that will return a 401 and work like a logout. Mostly I just close my browser, that clear everything in my setup.
- throwawayboise 5y ago
  I don't see anything wrong with a convention "to log out, close your browser" especially for little internal utility pages.
  - pmontra 5y ago
    People could have many open tabs with work in them. Maybe they would have to login again in some of them. Other could come back in a different state, especially with SPA.
deepersprout 5y ago
Send an ajax request to your api with invalid credentials. The response returns a 401 and loggs the user out. Then redirect to the pre-login page.
- zemo 5y ago
  if all the client needs is to see a 401, can't you just make a static /logout page that always renders a 401?
deleted 5y ago
[deleted]
theamk 5y ago
Last time I used HTTP basic auth, we've had a page which would unconditionally send 401 error code -- it'd invalidate credentials cache (effectively logging out the user) and then pop up new credentials dialog. I am not sure how standard-complaint this was, but it seemed to work in most browsers. One downside is that in trivial implementation (/logout page returning 401), you'll end up with credential prompt where no credentials work, and this can be pretty confusing if someone leaves the compute in that state. I think it can be worked around with "expiration" URL parameter or a cookie, but this is somewhat finicky to setup.
pmontra 5y ago
With Firefox, from the Preferences, select only "Active logins" in the Clear History dialog [1]. Very odd that it belongs to history and far from ideal. However it's not something a lot of people use nowadays so I'm not surprised that they tucked it under the carpet. I use Basic Authentication for a few web services running on a server of mine and that I'm the only user of. It saves me a lot of work. I set the user and password in a file on the server and let nginx deal with it. [1] https://security.stackexchange.com/questions/192828/firefox-not-deleting-http-basic-authentication-credentials-although-being-instru/214062#214062 https://security.stackexchange.com/questions/192828/firefox-...

sdze 5y ago

This is perfectly fine. Nothing to be ashamed of. At least you don’t need to create a logon form

SavantIdiot 5y ago
But if you are rolling your own auth, you still need to create the signup, change password, reset password, confirm account, delete account, etc. pages. What's one more? Given that a logon form is >5% of the total amount of work to roll auth, seems kinda pointless to use this.
- Jolter 5y ago
  Author mentions internal tools, so I assume they already have a user database they integrate with on the back-end? LDAP or similar.
- amelius 5y ago
  But still, why reinvent the wheel? There are plenty of libraries, even services available that do what you want.
  - SavantIdiot 5y ago
    I recently re-rolled a password auth protocol because Auth0 and AWS Cognito were just so goddamn complicated. Ages ago I used stormpath because it was so simple, I realize there are many options today for federated logins, 2FA, SMS / phone password resets ... i just wanted an old-school password system for my dumbass personal site.
- jeofken 5y ago
  Implementing magic email sign in links is more straightforward and secure. You implement a login route which takes an email address. You symmetrically encrypt the email with a secret key from an environment variable, and send a link to /login?secret=<email-ciphertext>. This route handler checks that the ciphertect decrypts into the email, and if true, save the ciphertext as a cookie and check that it decrypts to the right email every time you require auth

billpg 5y ago

Wouldn't you need to the substantial workload of PBKDF2 (et al) for each and every HTTP request? Maybe have the images, JS, CCS etc handled by a separate server, but there's still going to be many requests that need to be authenticated for.

klodolph 5y ago
I don't see why that couldn't be cached.
- TedDoesntTalk 5y ago
  You can also enforce HTTP Basic Auth on only sensitive URLS while allowing images and css, for example, to be downloaded without auth.
- billpg 5y ago
  Your "is this password valid" cache would need to be indexed by the clear-text password. That's a separate security issue.
  - klodolph 5y ago
    Why would you need to index it by the clear-text password? You don't need to retrieve the clear-text password, it doesn't have to be stored in the cache at all. The cache itself would be in the memory of a process which had access to cleartext passwords anyway, so presumably an exploit which allowed you to read the cache would be damning no matter what.
    - diarrhea 5y ago
      The parent commenter possibly meant: with an incoming request, sending a password in clear-text, how do you cache it? You hash it, then store the fact that authentication was valid with some expiry. Once the next request, again with clear-text password, comes in you need to look up its validity. You want to check without hashing, that's the entire point. If you look up whether the hash is validly cached, you gained nothing. Hashing was required. To look up without hashing, you will need to use the clear-text password somehow. Hence it has to be part of the cache somehow, i.e. its index. If that's all in memory in a memory-safe language, I guess it can be argued that's not unsafer than before, but I'm no expert.

nuccy 5y ago

I find HTTP basic auth very useful to "protect" gitlab, wiki, forum, et al. internal resources exposed to the internet. With a simple apache/nginx config it is possible effectively to hide those from the intenet and in addition to their built-in authentications (ldap-based) have a fense reliable enough to prevent zero-day vulnerabilities of these populular web applications. Having them as sub-folders of a single web-domain (with proper rewrites added to apache/nginx) prevents numerous HTTP basic auth requests so authentication is required just once after the browser has been restarted.

mbreese 5y ago
I have a few webpages that have to be protected this way, due to an external client that only supports HTTP Auth. I’ve actually been pretty happy with this setup. I have nginx configured to use subauth authentication so I can still have external username/passwords stored in LDAP, etc. It’s been a surprisingly good combination.
showerst 5y ago
I do the same thing; really nice for those things you just can’t put behind a VPN for one reason or another.
- nuccy 5y ago
  A nice alternative to VPN (especially when you don't have a root to set it up) is using ssh tunnels: ssh user@server -D 1234 and Firefox with socks proxy set to 127.0.0.1:1234 (e.g. using Foxyproxy addon, though possible without it via the Firefox network settings). Then all Firefox trafic is exiting on the server side (including DNS requests).
  - znpy 5y ago
    > including DNS requests Don't be sure about that! There's an additional setting to check to be sure dns goes through the proxy. Can't recall the details now, but it's there! Or maybe it was due to dns over tls not being proxied?
5y ago

yuliyp 5y ago

This has many flaws that make it impractical beyond hobby projects or projects with a small set of users: - It's trickier to throttle credential checks as every request is a login request, effectively - It's hard to easily build account recovery flows or captchas into the login process. - The UX of logging in/out is browser-dependent and confusing for users - it can't integrate well with other auth systems - Sending a password on every request requires care to avoid accidentally logging passwords - Every request needs to do password validation, presenting additional load on the authentication systems/datastores

codazoda 5y ago
Probably true. I’m not suggesting it for your enterprise project. I’m just trying to remove personal roadblocks so I can test an MVP before I invest too much development time.
hiptobecubic 5y ago
Did you even read the post?
- yuliyp 5y ago
  Yes, I did. Hence why I pointed out one of the characteristics that made it work fine in the scenario mentioned (that it has a relatively small set of users that can be trained), and many of the concerns I mentioned are not particularly applicable to the situation which the OP presented. I was making the point that the OP's success is not necessarily transferable to large scale applications.
gjsman-1000 5y ago
I wonder if there would be an audience for an HTTP Basic Auth 2.0 spec. Some of your criticisms aren't exactly accurate though. "Sending a password on every request requires care to avoid accidentally logging passwords" applies to almost every login system ever made. Unless you use browser-based hashing with JavaScript, but that has significant known flaws and doesn't add much security. And "Every request needs to do password validation, presenting additional load on the authentication systems/datastores" also applies to almost every login system ever made and HTTP Basic Auth doesn't make this better or worse.

cadence- 5y ago

This is great for small projects and services that have just a few users and an easy way to change passwords and create/delete accounts directly in the backend. It’s secure (although you must use HTTPS) and is very easy and fast to use, especially if you have a password manager that automatically fills out the login form.

forgotmypw17 5y ago

I use it as a captcha. It's great for keeping crawler bots out, and easy enough for humans to get past. Once a user logs in, I set a cookie, and the user is not prompted for the auth again. The beautiful thing about this scheme is that the cookie is always sent, so I can create a rule which bypasses auth when the cookie is present. Basic Auth is one of the most supported features of HTTP, supported even by Mosaic. There's one Chrome release, I think 65.x, which screws it up when used together with gzip and requires a page reload after authenticating, but that's the only exception I know.

zinekeller 5y ago
> There's one Chrome release, I think 65.x, which screws it up when used together with gzip and requires a page reload after authenticating Fortunately, that Chrome version is dead in the water (unlike Chrome 49, which is the last version for XP and Vista)
- diarrhea 5y ago
  > unlike Chrome 49, which is the last version for XP and Vista Oh God.
  - mooreds 5y ago
    Agreed. My sympathies that the GP even needs to know this.
    - zinekeller 5y ago
      No need, I just angrily redirect users to FF52 (Firefox tends to be the last major browser maintained for older systems anyways). Plus, requiring a minimum of TLS 1.2 with specific PFS ciphers is now the requirement, nuking even the Windows Embedded POS version of Windows XP for Chrome (Firefox brings its own cryptographic libraries).
- forgotmypw17 5y ago
  Thanks for the tip about Chrome 49. I'll add it to my list of browsers to test with more frequently. 65.x happens to be the last version added to Ubuntu 13.x, which is what one of my devices came installed with and I'm not motivated to change.

Waterluvian 5y ago

Something I’m practicing more often is to keep something dead simple and then later adopt a library or some higher abstraction when necessary. For example, just handling a websocket myself before later using some sort of library for it. In the past my concern was that I’ll have to make breaking changes to some protocol or message structure. But I’m learning now that it’s actually a good thing: it makes me think about how I’ll evolve and grow without the answer being “just preemptively grow it so you don’t have to think about it.” And naturally I’m discovering that the basic tools go far further than I expect and sometimes I never need to pay for that abstraction at all.

klysm 5y ago
I find a lot of libraries don’t make the underlying systems easier to use per se, they just map a lot of use cases to configuration instead of code. I would rather just use the code hiding behind that static configuration.
- Waterluvian 5y ago
  After years and years of production experience with thousands of mobile robots that use this weird xml + yaml as configuration, I am 100% in the “just use code as configuration” camp.
  - smitty1e 5y ago
    I put stuff in config.py Then I just `import` at will. The need for a separate configuration format was what, again?
    - Waterluvian 5y ago
      My probably wrong belief is that it was a misguided but noble idea of abstracting complexity.
    - gedy 5y ago
      Compiled languages had a harder time with this.

smasher164 5y ago

I found that sites (like fb messenger) which block URLs to certain sites can be easily bypassed by using HTTP Basic Auth with empty credentials. I built a small service (https://rot13.akhil.cc https://rot13.akhil.cc) that takes in a rot 13'd URL and redirects it to the original with HTTP Basic Auth. The nice part is that the credentials are cached, so visiting it again won't show the dialog.

tdeck 5y ago
That's really clever!

yegle 5y ago

It's always easy to add Oauth flow to a website that uses basic auth, by using an identity aware reverse proxy (e.g. https://pomerium.io https://pomerium.io).

kogir 5y ago

My big problem with HTTP basic auth in 2022 (squints at Netgear router) is that in Edge/Chrome 1Password can’t auto complete it. It gets really annoying really quickly.

xnaas 5y ago
Bitwarden has 0 issues 'autofilling' basic auth. It just passes the login credentials on connection and you never see a basic auth prompt.
- jeroenhd 5y ago
  That's actually a gripe I have with Bitwarden, because you can't turn that feature off. If an attacker can take over a single endpoint, Bitwarden will happily send your credentials to an iframe from a malvertiser without ever telling you. It's a fine feature and the WebExtension API won't let them solve basic auth in any other way, but it's a security risk in my opinion. I'd much rather see browsers provide an API to HTTP Basic auth prompts instead so the user can select an identity from the list if they've got a saved username/password combo that matches a given set of requirements.
- watermelon0 5y ago
  It only supports a single user/pass pair for each site. There are many cases where you would want to use multiple identifies and switch between them.
progforlyfe 5y ago
100% this! At least Firefox with 1password seems to handle it okay.
Maxburn 5y ago
Yes, this is one of my major grapes. I’m using LastPass though. The comment below about bitwarden is interesting and I will have to give that a try.

zimbatm 5y ago

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?

jerf 5y ago

HTTP Basic Auth was deprecated a long time ago, back when HTTPS was a very expensive exotic thing that only large sites used. I'm not sure it would be worth deprecating freshly today if it came up, now that anyone who wants HTTPS can get it easily. It may not be the perfect solution to everything but it does fill in a nice space, even in its current form. If browsers would just pay a bit more attention to it it could become very nice; most of its worst quirks are technically in the browsers, not the protocol.

kjaftaedi 5y ago

You should take a closer look at AppWrite, AzureB2C, or Google's Firebase. You can even have Azure or Google connect to your own custom identity provider. It's only a few lines of code to implement user management using identities you control. I get not wanting to get locked into these things, but once you learn how they function, you can switch between identity providers in minutes. I do get the sentiment though, but for something like this my vote would be for certificates instead of basic auth.

nichochar 5y ago

I love simplicity. the reasons you provide for using it are really strong, and I think it's a much superior option to prototyping leveraging oauth 3rd parties (which has tons of downsides). It would be good to have a hard rule as to when you migrate, and what the reasons are (if a project has more than N users, if you store field X which is pretty sensitive, etc..)

1vuio0pswjnm7 5y ago

https://www.ietf.org/rfc/rfc7617.txt https://www.ietf.org/rfc/rfc7617.txt

mholt 5y ago

Caddy comes with basic auth support because it's still useful for a lot of use cases. IMO the biggest weakness of basicauth (when deployed over TLS) is the fact that most server configurations store the passwords in plaintext, usually in a config file. This is like storing passwords in plaintext in a database. Caddy does not allow this. You have to use a secure hash on the password before adding it to your config: https://caddyserver.com/docs/modules/http.authentication.providers.http_basic https://caddyserver.com/docs/modules/http.authentication.pro... Of course, password hashes are slow, so KDF'ing a plaintext string at every HTTP request can grind even powerful servers to a halt. So Caddy can optionally cache hash results in memory (we do expect memory to be safer than a config file -- and Go is a memory-safe language in this regard). And while this can introduce nuanced timing variances (fast if recently hashed), they do not necessarily correspond to correct passwords. If you think this stuff is interesting and want to help make Caddy's basic auth even better, feel free to contribute or sponsor: https://github.com/caddyserver/caddy https://github.com/caddyserver/caddy

LAC-Tech 5y ago
happy new year. Caddy is such a great piece of software. It has great defaults 'out of the box' but at the same time doesn't feel like I'm drowning in incomprehensible magic. We need more software like this!
- mholt 5y ago
  Thanks for the kind words!
- lgvld 5y ago
  Yeah caddy is such an awesome server! ;-)
hasel 5y ago
Is this supposed to be used to put entire domains behind basic auth or should you use it for specific end points?
- 5y ago

throwaway984393 5y ago

Spend an hour to set up an OAuth2 Proxy (https://oauth2-proxy.github.io/oauth2-proxy/ https://oauth2-proxy.github.io/oauth2-proxy/) instead. You can use the one proxy for entire subdomains / unlimited number of apps. No plaintext passwords, scales well, open source, industry standard, and you get SSO for free. Hell, you don't even have to manage accounts! It makes your life simpler and it's more secure. You can't say that often.

skywal_l 5y ago

Stupid question: why not use nginx? Configuring basic auth is about 4 lines of config. Nginx is fairly simple and is overkill only for dev setup for which you don't need auth anyway.

Valord 5y ago
This is what I've been doing for simple projects, easy.

prpl 5y ago

oauth2-proxy is as simple as HTTP Basic Auth (and can also accept HTTP Basic as well) - no great reason to not use it, along with REMOTE_USER header

RedShift1 5y ago
HTTP basic auth RFC is 14 pages. The OAuth2 RFC is 76 pages, and that's only the framework. Perhaps we have a different understanding of what "simple" means...

devmunchies 5y ago

I like basic auth (Header of `Authorization: Basic username:password`) but for persistent session auth I prefer the Bearer tokens[1][2] (Header of `Authorization: Bearer my_token_here`). It's easy to generate a hash after the user logs in and then just store it in a cookie. The user doesn't have to store their password locally and I can delete the token from the database to force them to re-login. You can reuse the same token generation infra for APIs too so its pretty dynamic. I've basically moved away from JWTs in favor of this simpler approach. [1]: (list of auth schemes) https://developer.mozilla.org/en-US/docs/Web/HTTP/Authentication#authentication_schemes https://developer.mozilla.org/en-US/docs/Web/HTTP/Authentica... [2]: (Bearer auth spec) https://datatracker.ietf.org/doc/html/rfc6750 https://datatracker.ietf.org/doc/html/rfc6750

creeble 5y ago
Surprised there aren’t more comments here - does everyone agree that this is equivalent (in security terms) to using JWT? I would very like to never use JWTs again.
- devmunchies 5y ago
  i listen to a few cryptography podcasts and cryptography is an interest of mine[1]. most security engineers agree that JWT has too much of a surface area and takes a lot of care from the implementer that it can lead to security holes[2]. Another reason i like just generating a securiity token when the user logs in is that i can require a join on the table for any query so that its extra secure. e.g. if fetching "posts" for a "user" and i have 3 tables (users, posts, and user_tokens) i can do an inner join like this (if the `posts` table has `user_id`): select p.* from posts p inner join user_tokens ut using (user_id) where p.user_id = $1 and ut.token = $2 -- `users` table wasn't needed for this join since am not selecting from it with JWTs the security happens once when you verify the JWT signature, but then security is less of a focus when making queries, which would complicate queries anyway since you have to make sure the same user who owns the JWT has access to the data (it handles authentication but not authorization). You still need to hit the database anyway for fetching any data so the headless approach for JWTs isn't really saving me much, so I like to just bake in security for the queries. [1]: I recommend new book "Real World Cryptography" by David Wong [2]: (podcast about JWTs from cryptographer, august 2021) https://securitycryptographywhatever.buzzsprout.com/1822302/9020991-what-do-we-do-about-jwt-feat-jonathan-rudenberg https://securitycryptographywhatever.buzzsprout.com/1822302/... -- EDIT: would probably want a few more predicates in that query to account for token status. e.g. where p.user_id = $1 and ut.token = $2 and ut.is_revoked = false and ut.is_expired = false

ufmace 5y ago

I like the reminder that this is out there and mostly available. I think many of the comments here are missing the point - they're saying it's useful for small-time projects with one or a few users and not needing to be integrated into a sophisticated infrastructure. No need to worry too much about hashing, logouts, the full chain of account management, etc. Use a full-featured solution if you need that, keep Basic Auth for a thing with a few admin pages where anything unusual gets handled over SSH. This also reminds me - Gemini uses client certs for a similar purpose. Gemini doesn't seem to have much going on, but it does make a good case for using client certs better. Right now, they're technically supported, but the UI for both browsers and server support is really clunky. Build a decent UI on both sides, and it could be a nice simple solution for higher-security authentication.

ChrisMarshallNY 5y ago

I just use it once, to generate an API key, then use the key, and a server secret (in the basic auth header), after that. The key could be generated by something like Sign In With Apple. Not Fort Knox, but fairly good. Because of FastCGI, I have to have an option to pass login creds in the URL, but that is not by default.

smitty1e 5y ago

One non-technical advantage is prototyping. Going this route says to the consulting client: this is NOT the full solution. This is only work-in-progress. If you treat this as the final delivery and deploy this to prod, you're making a big mistake. Not that I've ever seen that happen, mind you.

worik 5y ago

What is authentication for? What is it protecting? Sometimes the effort and expense protecting a thing is more than the value of the thing protected. Often there is nothing really to protect, "authentication" is just administrative convenience. So simple is best. Cheep and cheerful!

tunesmith 5y ago

I don't know if it really holds up to scrutiny, but I use http basic auth for a semi-public website. It has members (like less than twenty) that I don't know personally other than through the website, but I don't want the website public because I don't want to deal with with TOC, GDPR, legal stuff in general. Once you're past basic auth, it actually does have a login/registration flow, but it seems like I'd need to see a lawyer if I ever wanted to make a member-driven website public and I just haven't gotten around to it yet, so... http basic auth. Is this sound thinking? I don't know.

emj 5y ago
The GDPR/Cookie rules are just the same common courtesy that all projects I've been invovled with always has had. No ad trackers and no personal data stored about what I did on the site unless necessary for the function provided. There is no exemption for personal sites. Point being, I'm from the EU but some times that has not always been important and only come up after working with someone online a couple of years. Basically; HTTP Basic auth does not make you website anymore private than a login page. Just treat you users fair and be straight forward with what you do with the data, and you won't need any lawyers.

bdcravens 5y ago

I use it for an internal API that needs credentials to make additional calls. It lets me keep the HTTP semantics super clean.

efitz 5y ago

I died a little inside reading this article. Clearly we have a lot farther to go with secure development lifecycle evangelism.

tzahifadida 5y ago

The problem is not with small projects. Who cares if it gets hacked. The problem is with real life SSO. If you used a 100 apps and 1 gets hacked then you have to change the other 99 passwords. Sound bad right? That is why you should not use basic auth and use openid connect or similar tech. Sometimes it is a bank, and no SSO involved. It is not well understood but SSL has termination points. E.g. the gateway and each gateway all thru the last layers. SSL becomes vulnerable at these termination points. If basic auth is used, then you just lost a whole lot of cash. Otherwise use challenge response, encrypted passwords within the SSL, and all kind of out of this world tech for risk assessment. Basic auth? Really?

tlrobinson 5y ago

I used to use Basic Auth for small personal/internal services, but these days I prefer a proxy like Traefik/NGINX with a simple authentication service like Authelia or Traefik Forward Auth. It’s a little more work to setup but not much and there are a bunch of benefits: SSO across multiple services, control over session expiration, works better with password managers, 2FA, etc.

deleted 5y ago

[deleted]

incanus77 5y ago

I don't recall seeing a lot of good info on how to use HTTP Basic Auth back in the day, to the extent that in 1998 I wrote my first technical how-to to post on my own website. It still lives on here: https://codesorcery.net/old/authentication/ https://codesorcery.net/old/authentication/

thorum 5y ago

As a counterpoint, learning the basics of a good OAuth library or service like oauth2-proxy, auth0, next-auth or keycloak is well worth your time as a developer. Once you get over the initial learning curve, it’s almost as easy to add to a project as basic auth. You don’t need to reinvent the wheel with each project, building login pages and database code - other people have done the work for you - and you can create a more usable and professional experience for your users.

kevincox 5y ago

I have always wondered how feasible it would be to use the basic auth URL syntax for thinks like API tokens and email validation. Ideally these values would not be logged but if you want a user to click them they basically need to be in the URL. So either you don't log URLs or you need to redact all of these parameters. Most systems are smart enough to avoid logging passwords so if you could just use URLs like randomtoken@example.com/confirm-email. However it seems like browsers usually put up scary warnings and most email providers will consider this a spammy/scammy pattern. Of course another problem here is that you just want it for one URL, whereas basic auth is usually preserved for the session.

Shadonototra 5y ago

HTTPS is a mess, certificates are a mess Not everything needs it and yet it is mendatory for everything you want to do Just had get throught all of that mess for a simple websocket This is beyond sad

LinuxBender 5y ago

I still use basic auth as a quick and dirty way to protect a link when emailing files to friends that are still on gmail. It keeps the Google bots off my files.

pronoiac 5y ago
I've been considering basic auth for projects I spin up on subdomains, as I think there could be bots watching https registrations.

geenat 5y ago

Easiest way to defend against brute force attack? How does one rate limit? The only thing putting me off using HTTP auth is this. Seems like you need NGINX configured to hold state and be the rate limiter.

hnick 5y ago
You can use a slow validation function (bcrypt) to naturally rate limit login attempts, or log login attempts somewhere and do it based on that in the code layer. Most login schemes will have at least a basic database with a users table so it isn't much extra effort to check during validation.

r1ch 5y ago

Basic Auth has become increasingly difficult to use as a generic way to protect a web app. Many apps these days have endpoints that respond with 401 when a user isn't logged in, which if you're fronting the application with basic auth, results in the user being "logged out" as the browser thinks the credentials are no longer valid. The hijacking of HTTP status codes by client-side apps wanting to interpret them in their own way makes me think we need a new range of codes for user-defined statuses.

ChuckMcM 5y ago

Also has the benefit of discouraging crawlers.

jacobsenscott 5y ago

It seams firefox caches bad basic auth creds. It is so annoying because there are several sites where I can only do a basic auth login from a private window. If I go there in a regular window I just get the invalid authentication error, and no option to enter a new username/password. It isn't clear where this is cached either, so it is very difficult to clear that cache.

andrethegiant 5y ago

Looking at that screenshot I bet the password is 1234

jijji 5y ago

a good example of doing Auth-Basic in PHP is https://www.php.net/manual/en/features.http-auth.php https://www.php.net/manual/en/features.http-auth.php

fullstackchris 5y ago

Easiest auth I've found is Netlify identity: https://docs.netlify.com/visitor-access/identity/ https://docs.netlify.com/visitor-access/identity/ It's usually a one liner to add to apps. Reach for Auth0 when you need authentication a bit more down to the metal.

wraptile 5y ago

FYI Python can server http basic auth straight out of the box! I wrote this tiny wrapper Sauth[1] that has been a real life saver for delivering minor WIP stuff to clients who are not in the whole cloud ecosystem - just type in url and put in your credentials to see the latest files. 1 - https://github.com/Granitosaurus/sauth https://github.com/Granitosaurus/sauth

ChicagoDave 5y ago

The primary flaw isn't BASIC AUTH. It's the password itself. Brute force attacks are easy. The only good way of securing anything is through an Authenticator app.

anaganisk 5y ago
And all that takes to break it is a compromised version floating around in WhatsApp groups saying Authenticator plus would give u blue theme.
lucb1e 5y ago
You can still have the server trigger an authentication confirmation when using basic auth. Web servers not coming with authentication apps is not a flaw, it is a completely separate component and scope.

a-dub 5y ago

i kinda miss .htaccess

ungerik 5y ago

Surprise of 2022: you get to the top of HN by telling the world about HTTP Basic Auth ...I am getting old ;-)

codazoda 5y ago
You and me both. I’m just as surprised as you. Nice way to start the year off though. :)

outloudvi 5y ago

I think that Basic Auth is still working as is, so actually... why not?

pabs3 5y ago

I wish browsers supported client TLS certs better, the UI is usually terrible and client-side key generation got dropped from some browsers.