Hacker News new | comments | show | ask | jobs | submit login
Ask HN: Why isn’t HTTPS and Basic Auth as common as cookies?
7 points by boramalper 5 months ago | hide | past | web | favorite | 10 comments
I was considering which authentication method to use for a simple web front end of my application (which also provides a REST-ful API) and I cannot see any compelling reason why I should prefer form-based authentication w/ cookies over basic auth.

Someone asked on stackexchange “Is BASIC-Auth secure if done over HTTPS?” and the most upvoted answer is:

> There are a few issues with HTTP Basic Auth:

> 1. The password is sent over the wire in base64 encoding (which can be easily converted to plaintext).

> 2. The password is sent repeatedly, for each request. (Larger attack window)

> 3. The password is cached by the webbrowser, at a minimum for the length of the window / process. (Can be silently reused by any other request to the server, e.g. CSRF).

> 4. The password may be stored permanently in the browser, if the user requests. (Same as previous point, in addition might be stolen by another user on a shared machine).

None of his/her reasons seem compelling to me though. TLS protects the password on transmit so #1 is no longer a concern. I’m unsure what the attack scenario is with the #2 so I don’t know what a “larger attack window” really entails; MITM, replay attacks... (all of which TLS protects from)? Regarding #3, cookies are also susceptible to CSRF but unlike basic auth, there are methods to protect against that; though I cannot see how CSRF can cause any harm if GET is idempotent as intended (except wasted bandwidth maybe). Lastly, cookies are also stored in the browser for a very long time if the user requests so I don’t think #4 is really valid either.

I believe the most concerning/valid point of all is #3, and yet I still don’t think it’s something I need to worry about. Am I mistaken? Is there anything else that one should be aware of for the sake of security?


[1]: https://security.stackexchange.com/a/990

> 2. The password is sent repeatedly, for each request. (Larger attack window)

We, for example, have a different web service for authentication. That's literally all it does, it checks username/passwords, generates a token, returns a cookie, and then is never used again for that user's life cycle.

This allows us to set database/table permissions such that a compromise in any other part of the web site cannot trivially be leveraged into a credentials theft (even hashed credentials), and are able to deploy the authentication web service in a minimal state.

That is harder with basic auth, you'd likely need a request filter in front of every incoming request (inc. error pages). This means that every web server/web app instance you deploy needs access to user credentials.

Plus it gives you the flexibility to easily expire a single user or ALL user's active sessions just by either removing their token from a table, or rotating the encryption key(s) that are used to protect your authentication cookies.

I'd offer a few more reasons:

- No great way to offer forgotten password/help (or alternative workflows, such as "create an account").

- Focus stealing login dialogs that hold the user hostage (& bad browser implementations in general).

- Dialogs cannot be styled to the site/page

- Error workflow is clunky, no in-line errors/warnings e.g. "Your username should be an email address."

- Worse password manager support

The quoted points are all no worse than cookies.

Regarding point 3, the csrf problem is there with cookies as well.

One annoyance with basic authentication is the logout button problem (you can only kludge it by failing to reauthenticate as a different user). This is a flaw in the browser basic auth implementations of course, not basic auth or your app, but the user will not be consoled by this fact.

There is also UI/UX to consider, e.g. no "I forgot my password" button in the basic auth dialog. So you have to rely on error page handling this case and if you have to go to this lengths, why not scrap the whole basic auth in the first place?

Further, you can't show flashy banners with questionable by profitable content during a basic auth dialog...

I agree.

If I remember well, in old browsers (netscape 4.x, IE 3) when you had enough bad login attempts, you got stuck on the 403 forbidden page and you had to restart the whole browser just to try to login again.

Of course you could have a 403 page with the I fogot my password mechanics; but that was very uncommon. Some servers (Apache) would allow you to do that but that was an exception, not the rule.

Oh yes, UX is definitely a concern, but I was more worried about the security implications of it. Also, users are so accustomed to form-based logins that a modal dialog from the browser might even freak some out.

Now thinking about it, I think two-factor authentication would also be impossible with Basic Auth, and surely that’s a legit security concern.

For the record, my app is a small self hosted solution so changing your password is as simple as updating a credentials file and sending a SIGHUP to the daemon.

With http cretentials, if you change your password while authenticated you'll get a 403 .

Form+Session[Cookie||LocalStorage] is much more flexible.

Wouldn't refresh work?

The user can press cancel, or give the wrong password, and then the application can serve a custom page containing a "forgot password" button.

As others have said, things like CSRF can easily be an issue with cookies as well.

The deciding issue has always been UX for me. If browsers had done a bit more on this in the early days (in particular, a logout button), HTTP Auth could have been a compelling alternative. I think that ship sailed about 20 years ago, though...

Other reasons to use cookies for session management include the fact that you can use them to store data about users who aren't logged in. That logging a user out is more straightforward. And that you can store additional data in a cookie if you want to.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact