Stealing my POST data_问答_开发者_运维开发者技术经验分享

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 m开发者_如何学编程y 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.

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:

User submits login via HTTPS with username and password
Server takes password and applies a hashing algorithm to it, generally using MD5, though something strong like SHA256 is recommended
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.

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?

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.

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.

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.