
Ask HN: Why isn’t HTTPS and Basic Auth as common as cookies? - boramalper
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&#x2F; cookies over basic auth.<p>Someone asked on stackexchange “Is BASIC-Auth secure if done over HTTPS?” and the most upvoted answer is:<p>&gt; There are a few issues with HTTP Basic Auth:<p>&gt; 1. The password is sent over the wire in base64 encoding (which can be easily converted to plaintext).<p>&gt; 2. The password is sent repeatedly, for each request. (Larger attack window)<p>&gt; 3. The password is cached by the webbrowser, at a minimum for the length of the window &#x2F; process. (Can be silently reused by any other request to the server, e.g. CSRF).<p>&gt; 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).<p>None of his&#x2F;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.<p>I believe the most concerning&#x2F;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?<p>Thanks!<p>[1]: https:&#x2F;&#x2F;security.stackexchange.com&#x2F;a&#x2F;990
======
Someone1234
> 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

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

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

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

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

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

~~~
boramalper
Wouldn't refresh work?

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

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

