Quote: "I must say that i can't read your message without feeling that as an accusation"
It wasn't an accusation. I'm just highly security concious.
Quote: "i don't know why you are "whoising" and publishing my dedicated server informations"
It's
public information, which anyone can obtain, is it not?
The information can be used to confirm the reliability of your site (to an extent). So it could be useful.
Quote: "i'm not russian and the server is safe"
Are all russians criminals? (What about NSA?)
Quote: "For the password, for every website , you store only the encoded password .. not in clear text. The application compare the database encoded password with your submitted encoded password."
Quote: "the encrypting process will be done at the client side (Javascript) and after, sent to the server"
I'm fully aware of how to compute a password hash; eg. an MD5 checksum (which is commonly used). But very few websites actually do that. (Even the TGC website fails to employ any amount of security during the login process.)
And on the downside, it's trivial to get the plain-text password based on a hash. (There are even online tools for doing that.)
So, if a cracker gained access to your applications hash database, they'd be able to get the passwords just as easily. (But I will assume that it wouldn't be easy to gain access to the password hashes in the first place.)
Quote: "For the informations sent to the server, almost EVERY website are receiving this informations."
True for most users.
When I'm using Tor they don't know my IP or location, and my local HTTP-proxy rewrites outbound HTTP-request headers -- so any identifying information in the headers is replaced with disinformation. Often I'm also blocking the referer, so the destination doesn't even know from which page I came to the site. Third party cookies and web storage are obviously blocked so that they do not bleed information. This isn't a typical web usage scenario for most users, though.
Quote: "And try to access a website without javascript actually ... you won't be able to see any website :p"
Which doesn't really make it any better, does it? Because it only means that I couldn't use that service without enabling JavaScript. (Which I don't want to do.)
Quote: "As TGC Forums do, your encrypted password could be saved in local cookies for a quicker logon."
Well, the TGC website login isn't using a secure connection either,
and they don't compute an MD5 hash for passwords -- they send them "in the clear" as a POST request sent by the login form.
To be specific, the following cookies are set during the initial login phase to the TGC website:
- plS, plT, public_key, public_key2, suid, PHPSESSID
And they do contain hashes, but only after the hashes have been computed on the
server side, following the POST action.
SIDENOTE: TGC website is a prime example for insecure login -- it transmits everything in plain-text without any attempt at encryption.
Quote: "For the moment, the aim of this chat is to get few advices on what could be improved"
I understand that. But the sooner you get this critique the better. Now you can factor it into your development.
Quote: "i will ask you to proxy your connection to see what is sent"
I am in no way out to prove that this chat system is a bad idea.
So I don't want to become a security tester for it. I'm just seeing a few problems with it. And the more I talk with you, the lesser those problems seem to become. I begin to realize that I've been paranoid again.
SUMMARY
I think we've covered that there are SOME issues with the chat service, but nothing horrible for a normal user. If you can prevent identity impersonation between the forums and the chat, I wish you success.
It seems to be hosted by a reliable ISP, and you're working to address some of the issues I mentioned earlier, while also adding a layer of security.
Cheers,
AgentSam
