31

Why almost all websites out there are using cookies instead of basic auth? It can't be only that the user/pass window is ugly and none of them is more secure. They are both insecure (without https).

loxs
  • 1,476
  • 1
  • 12
  • 27

3 Answers3

19

To logout of a basic auth login the browser often needs to be quit entirely. This means there is no way for the server to log out the user.

I believe basic auth also has more overhead (assuming your cookie size isn't massive), but I might be wrong about that.

HTTP basic auth also sends the username and password with every request, making it potentially less secure because there is more opportunity for interception.

Andrew Marshall
  • 95,083
  • 20
  • 220
  • 214
  • 2
    1. What does it mean to "logout" the user? If the user is able to login back right away, why would I want to logout them? The only valid way of "logging someone out" is if I make it impossible for them to continue to use the site. And that can be always done by changing the user credentials (or invalidating them). 2. The overhead is the only reasonable explanation for me (so far), as the server would need to do a password check on every request. 3. Cookies are sent with every request. Firesheep can hijack every single request. – loxs Feb 19 '11 at 18:42
  • 4
    Cookies store a session ID, you can delete the associated session on the server and effectively log out the user since the cookie is no longer associated with a login. Users expect to be able to log out of a site without having to quit the browser. Hijacking a session ID from a cookie is less severe than getting the actual username and password, especially if important actions require the user to enter their password even if they're logged in. – Andrew Marshall Feb 19 '11 at 18:47
  • Agree, this is a valid use case of cookie sessions. Though, I can't think of a great number of websites that really need what you describe. Most websites' "logout" links never get clicked. So this still isn't an answer to my question. What makes it so that virtually everyone chooses cookies. – loxs Feb 19 '11 at 19:04
  • 2
    If the user is using a computer not their own they're very likely to want to click the log out link. Also, the un-customizability and obtrusiveness of the basic auth login dialog is a huge reason for why most sites choose cookies instead. Basic auth is just that: _basic_. – Andrew Marshall Feb 19 '11 at 19:08
  • 3
    But basic auth is _designed_ for auth, and cookies are not. Cookies are an abuse over the http protocol, which has nice hooks and error codes and everything if used properly (and basic auth is _proper_ in this aspect). – loxs Feb 19 '11 at 19:12
  • Besides, logging out when you are on a computer you don't own is darn easy. Just close the browser! – loxs Feb 19 '11 at 19:15
  • Cookies are designed for storing user data. How is storing a session ID an abuse of that? Cookies don't do the actual authentication, you can just as well store a session ID for an unauthenticated user. – Andrew Marshall Feb 19 '11 at 19:17
  • Hm, you are right here. Then the auth itself is just an ugly window to ask for user and pass. – loxs Feb 19 '11 at 19:24
  • 2
    @Andrew Marshall: +1 for pointing put `HTTP basic auth also sends the username and password with every request, making it potentially less secure because there is more opportunity for interception` – Marco Demaio Apr 29 '11 at 15:47
  • This is incorrect it depends on how HTTP basic auth is handled by the web server or, indeed, the script behind it. Also with HTTP basic auth you don't have to send the password every time, once authenticated you can set a session cookie or use a token for the rest of the users session. Like I said it depends how you implement it on the backend. –  May 18 '11 at 13:13
  • @loxs "Then the auth itself is just an ugly window to ask for user and pass" << doesn't have to be with javascript you can use a HTML form and pass the details to a ajax call or set the HTTP header. –  May 18 '11 at 13:15
  • @andicrook You seem to not know what [HTTP Basic Auth](http://en.wikipedia.org/wiki/Basic_access_authentication) is as everything you just said is false. See also [HTTP Basic Auth FAQ](http://httpd.apache.org/docs/1.3/howto/auth.html#basicfaq). – Andrew Marshall May 18 '11 at 16:00
7

You have more control over cookies. You can encrypt them so that they are secure even without HTTPS. Basic auth is always unsecure over HTTP. Also cookies don't contain the password on each request. And, yes, what can I say, users like AJAX login forms and nice animated effects when logging in which unfortunately cannot be achieved with basic auth.

Darin Dimitrov
  • 1,023,142
  • 271
  • 3,287
  • 2,928
  • 6
    I wouldn't say an encrypted cookie is more secure than an unencrypted one. One way or the other, if you have the cookie, you can log in. So for the man-in-the-middle, it doesn't matter if your cookie is encrypted. Firesheep proved this. – loxs Feb 19 '11 at 18:22
  • 1
    @loxs, yeah, I agree, HTTPS is the only (at moment) reliable and secure way to be used. The thing is that if a cookie is encrypted with a sufficiently strong key, it would make it impractical for the standard hacker who doesn't dispose with some special hardware to brute force it before it's validity expires. – Darin Dimitrov Feb 19 '11 at 18:23
  • 5
    The hacker usually wouldn't care to find out what's the data stored in the cookie. As long as they can log in to the victim's account. – loxs Feb 19 '11 at 18:29
  • 2
    See my comment on my response for why hijacking a session can be less of a security risk than getting a username and password. – Andrew Marshall Feb 19 '11 at 18:49
  • There are several techniques such as randomising the session id with every request and resetting the cookie. This can be forced with a timed background operation on the page whether the users navigates within the site or not. This can be compounded with browser fingerprinting so if the same session id is stolen and reused it can be invalidated by the server. In short you can make the window of usefulness of a stolen cookie very small. Still, all of this is security through obscrurity. SSL is the only secure method to login and CONTINUE browsing a site. – Monstieur Feb 19 '13 at 10:46
  • Well actually you **can** show a beautiful HTML/CSS login form which performs an AJAX request to login using basic auth under the hood. That's what I'm doing on my current project and it's an SPA. – Mickäel A. Apr 09 '16 at 13:24
1

With cookies you have the complete control on when to authenticate the user, its not as soon as theres a request.

Plus you dont have to authenticate for pictures as well

Another thing is that you dont have to rely on a sysadmin for auth.

You also have the choice regarding the users repository with session.

There are other things. As you said, both are more or less secure so why not opt with flexibility? To showcase sites to clients we often use server auth as it is easy and a global solution.. for forms within apps, we use cookies.

Mike Gleason jr Couturier
  • 9,018
  • 4
  • 40
  • 59
  • 2
    That depends on the implementation. With frameworks like webmachine (erlang) you decide for what addresses to require auth. You don't need to rely on a sysadmin. You can store your passwords in a database of your choice. – loxs Feb 19 '11 at 18:36