Open evertton opened 11 years ago
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.
@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.
something like:
$resource = openssl_pkey_new();
$public = openssl_pkey_get_details($resource);
openssl_pkey_export($resource, $private, "Codiad");
$public = $public["key"];
Codiad is also vulnerable to session hijacking.
could be solved by saving the IP in the session and check everytime if the IP is the same as it was.
@Fluidbyte it had not worked practically with these issues.
@newsocialifecom I was thinking of OpenPGP keys.
RFC 6091 - Using OpenPGP Keys for Transport Layer Security (TLS) Authentication
@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
Why don't we use the fact, that the password need't to be restored on the server?
Disadvantages:
Advantage:
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
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();
}
it's not as safe as openssl, never
I haven't said anything about SSL ;) - for me SSL protection is quite enough
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.
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)
thanks for the report, please send such things by email
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.