A few days ago, I was sitting in a cafeteria of USC and browsing the internet on their public WiFi, when I needed to log on to some site. Unfortunately, as many sites do, this one did not use SSL by default, which meant that my username and password would be submitted in the clear. What is the reason for this gross lack of security? I imagine that many people can't afford an SSL certificate, especially if the site is a hobby project or a blog. Even so, however, there's absolutely no reason why every Wordpress/Drupal/etc website submits credentials in the clear. Much of the time, people don't have much of a choice on using a public WiFi hotspot, and even though they might consider session hijacking an acceptable risk, it's absolutely unacceptable for an eavesdropper to obtain the plaintext password you use for that site. It's even more unacceptable when we consider that ways to perform secure authentication have been around for ages. To this end, I would like to propose a solution for performing reasonably secure authentication over HTTP. The proposed approach
Preventing the transmission of a plaintext password is pretty easy: Just hash it. There's a problem with that approach, though, and it's that the attacker can just store the hash and use it to log on to the website again and again. CRAM-MD5 is designed to solve this exact problem, by sending a one-time challenge to the client and having them hash that together with the plaintext password (of course, we don't have to use MD5, any hashing algorithm will do, and SHA is preferred). The server performs this procedure as well and compares it to the response it got from the client. If they are identical, the client obviously knows the password, and can authenticate. The problem with this is that it doesn't work in a stateless protocol. Whatever we use for state, the attacker can just pass it back and pretend to be the user. A possible solution for this problem is to use the IP address of the client as the challenge. This will prevent the attacker from logging in, unless they have the same IP as the user. We could also make the response expire by including the current date (plus a few minutes) in the challenge, so that the response will be invalid after a minute, for example. This solves most of our problems, and is, at any rate, much more secure than the weakest link in the chain, which is session hijacking. The second problem
The second problem with this approach is the fact that, to verify the password, the server needs to have it stored as plaintext. This is another serious lapse of security, so we need to address it. Read more: Stochastic Technologies' official blog
Preventing the transmission of a plaintext password is pretty easy: Just hash it. There's a problem with that approach, though, and it's that the attacker can just store the hash and use it to log on to the website again and again. CRAM-MD5 is designed to solve this exact problem, by sending a one-time challenge to the client and having them hash that together with the plaintext password (of course, we don't have to use MD5, any hashing algorithm will do, and SHA is preferred). The server performs this procedure as well and compares it to the response it got from the client. If they are identical, the client obviously knows the password, and can authenticate. The problem with this is that it doesn't work in a stateless protocol. Whatever we use for state, the attacker can just pass it back and pretend to be the user. A possible solution for this problem is to use the IP address of the client as the challenge. This will prevent the attacker from logging in, unless they have the same IP as the user. We could also make the response expire by including the current date (plus a few minutes) in the challenge, so that the response will be invalid after a minute, for example. This solves most of our problems, and is, at any rate, much more secure than the weakest link in the chain, which is session hijacking. The second problem
The second problem with this approach is the fact that, to verify the password, the server needs to have it stored as plaintext. This is another serious lapse of security, so we need to address it. Read more: Stochastic Technologies' official blog
Posts
0 comments:
Post a Comment