I want to include secure login in a website and, given the threat model, I am wondering if I can safely drop back to a faster plain connection like this:
- Over a secure connection, negotiate a random token
T. This is stored in a cookie. - The server stores
f(T)=hash(private_salt,T,username,password,$_SERVER['REMOTE_ADDR']) Tis shared later on over unencrypted connections. The server recomputesf(T)to authenticate the connection.
The idea is that T represents no particular information, and even if it is stolen, a connection from a different originating IP address will cause the a different f(T) to be calculated.
The obvious weakness is session theft behind NAT. Let’s say we can dismiss this in practice. The question basically boils down to: how easy is it to spoof a connection, preserving $_SERVER['REMOTE_ADDR']?
This website requires only moderate security. There will not be sensitive traffic. The threat model is basically to cope with vandalism. I only need to deter bored people, not the Russian mafia. Given this assumption, is the above protocol sufficiently secure?
Also, let’s assume this happens with a regular web browser and LAMP — for the secure password transmission, is https the only game in town? It seems like Diffie-Hellman Key Exchange or similar would be sufficient (impersonation of the server is not in the threat model) and does not require all that signing malarkay. Is there a standard apache/php module for this which most browsers support?
Bad idea.
I used to be on a big network that had multiple IP addresses. Every request I made was assigned to one of the IP addresses by a load balancer. Effectively this meant that my IP address was rarely the same in two consecutive requests. I would be logged out of your system every time I loaded a page.
You could try using
$_SERVER['HTTP_USER_AGENT'], as this will require the cookie thief to either have the exact same browser or (assuming the threat model allows for sufficiently skilled vandals) to forge the exact same UA string. That said, if you don’t tell anyone you check the UA string, it could be puzzling to less-skilled hackers to work out what your server is rejecting about the “perfect good” session cookie.