Https And W3schools Forums... Cleartext Over Network?

[nachumk]

Hi,I just started to think about enabling https and encrypting cookies and that got me wondering how it all works... So as usual I started poking around other sites and it seems that this site sends passwords in cleartext over the network. Is this correct or am I missing something? I did check with WireShark and that's how it looks.Thanx,nachum

[nachumk]

I see that people have read this. Am I wrong? I really would like to understand the issues at hand, so feel free to put me in my place if that is needed.Thanx,

[Synook]

You are right, any site that doesn't use HTTPS or another form of client-side encoding will send all data in clear to the server, even passwords.

[nachumk]

You are right, any site that doesn't use HTTPS or another form of client-side encoding will send all data in clear to the server, even passwords.

Is there a reason why there's no https and no client-side encoding used on this site?

[boen_robot]

Is there a reason why there's no https and no client-side encoding used on this site?

In a word - money. Having a certificate is not free. And when you offer a free service such as this forum, you can't really afford to pay.

[nachumk]

In a word - money. Having a certificate is not free. And when you offer a free service such as this forum, you can't really afford to pay.

Of course. What about a self-signed certificate? This would at least keep the authentication encrypted and not open to simple WIFI sniffing?

[boen_robot]

Of course. What about a self-signed certificate? This would at least keep the authentication encrypted and not open to simple WIFI sniffing?

WiFi sniffing only works once you're inside the network. If the network itself is encrypted (as it should be anyway... you don't want people leeching from your speed and/or bandwidth), such kind of a scan won't work before the WiFi key is broken.As for self signed cerfificate, it would cause the user to click over a red screen of death, which would (rightfully so) lead to extreme distrust over W3Schools. Besides, with an untrusted certificate at hand, you don't get protected against a man in the middle attack: If a hacker really wanted to get users' passwords as they type them (with or without cracking a WiFi password), they'll need to instead target an ISP's gateway. Once they gain control over it, they can redirect the request and/or response to a proxy they control. When they do that, the error message the user receives is the same one of a self signed certificate. If users have learned to trust an untrusty cerficiate, they'll give out their data to the hacker at that point.

[nachumk]

WiFi sniffing only works once you're inside the network. If the network itself is encrypted (as it should be anyway... you don't want people leeching from your speed and/or bandwidth), such kind of a scan won't work before the WiFi key is broken.As for self signed cerfificate, it would cause the user to click over a red screen of death, which would (rightfully so) lead to extreme distrust over W3Schools. Besides, with an untrusted certificate at hand, you don't get protected against a man in the middle attack: If a hacker really wanted to get users' passwords as they type them (with or without cracking a WiFi password), they'll need to instead target an ISP's gateway. Once they gain control over it, they can redirect the request and/or response to a proxy they control. When they do that, the error message the user receives is the same one of a self signed certificate. If users have learned to trust an untrusty cerficiate, they'll give out their data to the hacker at that point.

At this point I see that the reasons are all known to me and any choice has its merits and its problems. I just wanted to check that I knew what was going on here and it seems that I do. Although I still think that having a certificate which could be accepted once is safer than sending cleartext, and barring that a js encryption would also help, but again every choice other than a signed certificate has the possibility of being hacked.Thanx

[Synook]

Having a non-authoritatively-signed certificate is bad practice.Sure, it may be technically "safer", but it's a bit like having a certificate of practice - "oh, I'm safe!" but really no-one has checked.The problem with JS encryption is that anyone can see how it's encrypted.

[nachumk]

Having a non-authoritatively-signed certificate is bad practice.Sure, it may be technically "safer", but it's a bit like having a certificate of practice - "oh, I'm safe!" but really no-one has checked.The problem with JS encryption is that anyone can see how it's encrypted.

I agree with all of that, but I still think some obfuscation is better than cleartext. Having a certificate would require a would-be sniffer to do some advanced stuff to get your password, and even javascript is better than nothing. Perhaps using a hashed password calculated in js is better. That way only the hashed password is transmitted and a person's real password is never sent along the network. Someone can sniff the hashed password, but who cares, it's only a forum. At least this way real password's aren't put at great risk. It's definitely no worse than cleartext.(Of course the actual javascript could be hacked on the way and my computer could be convinced to send the real password w/o hashing, but let's not go crazy...)

