Humour, comics, tech, law, software, reviews, essays, articles and HOWTOs intermingled with random philosophy now and then
Filed under:
Software and Technology by
Hari
Posted on Sat, Feb 7, 2009 at 21:14 IST (last updated: Sat, Feb 7, 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:
- Server expects password in encrypted form sent over HTTP.
- A genuine client does the encryption using JavaScript and then submits the password
- Somebody steals this "hash" by listening to the HTTP packets over the network.
- 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.
- 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)
Comment by drew (visitor) on Mon, Feb 9, 2009 @ 11:13 IST #
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, Feb 9, 2009 @ 18:25 IST #
Comment by MrCorey (visitor) on Mon, Feb 9, 2009 @ 22:10 IST #
Comment by Hari (visitor) on Mon, Feb 9, 2009 @ 23:35 IST #
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, Feb 10, 2009 @ 17:33 IST #