Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

Recently I was thinking about how websites like gmail and amazon use HTTPS during the login process when accessing your account. This makes sense, obviously, since you're typing in your account username and password and you would want that to be secure. However, on Facebook, among countless other websites, their logins are done with simple HTTP. Doesn't that mean that my login name and password are completely unencrypted? Which, even worse, means that all those people who login to their facebooks (or similar sites) at a wifi hotspot in public are susceptible to anyone getting their credentials using a simple packet sniffer (or something similar)? Is it really that easy? Or am I misunderstanding internet security?

I'm a software engineer working on some web related stuff, and although at the current time I'm not too involved with the security aspect of our software, I knew I should probably know the answer to this question, since it's extremely fundamental to website security.

Thanks!

share|improve this question
add comment

3 Answers

up vote 6 down vote accepted

Yes. Anything done over open WiFi using HTTP is completely open to interception, replay, etc.

That said, sites that use HTTPS to negotiate login yet exchange the resulting authentication cookie over HTTP are very open to session hijacking as well, as the developer of firesheep showed.

If you want decent security, do everything under cover of HTTPS. Servers are now fast enough and SSL certificates cheap enough (if you shop around) that this is practical; there's no longer any excuse for web developers so endangering their users.

share|improve this answer
1  
The key here is 'session hijacking'. The attacker doesn't get the actual password, they get the token given to the user after the password is validated. That token can be re-used by an attacker until it expires. Things like IP-binding the token to a specific IP or only allowing the token to be used with the user-agent string the user logged in with can help, but HTTPS is the only way to fully protect the token. –  sysadmin1138 Feb 2 '11 at 15:15
    
What SA1138 said, though since some sites allow an authenticated user to set his password with no re-authentication, sufficiently poor site design can allow the password to be captured and the original user locked out of his account. Personally, I hope this will be the decade when two-factor authentication starts to become normal, and username/password is consigned to yesterday's dustbin. Anyone for OAUTH? –  MadHatter Feb 2 '11 at 15:27
add comment

If you really log in to a site with plain HTTP it's completely insecure, yes and anyone in a public WLAN could sniff your data. This is why i.e. Facebook does the actual login via HTTPS (look into the source code of the Facebook start page and you will see it) and then continue without encryption in order to save on computing power. This at least protects your password, but still allow all kind of other attacks, like Session Hijacking (they sniff your session cookie and use it themselves).

share|improve this answer
    
Ah, that makes a lot more sense (that they do the actual login using HTTPS). I just couldn't imagine that it was truly THAT easy to steal someone's facebook password in public. –  JoeCool1986 Feb 2 '11 at 15:12
add comment

Sites that pass sensitive data (like credentials, or cookies that act as proxy for credentials) in the clear put their users at risk. Any method that can be used to intercept and record traffic (sniffers, monitor-mode wifi NICs, etc) will be suitable for gathering these credentials. Sessions can be hijacked, responses from remote servers can be spoofed, etc. All kinds of nastiness comes from moving data around in the clear.

Just moving user credential data over HTTPS isn't good enough. If you're using cookies that stand-in-place of the user's credential you can't move those over HTTP either, or you risk compromise of the user's session.

As a developer, you're doing your users a disservice if you're not using HTTPS to move their credentials around. That usually means more CPU utilization in some tier of your infrastructure, and opacity to the traffic as it moves toward the edge of your network. This many mean creating a software architecture that allows for delivery of "bulk" content (static images, static scripts, etc) in cleartext, but delivering personalized content (that is, content for which the composition is controlled by receiving credentials from the remote user) via means that allow for secure transmission of credentials.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.