Reputation: 19713
I know it's a bad idea but I need to do this. I'm about 8 weeks away from getting a new server where I can have a working SSL'd application. So for the next 8 weeks I need to make it hard for someone to eavesdrop my app.
One idea I had was, as the user entered their email address and password and clicks login, I write to the database a very unique and random password (maybe timestamp + ipaddress) to a column 'latestAttempt', next to their login details. When the request reaches the login script page, it checks to see if that IP address has tried to make a login in the last 1 minute. This should at least prove that the login details came from the login page.
I know I can't stop it but I would like to make it difficult. Are there any other methods out there that could temporarily put off eavesdroppers, while I wait for my new server with SSL?
UPDATE
I understand why this proposal wouldn't work, I'm not sure why it even came to my head to be honest, it's a load of rubbish!
Upvotes: 3
Views: 1275
Reputation: 67019
Your proposed solution will not prevent an attack. The user name and password i used to obtain an authentication token, which we often call a cookie value in the context of a web application. If this authentication token is transmitted in plain text then You are in violation of owasp a9. In short this proposed security system is absolutely worthless.
Upvotes: 1
Reputation: 122649
It's not clear what makes you think that making sure the user comes from a specific previous page will prevent attacks. Why wouldn't an attacker be able to do this?
If you want something a little bit more secure (although not perfect), switch from form-based authentication to HTTP Digest authentication. This will break a little your user interface, since it relies on a pop-up implemented within the browser (and doesn't easily allow you to log out without closing the browser), but at least, the username and password won't be transmitted in clear.
Upvotes: 2
Reputation: 415705
Your proposed solution won't help. The purpose of SSL is to prevent eavesdropping on the password as it is sent over the wire from the browser to your server, and no amount of timestamps/checking repeat logins will help stop that.
In the absense of SSL, there's not much you can do that is really secure, in the truest sense of the word. What might help in at least a small way is to use javascript to scramble the password before posting it to your server. Even better if you can find a javascript library that implements a real encryption algorithm, preferrably using public/private keys since the the encryption method will be public.
Upvotes: 6