Sat, 7 Feb 2009

The great HTTP security issue

Filed under: Software and Technology by Hari
Posted at 21:14 IST (last updated: Sat, 7 Feb 2009 @ 21:14 IST)
Everybody who uses any kind of web application has come across some kind of login situation or the other. Whether you are accessing an e-mail account or a social networking site, a discussion forum or any other personalized web service you usually log in with a unique user name and password.

Generally web developers are very keen on encrypting passwords and other sensitive information on the server itself, so that any compromise on the database does not lead to a leak of such data. But what developers cannot guard against is attacks against the HTTP protocol itself, which transmits everything as plain text, even an encrypted hash. So a security conscious web developer who encrypts every bit of information his application collects from the end user will still not be 100% safe against crackers.

The problem is that even if you encrypt passwords at the server side and make sure that the client side also encrypts the same password before submitting it to the back end script (using client side scripting, for instance), the hash itself can be stolen because HTTP transfers the hash as plain text.

Consider the sequence of events in such a case to allow for better understanding of how this problem is acute, especially with user authentication using passwords:
  1. Server expects password in encrypted form sent over HTTP.
  2. A genuine client does the encryption using JavaScript and then submits the password
  3. Somebody steals this "hash" by listening to the HTTP packets over the network.
  4. This cracker realizes that the password is a hash by studying its contents. By disabling JavaScript on his client-side, the cracker easily bypasses the security measure and uses the hash itself as the password. The server, expecting that, allows the login.
  5. The user gets compromised even if the hash cannot be decrypted because the server expects the hash.

Even if the client does not encrypt, the problem remains. Basically it is the problem of the protocol itself, not the web application. So it cannot be solved by the web programmer himself. That much is obvious to everybody.

So as far as I am concerned, I think that HTTP will slowly fade away and HTTPS will become more and more in use in the near future even for websites that don't necessary deal with monetary transactions.

5 comment(s)

Leave a comment »
  1. Yeah and actually running SSL with Apache to secure a website is like zero overhead in most cases.

    Comment by drew (visitor) on Mon, 9 Feb 2009 @ 11:13 IST #
  2. The big problem right now is the SSL providers. No one wants to visit websites that are self-signed, or use a domain-validation only certificate, and the SSL providers charge money for the certificates.

    I don't see SSL taking off simply because there are millions of people who won't buy the certificates. I wish someone would invent a secure protocol that greedy people can't control.

    Comment by RT Cunningham (visitor) on Mon, 9 Feb 2009 @ 18:25 IST #
  3. Well put, RT.

    Comment by MrCorey (visitor) on Mon, 9 Feb 2009 @ 22:10 IST #
  4. Hey I m working as a SA and this was really useful to me. Btw, Can we exchange links?

    Comment by Hari (visitor) on Mon, 9 Feb 2009 @ 23:35 IST #
  5. Drew, yes, actually I agree with RT's point: it's the providers that is the problem. It's not that nobody wants the extra security of HTTPS. It's that obtaining a trust-worthy certificate is a stumbling block. Also I think we need a purely secure protocol for normal HTTP sites without any of this "trusted certificate" problems.

    Certificate authorities always charge money and self-signed certificates aren't as trusted.

    Hari, thanks for your interest in my site. At present, I'm not into exchanging links, etc. However, I will link to your site if I find your content interesting and you are free to do the same.

    Comment by Hari (blog owner) on Tue, 10 Feb 2009 @ 17:33 IST #

Leave a comment

First-time comments on this blog are moderated.
Your name*
Email ID*
(wont' be published)
Website
Your comments*
(No HTML allowed)		 :-) :-D :biggrin: :-P ;-) 8-) :-( :mad: |-| :oops: :-/ :-| :roll:
bold italic quote code
Code* captcha Enter the code you see in the image
* required fields