[boen_robot]

Right, right... like protecting site source code with right click lock. "I know my HTML is easily accessible, but I want to prevent newbies from copy&paste-ing it non the less"... if someone is experienced enough to open up your page's source code, and select the right portion to copy&paste, they're also extremely likely to be able to use the "View" menu instead of using a right click.In the same fashion, if someone is experienced enough to perform network sniffing, they're extremely likely to be able to break a JS encryption, and they're (less, but still) likely to be able to break a self signed certificate.

[nachumk]

Right, right... like protecting site source code with right click lock. "I know my HTML is easily accessible, but I want to prevent newbies from copy&paste-ing it non the less"... if someone is experienced enough to open up your page's source code, and select the right portion to copy&paste, they're also extremely likely to be able to use the "View" menu instead of using a right click.In the same fashion, if someone is experienced enough to perform network sniffing, they're extremely likely to be able to break a JS encryption, and they're (less, but still) likely to be able to break a self signed certificate.

I didn't explain well enough. NEVER send the password. NEVER store the password. Use the password the first time to create a one-way hash value such as MD5 (I think). Save this value and send this value as the password. This would be the only value that the server would see to authenticate the user. The only risk would be if a person deletes his cookies or logs out and back in again then it's possible for someone to inject modified JS code to cause the password to be submitted without being hashed first. But to me this seems like an awful lot of work to do on the offchance that someone doesn't have the cookie, and it would only be an issue if someone is logging in with a password at an insecure location.Again after the first login there would never be a risk to the person's real password, and if a person stays logged with a cookie then it would impossible for anyone to gain access to his password.

[boen_robot]

I didn't explain well enough. NEVER send the password. NEVER store the password. Use the password the first time to create a one-way hash value such as MD5 (I think). Save this value and send this value as the password. This would be the only value that the server would see to authenticate the user. The only risk would be if a person deletes his cookies or logs out and back in again then it's possible for someone to inject modified JS code to cause the password to be submitted without being hashed first. But to me this seems like an awful lot of work to do on the offchance that someone doesn't have the cookie, and it would only be an issue if someone is logging in with a password at an insecure location.Again after the first login there would never be a risk to the person's real password, and if a person stays logged with a cookie then it would impossible for anyone to gain access to his password.

This already happens... but if you log out or the cookie expires, you need to regenerate the session cookie, which can only happen if you retype your credentials (username AND password). It is at THAT point that certificates really help.

[AElliott]

If you're authenticating via sending the hash, then you can just send the same hash... It doesn't do anything to prevent them sending the same request and that being a valid login. This also still has the problem that when the hash method is publicly available it is feasible to brute force (or if it's something like a basic md5 they could use a rainbow table) the original password (or another string that produces the same cryptographic hash), password security is not that trivial.EDIT: And as mentioned above this is done in cookies for more obvious reasons than for the initial authentication. But if someone gets the cookie, they can often hijack your existing logged in session, without needing the password - but not any later sessions (though I'm not sure of what measures IP.Board has to try to prevent this, matching IP address is unfortunately not useful since some ISPs dynamically switch your IP address fairly often).

[nachumk]

