Security Problems

[evertton]

We must pay attention to some possible security problems.

I have was capturing the requests between the server (demo.codiad.com) and my browser. And I realized that customer data do not suffer any encryption before transactions.

At least most sensitive data should be encrypted on the client. e.g. passwords.

Authetication packet captured: username=demo&password=demo&language=en

Currently, I use a OpenSSL key to protect my data during transactions outside the local network.

[ksafranski]

There isn't (as far as I know) a good way to encrypt between client and server without an SSL, which is why we haven't implemented anything for this. Basically if the installation requires that level of security it should be done with an SSL which is in the hands of the server administrator.

If you have a better solution that can be implemented on the application itself I would love to hear about it.

[newsocialifecom]

@Fluidbyte It CAN be done using RSA. in the installation php generates a public / private key pair and in login, javascript will encrypt the form with the public key and then php can decrypt it with his private key.

[newsocialifecom]

something like:

$resource = openssl_pkey_new();
$public = openssl_pkey_get_details($resource);
openssl_pkey_export($resource, $private, "Codiad");
$public = $public["key"];

[evertton]

Codiad is also vulnerable to session hijacking.

[newsocialifecom]

could be solved by saving the IP in the session and check everytime if the IP is the same as it was.

[evertton]

@Fluidbyte it had not worked practically with these issues.

@newsocialifecom I was thinking of OpenPGP keys.

[evertton]

RFC 6091 - Using OpenPGP Keys for Transport Layer Security (TLS) Authentication

[newsocialifecom]

@evertton yes, would be a good idea but it would not be so simple to implement because php doesn't have a standard OpenPGP api, maybe there's something in the internet

[ccvca]

Why don't we use the fact, that the password need't to be restored on the server?

1. Add a salt to the login form which was generated during the installation.
2. Add a token to the login form which is different each time you call the login and store it in a Session on the Server.
3. Salt and hash the password with JS (There are enought JS-SHA libraries on the web )
4. Add the token to the hash and hash both again.
5. This hash could be send to the server where it could be compared to the stored salted password hash by adding the same token to it.

Disadvantages:

• The current passwords needs to be salted, so the login might break if this is a "normal" update
• sha/ md5 are very fast hash algorithms, which should not use for password, but everything else would be quite complicate in JS
• The salt needs to be public

Advantage:

• much easier than a public key in JS
• safer because also if you catch the sended password it's useless

[newsocialifecom]

I tried one md5 encoder in javascript but didn't work like the php one… the hashes where completly different and of course broke the whole. This one

[daeks]

if you want to go that way, you can hash the password with sha512, like http://pajhome.org.uk/crypt/md5/sha512.html

onclick of login button:

function hash(form, password) {
   password.value = hex_sha512(password.value);
   form.submit();
}

[newsocialifecom]

it's not as safe as openssl, never

[daeks]

I haven't said anything about SSL ;) - for me SSL protection is quite enough

[ccvca]

Hash only is quite useless, because if you capture the hash you can use this hash again, so there is the same problem as before.

If you want to improve the security you need to send 2 salts one of them must be static for a Username fix one and the other must be different every time.

PS: Something like that is as safe as a JS-SSL

PS2: There is also the problem, that if you don't use SSL everyone who catch the etwork traffic could also catch the SessionID which can't encrypt, so there needs to be also an IP check in the session. But I don't know a way to protect Codiad against Man In The Middle without a SSL-Cert from a Trustet site. But that couldn't be done by Codiad itself.

[neissa]

a web IDE must be used with SSL over HTTP, if a password/secret/etc is in a config file and you save it, it will be send without encryption. I think checking the problem of login password without checking the problem of the file content is a mistake.

if you are afraid of security, check this kind of url : **\ (edit daeks)

[daeks]

thanks for the report, please send such things by email