I’m implementing a simple login system to a web app where no critical or private info is handled or stored, and I want to provide eavesdropping protection for login data transmission.
I’m already running https module of apache, but sometimes is not at option due to port access restrictions and some other issues so,
In order to not overcomplicate things and still offer a reasonably good protection in those cases, here’s my thought on a quick-and-cheap protocol, and my big question about it is if (and why, if you please) is it any good or a big no-no to do this kind of workaround:
-
On the login form, the client receives 2 random length (not too short not too long) text strings (which the server generates and keeps on $_SESSION var just for one check) along with server’s public gpg key.
-
User + string1 and pass + string2 are javascript gpg-encoded with server’s public key before being sent to the server.
-
Server recovers transmitted login info gpg decrypting with private key and removing strings, hashes the pass an checks if there’s a match stored for that user, returning login error / granting access to the app with that user’s profile until the end of the session.
I understand this only protects login info (and not against any man-in-the-middle attack faking the server, if I needed this I would simply force https), which combined with some basic sessionid theft protection techniques should prevent passive eavesdroppers from accesing the system with stolen credentials, if I’m right.
Should I implement this or is it a waste of time and resources?
Protecting the login is meaningless when you spill the real authentication token (the session id) a few milliseconds later. The session id must be protected with HTTPS though out its entire life, at no point can this value be transmitted over plain text or you will be in clear violation of OWASP a9.
The attacker is all like:
“Oah nice you authenticated that session for me, I’ll just take that cookie value and authenticate as that user, thanks!”