[if you're authenticating via sending the hash, then you can just send the same hash... It doesn't do anything to prevent them sending the same request and that being a valid login.]At least your password isn't at risk.[This also still has the problem that when the hash method is publicly available it is feasible to brute force (or if it's something like a basic md5 they could use a rainbow table) the original password (or another string that produces the same cryptographic hash), password security is not that trivial.]Add a per-user salt stored on the server and sent along for JS hash calculation.[And as mentioned above this is done in cookies for more obvious reasons than for the initial authentication. But if someone gets the cookie, they can often hijack your existing logged in session, without needing the password - but not any later sessions (though I'm not sure of what measures IP.Board has to try to prevent this, matching IP address is unfortunately not useful since some ISPs dynamically switch your IP address fairly often).]How would someone get the cookie?? I don't care about the session or about the password-hash value. I am not submitting this scheme to secure the website but rather to secure a user's password as best as possible without requiring SSL.I am not trying to prevent an unauthorized user from using someone's account, I am trying to prevent someone's important password from being sent out in cleartext. Clearly these forums don't require security that would stop someone else from logging in using another person's account (otherwise the forums wouldn't be sending out cleartext passwords!)What is the disadvantage to at least switching over to a hash? A well implemented salt value per user would solve the problem of recovering the original password. The only way to get the original password would be during an actual login without the hash value from the cookie in an insecure location. This would allow a JS modification to potentially cause the sending out of the original password, but other then that this is a much stronger scheme. If I took my laptop to a cafe after having the password-hash cookie then there would be no risk to my password and the only risk would be someone else being able to log into my account which is MUCH BETTER than losing my actual password which is the current situation.

[Synook]

Everything makes it slightly more secure. The issue here is that all we are discussing are best-effort techniques that, in lieu of proper encryption, make unauthorized access slightly harder. Of course, they can all be circumvented, and of course they provide no real protection, but then, in the real world, you would hopefully have the means to actually just buy a certificate and be done with it.

[AElliott]

At least your password isn't at risk.

If you're using a password that needs to be secure (like online banking passwords) for public forums, then you've already lost any pretence that that password is safe.

Add a per-user salt stored on the server and sent along for JS hash calculation.

This would be a valid point were it not the case that we're discussing someone network snooping. They will have access to the salt, and the method by which the salt is extracted and added to the hash input.

How would someone get the cookie?? I don't care about the session or about the password-hash value. I am not submitting this scheme to secure the website but rather to secure a user's password as best as possible without requiring SSL.I am not trying to prevent an unauthorized user from using someone's account, I am trying to prevent someone's important password from being sent out in cleartext. Clearly these forums don't require security that would stop someone else from logging in using another person's account (otherwise the forums wouldn't be sending out cleartext passwords!)

But the client side hash is still vulnerable to exposing the password, and you haven't suggested a way that actually prevents them from getting the password via brute force and a little trial and error.

What is the disadvantage to at least switching over to a hash? A well implemented salt value per user would solve the problem of recovering the original password. The only way to get the original password would be during an actual login without the hash value from the cookie in an insecure location. This would allow a JS modification to potentially cause the sending out of the original password, but other then that this is a much stronger scheme. If I took my laptop to a cafe after having the password-hash cookie then there would be no risk to my password and the only risk would be someone else being able to log into my account which is MUCH BETTER than losing my actual password which is the current situation.

There's no particular disadvantage I suppose, but I don't see a hugely tangible advantage. It does make it slightly more annoying for a user who's network snooping to gain access to your password, but not by a particularly significant degree.It could be done, but you'd have to take that up with the IP.Board guys who produce the software this forum runs on, anyhoo, if you're concerned about your password in internet cafes, then I suggest this: - make sure that if you have a general use password, it is not associated with any of your bank accounts etc, and ideally don't access that via a public network. - if you do need access to this kind of thing, then get yourself a VPN or similar, you can then have a known correct public key and make sure you don't allow any attempts to replace the VPN's certificate. That would secure all your traffic from anyone snooping on the public network (of course you need to have a reputable VPN, and one it leaves that virtual network it's fair game again, but it reduces the risk by a fairly large margin if you're travelling a lot)

[justsomeguy]

There might be a few tricks you could try, but you really should just use SSL and not worry about trying to mess around with Javascript for security. invisionzone.com could have a wildcard SSL certificate for their domain which would apply to all subdomains, but I'm not sure why they don't do that. They might have too many subdomains, I think a wildcard certificate has a limit of several thousand subdomains and they might exceed that. A wildcard is only about $500 for a server though. For regular SSL, a certificate for just a single domain, that domain needs to be on its own IP, so that's another restriction. If you have a server that hosts 5 domains on the same IP and you install SSL for one of the domains, any HTTPS request to any domain on that server will only load the one protected domain, regardless of what you typed in. So, each protected domain needs its own IP, a request coming in on SSL on a certain IP will be routed to a certain site regardless of what the host is.So there are several considerations for SSL, but at the end of the day if you want security you need SSL, trying to hack together a Javascript security model isn't much of a replacement.