Stealing my POST data

Question

Okay, this is probably quite basic, but the implications are important to me in this phase of development. I am thankful for any input and discussion.

The data in this example are not protected using SSL encryption.

---

page1.php/asp contains a form which POSTs the variables username and password to page2.php/asp.

---

• Can ANYONE from ANYWHERE intercept my POST data just by listening for it, perhaps with some third party software like Firesheep?

If the above question renders TRUE:

• Should I always consider my unencrypted POST data freely available for anyone?
• Are the standard login form on my site just a ploy to depict a layer of security that's not even there?
• Should I then consider the login feature just as a way for me to personalize the user experience?
• Does it make sense to encourage the user NOT to use his or her normal (assumed safer) password, since it won't be protected during their registration and login procedures?

I ponder these issues, I appreciate any input and feedback.

Katleen

Answer 1

Can ANYONE from ANYWHERE intercept my POST data just by listening for it, perhaps with some third party software like Firesheep?

No, the traffic has to pass near them.

If the above question renders TRUE:

It doesn't, but even so.

Should I always consider my unencrypted POST data freely available for anyone?

Unless it only travels across a LAN, then yes. If it does only travel across a LAN then add the qualifier "on that LAN" and the answer will be yes.

Are the standard login form on my site just a ploy to depict a layer of security that's not even there?

No

Should I then consider the login feature just as a way for me to personalize the user experience?

Certainly you shouldn't do anything serious without encryption.

Does it make sense to encourage the user NOT to use his or her normal (assumed safer) password, since it won't be protected during their registration and login procedures?

It would make sense to do so for any system. Even if the communication was secure, your server could be compromised in the future, or a third party system could be and then the data there used to attack your system.

Hawkes

Thanks David, your reply answered all my questions. Your final remark show that you actually got what I meant with the question :) – Katleen

See @MattGibson post. Traffic interception was often theoritical on a LAN. When using Open wifi, it is happens all the time. – Energetics

Answer 2

When the user submits the login form through unencrypted HTTP, their data gets sent to your server by traveling through a series of routes. At any one of these routes, yes, someone could sniff the data. Also if the user's machine was infected, the hacker could sniff the data locally.

If it's a login form you should be using SSL, period. Also make sure the user's password is encrypted in your database. The process for logging in should be:

1. User submits login via HTTPS with username and password
2. Server takes password and applies a hashing algorithm to it, generally using MD5, though something strong like SHA256 is recommended
3. Server compares encrypted value to encrypted value in the database

That way, if your database is ever hacked, the passwords are very VERY difficult to figure out (unless they used something basic like 'password', but that's their fault at that point).

Does it make sense to encourage the user NOT to use his or her normal (assumed safer) password, since it won't be protected?

You'll be driving users away.

Brigette

Note: md5 and SHA are not encryption, they are hashing algorithms. – Octavalent

Also, salt your hashed passwords to avoid deciphering of your users' passwords via rainbow tables. And rehash them a number of rounds to make brute-force attacks nearly useless. Both to prevent that, if someone gains access to the hashed passwords, may get what was the original plain-text password. – Autocracy

Thank you for your nice answer. I am already hashing the passwords before storing them in the database using sha256 on the string. The string consists of the password provided, a "random" variable that's definite for this user, plus a longer string that's the same for every user. This means that access to the site is protected, however, the INTENDED password sent by the user is not. This concerns me. – Katleen

@Katleen as I noted, when sending login data, use HTTPS, period. The worst part about someone sniffing unencrypted data between routes is that in most cases you don't have control of the servers, so you have no way to monitor an intrusion and realize that the user's password is stolen. They only find out when some account they own is hacked. – Brigette

Answer 3

Yes. Anyone who can see the packets passing through can see the username and the password. This makes it especially vulnerable when on open, shared Wi-Fi networks and the like.

I'd say that all your assumptions ring true, and this is especially why it's bad practice to share passwords between services, especially where those services have different levels of security.

I would advise you to move to SSL login if you can, partly because so many users will ignore any advice you give them about using a common password, and partly because it's just good practice. It was good practice before things like Firesheep became so easy for "normal" people to use, and it's even more important now.

Soot

Answer 4

Should I then consider the login feature just as a way for me to personalize the user experience? Does it make sense to encourage the user NOT to use his or her normal (assumed safer) password, since it won't be protected during their registration and login procedures?

This depends on the website that uses the login form. Most big sites such as Gmail use https for the login authentication and then switch to http. (There have been reports that this switch also introduces some vulnerabilities.) Other sites send a salt value in a hidden form field. Your original password is replaced with the salt and the hash. The same operatio is repeated on the server to ensure that you have sent the correct password. This happens behind the scene so a user cannot really be sure whether is sent unencrypted. It is expected of good sites to do this. Ordinary sites may not do this. Many configuration pages of routers and modems employ no encryption or obfuscation.

Subulate