[web] login/password without HTTPS

Most sites that log in using HTTP will hash the password the user entered using a &#106avascript before sending the details to the server.

If you're using HTTP basic authentication, the login details are not encrypted.

They are encoded in a non-plaintext fashion though. Look at the WWW-Authorization: header sent by the client, this contains some encoded form of the username and password (Base64, IIRC)

This can be trivially decoded anyway. It's not encrypted.

Mark

Gamedev.net uses HTTP POST for authentication (Not HTTP BASIC) and your details get sent in plaintext in a form-encoded post.

However, using Wireshark, I see that in my configuration*, the actual login details get sent in a separate packet to the POST- this may be because it's using HTTP/1.1

The data sent in the POST are something like:

Content-Type: application/x-www-form-urlencodedContent-Length: 81action=login&dom_id=2&u_login=MarkR&u_password=xxxxxxxx&cookies=yes&autologin=yes

* Yours may be different.

To see what's going on more clearly, use Mozilla (Firefox is ok) and install the extension "Live HTTP headers", which shows you the contents of POSTs as well as headers.

Mark

markr:
It is entirely possible that I did not examine the packets closely enough using Wireshark and that my username and password were both transmitted in plaintext.

By the way, just to clarify, HTTP POST is simply a form such as the following, correct?:

Username:
Password:

And since POST is used instead of GET, the form variables aren't displayed in the resulting URL?


This may be asking the obvious, but essentially, the logins for GameDev.net are not secure and anybody who decided to put some effort into snooping a connection could somewhat easily obtain the username and password of a user logging in?


aidan_walsh:
Thinking about it, it doesn't seem like hashing before sending would do much good. If somebody snooped the connection and saw the hashed text that was sent, all they would have to do would be send the hashed text as well. It wouldn't matter what the password was that was converted to the hashed text. Plus, there's the issue that the server would need to receive the actual password at least once to store and compare to future logins.


Thanks.

Your point about the data that is hashed being sent can be intercepted is absolutely true. Anybody could grab and then use that login data to login as somebody else.

However, the point of hashing the plaintext password is so that the user's actual password never gets stolen - as often times, a user will re-use that same password at multiple sites. So, a stolen plain text password could suck. Also, for this same reason, you should not store plain text passwords in your dataase, simply store the same hash as you would send across the wire. This makes password recover impossible, so the user would have to reset the password instead (this is how phpbb boards work).

If you want secure trasmission and not just protecting users from lost password, use SSL/https.

markr:
THANK YOU for showing me Live HTTP Headers! Man, that is so much quicker and easier than Wireshark, and it did the trick for this gamedev.net login question. Sure enough, there was my password in the packet, plain as day.

pjcast:
So, as markr and I have proven above, my password is clearly visible in plaintext to anybody that wants to snoop my connection. In this case, my plaintext password is sent to the server where it is either compared to my plaintext password stored in the database or it is hashed at the server and compared to the hashed password stored at the database. Either way, the fact is that it was sent in plaintext.

