Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

I am doing a token based authentication but facing some security problems. In the system, a user will login as follows:

  1. Type username and password to login in a https login page
  2. If the login is succeeded, the server will be set a 'authentication cookie'. Otherwise, go to login page again
  3. The 'authentication cookie' in every request will be used to identify the user.

I think this is secure if the request is under https because the 'authentication cookie' cannot be stolen easily due to encryption of SSL. I don't want all pages in my website can be accessed under https only. However, if the page can be accessed under http, then connection may subject to 'man-in-the-middle' attack. If the data in cookies is copied, then it is game over.

What is good practice of cookie-token based authentication under http ? Could you give me the detailed implementation about the good practice?

share|improve this question
1  
any specific reason as to why not use SSL throughout the whole application? That would the best 'best-practice' in this scenario. Also make sure the cookie has the HttpOnly flag set and if you do go for SSL across the whole application, make sure you also use the 'secure' flag. –  Lex Dec 3 '13 at 12:05

2 Answers 2

up vote 2 down vote accepted

A central tenet of OWASP - Insufficient transport layer security is that the session ID is never leaked over HTTP. Although mixed content sites are a bad idea from a security perspective, one way that it can be done is using the Secure Cookie Flag which will tell the browser not to include the session ID in non-HTTPS requests.

If you host any HTTP page, then an attacker could introduce JavaScript in a MITM to compromise an authenticated session. HTTPOnly cookies would prevent the malicious JavaScript payload from reading the cookie value, however the payload could still read authenticated pages using an XmlHttpRequest, obtain CSRF synchronization tokens, and perform unauthorized actions. The solution is to use HTTP-Strict Transport Scrutiny, which also solves the problem of SSLStrip.

HTTPS is extremely light weight and you will see about 1%-2% increased CPU usage when using HTTPS over HTTP. Not using HTTPS because of some illusions of efficiency is a mistake. HTTP/2.0 may be HTTPS Only.

share|improve this answer
1  
@apsillers I updated my answer, I went into greater detail into that attack as it is important to my argument. –  Rook Dec 4 '13 at 19:41
    
Is Facebook using authentication cookie? If yes, why Facebook do this? Facebook can be accessed under HTTP and it is not secure. If no, could you explain its authentication implementation? –  Timespace7 Dec 9 '13 at 16:11
    
@Timespace7 Facebook uses an OAuth token passed as a cookie or HTTP header and protected by HTTPS. –  Rook Dec 9 '13 at 18:30

Rook makes some good points - just to expand a little...

cannot be stolen easily due to encryption of SSL

Only if set the secure flag on the cookie - otherwise a MITM could inject (for example) an iframe in a seemingly innoccuous web page pointing to your server using http and sniff the returned cookie.

A further problem is that of session fixation - again if your browser thinks it's visiting your server via HTTP and receives something which looks like a session cookie, your SSL wrapped authentication may default to re-using that value for the authentication token (session fixation). You need to ensure that your code generates a new token when the user tries to authenticate.

Then there's the possibility of a XSS (cross-site scripting) attack where a bit of javascript can read the cookie and relay it elsewhere e.g. via an img tag - setting the HTTPonly flag on the cookie prevents this.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.