The alternative that you mentioned (hashing before sending and comparing it to the hash stored at the server), doesn't make the login to that particular site any more secure. A snooper could simply send the hash to the server and the server would never know that it didn't come from the genuine password. BUT, if somebody is going to steal your login (as we've shown how easy it is to do), it's better to steal a hash that may only work for that one site, rather than the plaintext password that may work for many sites the user visits.

So the gist is that without HTTPS, this is the risk you take and what you have to live with. Am I on track?

Thanks.

Yup, as far as I know there is no completely safe way to send a password without using a secure system (https/SSL, SSH, etc etc). The best you can hope for is just protecting your users information.

If your site will cotain sensitive information that would be compromised from an outsider stealing a login (i.e. getting banking information, ssn, etc, or affecting your project source code or whatever), then you need to use HTTPS. If it is a normal site like a small forum, there is usually very little private/sensitive data in the profile page to really worry about using HTTPS (which can add quite a bit to the server load).

another way to allow a non-secure channel to send secure information (as long as neither endpoint itself is compromised (like a virus)) - would be for the server to send (and of course have to track) a salt to the client, which the client would then use to further modify the hash ... and this salt to change each login. Of course first the server would need to have stored the non-salt affected hashed password, so the initial account creation and password reset feature would need to be further secured ... but still, you can in fact send hashed passwords safely over a non-protected channel, as long as they have been somehow modified for that particular request (and therefore cannot be reused).

The reason that sites such as this can get away with unencrypted packets is that it would take a lot of work to tap into the internet backbone. What would be the payoff? Being able to impersonate someone on this, or another site? A hacker that goes to that much trouble is more likely going to look for bank account numbers, credit card numbers or the like.

There are of course, server load and speed implications of using HTTPS. A SSL connection takes several more round trips to establish, then there is ongoing load on the server to encrypt / decrypt the request / response.

The load on the client isn't that important as it has more work to do rendering the page etc, anyway.

To be properly secure against session hijacking etc, Gamedev would need to run the whole site under SSL, which would probably put too much load on the server, as it's a high traffic site.

Also there would be some problems with the third party advertising scripts it uses extensively (Browsers spout warnings when they see a mixture of HTTP and HTTPS URLs in the same page).

The benefit just wouldn't be high enough.

Conclusion: If you're a Gamedev.net Moderator, don't use an open wifi connection to browse it!

Mark

Quote:

Original post by ID Merlin The reason that sites such as this can get away with unencrypted packets is that it would take a lot of work to tap into the internet backbone. What would be the payoff? Being able to impersonate someone on this, or another site? A hacker that goes to that much trouble is more likely going to look for bank account numbers, credit card numbers or the like.

If you think that intercepting network traffic requires jacking into the "internet backbone" you don't know networking works at all.

All networks are made up of subnets, and traffic is routed using hubs, switchs, routers, repeaters, firewalls, wireless access points, etc. All traffic sent on a hub is received by all clients attached to that hub. All traffic routeded through any machine, switch, or router can be redirected / repeated or modified by that device. All traffic over a wireless or wifi connection is interceptable by anyone with a device to hear it (which is why ALL decent wifi links use some form of protection like WEP or WPA - because otherwise every neighboor could basically wiretap each other with almost no work). Also there are many ways to configure announce your as as any IP you want, thereby causing traffic destined for 1 computer to be routed to you instead or in addition to.

So to intercept traffic all you have to do is "hack in to" any link anywhere in the chain. Obviously I can't sit at my house and intercept other people's gamedev passwords. But if I am in a college dorm room I can almost always snoop the traffic of my entire subnet (usually a whole floor of students), if I am at work I can often hear the whole subnet (usually the entire office) ... so the average person using the internet is not secure in many of the places they do the most browesing.

Nevermind the simple idea that the administrators of networks that you use cannot and should not ever be trusted (what percentage of identity theft is caused by stray stealing vs. the amount caused by some group that actually gets into positions where they can have greater influence). I would assert that most major network identity theifs are in fact network admins by trade.

That is why people on the other end (gamedev, or my bank) should not assume that every step on the way to my end of the network is secure.

I don't in any way think that a site like gamedev should use SSL for the whole site. What I do assert is that ALL sites should use SSL for the login, or some system that at least does not let snoops get to a raw text password. EVEN if it lets the snoop log into gamedev as me I am fine, but NOT if my password is compromised. There is no way I use a different password for ALL my accounts and snoops know this.

My solution of course is to use a few passwords for all my irrelevant websites, and a few different passwords for all my secure sites (bank, cell phone, etc)

I know networking very well. Some network admins, such as myself, just don't really feel the need to be paranoid about a message board logon.

If someone in my house wanted to steal my logon/password, that would be quite different than some arbitrary hacker in Romania.

My point is that it isn't worth anyone's time and effort to steal a logon/password to a message board when there is nothing in it for them.