PHP Encrypt Security

[r4v37t]

I want makes my web is secure with encryption at a private information likes username and password.

Like we know when PHP post that information to server it's not in encrypt, but I want makes it encrypt.

How PHP can do that?? (like the javascript do in wifi web based security at login)

Thanks.

[Sparda]

I want makes my web is secure with encryption at a private information likes username and password.

Like we know when PHP post that information to server it's not in encrypt, but I want makes it encrypt.

How PHP can do that?? (like the javascript do in wifi web based security at login)

Thanks.

Use of JavaScript to encrypt transited data is not secure. It will only prevent some one who is seeing the client transmitting data to the server. If the attacker sees both communication from the server and from the client (which is the majority of the time this type of attack is done) nothing you can do will work.

Additionally JavaScript based encryption can not prevent session hijacking.

Use SSL.

[stingwray]

You can make traffic sent of a network secure without using a secure protocol. HTTP has a secure variant, its called HTTPS and it uses SSL to protect the information. You should use this.

There are plenty of other things to do with security of web applications which you need to do, but encrypting transported data is not one of them.

Also, stick to what is tried and tested. Average joe creating their own security specification ends up in epic fail with them being broken trivially. Security systems are put together by groups of extremely intelligent people and are tested and verified to destruction. Not to say that problems won't be found, but most of them are found in the testing phase.

[Jonnycake]

Use of JavaScript to encrypt transited data is not secure.

Untrue, if you have a hashing algorithm (like md5 or sha1) implemented in JavaScript to encrypt the password and just compare that to the hash of the real password, then it's secure.

Algorithms:

http://www.faqs.org/rfcs/rfc3174.html - Sha1 algorithm RFC

http://www.faqs.org/rfcs/rfc1321.html - Md5 algorithm RFC

Implementations:

http://www.webtoolkit.info/javascript-sha1.html - Sha1 JavaScript implementation

http://www.webtoolkit.info/javascript-md5.html - Md5 JavaScript implementation

Edit:

However, when using JavaScript, you have to worry about if the browser has JavaScript enabled (which most do). If they don't have JavaScript enabled, there should be another variable which tells the script on the other end that the JavaScript isn't enabled and it has to hash it before it compares it to the right password. You could accomplish this by using a noscript tag.

[Sparda]

Untrue, if you have a hashing algorithm (like md5 or sha1) implemented in JavaScript to encrypt the password and just compare that to the hash of the real password, then it's secure.

No it isn't. You can capture the md5 and send it again.

[Jonnycake]

Oh, wow, didn't think about that.

[aeturnus]

No it isn't. You can capture the md5 and send it again.

Well, the OP could create a shared-secret using a PSK and Javascript to create the level of security I think he's looking for.

[stingwray]

Oh, wow, didn't think about that.

This is exactly my point about leaving it up to the professionals.

Well, the OP could create a shared-secret using a PSK and Javascript to create the level of security I think he's looking for.

PSK fails to work with multiple users and the requirement that good passwords means passwords are regularly changed.

SSL offers so many other benefits, such as not allowing people to see anything what you are talking to the server about. Encrypting data for transmission across an unsecured tunnel is going to provide attacks with a wealth of information, such as what they are doing, where they are going etc. still.

[Jonnycake]

[edit]

Sounded a little bit arrogant there

[/edit]

Also, SSL can be broken (as can anything else), so it's really not much more useful than the JavaScript with an MITM attack. Granted, it takes a long time to crack SSL, but it can be done. The JavaScript does what it's supposed to - keep the "sensitive" information from being read (in this case the password). He wants to make the post data encrypted, not the whole session. The server also needs to support SSL which, unless he has a good host, it probably doesn't.

On top of that, if you can do a MITM, then you can read the SSL handshake and, again, SSL would be useless. Or, you could send your own certificate and receive the data encrypted using the same certificate and get the plaintext that way. Assuming the attacker actually cares about getting the information, SSL isn't going to protect you during an MITM attack.

[Sparda]

SSL is all about stopping MITM attacks. At the point the user is presented with a "cannot verify certificate authority" error it becomes a case of user unawareness. JavaScript can not offer the security SSL does.

[aeturnus]

SSL is all about stopping MITM attacks. At the point the user is presented with a "cannot verify certificate authority" error it becomes a case of user unawareness. JavaScript can not offer the security SSL does.

That's of course assuming that the attacker didn't create a rogue CA, or recover the private key of a trusted CA. I agree with you and stringwray that a Javascript solution does not provide the same level of security as a full, properly configured, SSL session. But, at the same time, the OP doesn't seem to be too concerned with security and it would fit his requirements.

PSK fails to work with multiple users and the requirement that good passwords means passwords are regularly changed.

It doesn't fail, it just becomes more difficult since the admin has to do more than just set a domain policy and wait for angry users to call. But of course, you could implement the policy features yourself, server-side, that checks for the requirements you're looking for.

[r4v37t]

For now I don't care about the session but I want the post data (password or username or sensitive data) can be sent to server in already encrypted.

Why I want use the PHP or another server side scripting because the method of my encryption is can't be hard to study than when I use the JavaScript, however the javascript code can be encrypted too but it still can be learn by another people.

In this case I use CainAbel as the example for MITM, in this case sensitive data (password and username) can be catch easily because that I want the sensitive data is in already encrypted but it is possible to PHP to do?? If it is possible then how PHP can do that??

Thanks

[Sparda]

For now I don't care about the session but I want the post data (password or username or sensitive data) can be sent to server in already encrypted.

Why I want use the PHP or another server side scripting because the method of my encryption is can't be hard to study than when I use the JavaScript, however the javascript code can be encrypted too but it still can be learn by another people.

In this case I use CainAbel as the example for MITM, in this case sensitive data (password and username) can be catch easily because that I want the sensitive data is in already encrypted but it is possible to PHP to do?? If it is possible then how PHP can do that??

Thanks

Problem one: Repeat attack. If user names and passwords are transmitted encrypted using JavaScript unless the encryption was based on challenge response the attacker doesn't need to know what the username or password is, they can just send the encrypted version.

Problem two: Even if a challenge response is set-up it would be super easy for any one to decrypt because you have to send the challenge to the client in plain text.

Use SSL, it fixes both of these problems.

[stingwray]

That's of course assuming that the attacker didn't create a rogue CA, or recover the private key of a trusted CA. I agree with you and stringwray that a Javascript solution does not provide the same level of security as a full, properly configured, SSL session. But, at the same time, the OP doesn't seem to be too concerned with security and it would fit his requirements.

People really shouldn't chuck that around, because unless the rogue Cert was created before Jacob gave his talk its not going to happen now, it was be a statistical fluke bigger than the winning the lottery.

Also, to simply avoid this problem, make sure any SSL cert that you use is SHA-1 hashed, done.

If the OP doesn't seem to concerned about security, the might I recommend no security, its just as effect as not really concerned about security and a damn lot easier and less trouble!

[aeturnus]

People really shouldn't chuck that around, because unless the rogue Cert was created before Jacob gave his talk its not going to happen now, it was be a statistical fluke bigger than the winning the lottery.

Well, you're assuming that the only way to create a rogue CA is to use a bunch of PS3's playing with MD5 and hoping you get the right information from the CA.

And that's simply not the case.

That is sort of off-topic, though.

If the OP really wants to do this all in PHP and Javascript, I don't think we should tell him it's not possible. He could perform a DHE exchange that way and incorporate RSA certs, effectively doing the SSL without using the SSL libraries. Or use a salted PSK, or many other ways. I think we've all clearly suggested that using SSL is the superior plan of attack, but if he really doesn't want to do it, shouldn't we be suggesting options that fit his requirements?

[stingwray]

Well, you're assuming that the only way to create a rogue CA is to use a bunch of PS3's playing with MD5 and hoping you get the right information from the CA.

And that's simply not the case.

That is sort of off-topic, though.

So if its not the case then, would you like to show us the research?

Because when they announced this research it was pretty big stuff, so much so that we weren't even told what the talk was about until about an hour before, all we knew before was it was about attacking a piece of critical internet infrastructure and that Jacob said that it would be at the end of his presentation on the Cold-Boot attack.

[Sparda]

If the OP really wants to do this all in PHP and Javascript, I don't think we should tell him it's not possible. He could perform a DHE exchange that way and incorporate RSA certs, effectively doing the SSL without using the SSL libraries. Or use a salted PSK, or many other ways. I think we've all clearly suggested that using SSL is the superior plan of attack, but if he really doesn't want to do it, shouldn't we be suggesting options that fit his requirements?

It isn't possible without setting up an entirely new version of SSL that incorporates approved CA's. SSL works by having CA's say that the websites public key is verified as been the public key that belongs to that web site. Without the verification the public key can be replaced by any one doing a MITM attack.

[aeturnus]

So if its not the case then, would you like to show us the research?

Because when they announced this research it was pretty big stuff, so much so that we weren't even told what the talk was about until about an hour before, all we knew before was it was about attacking a piece of critical internet infrastructure and that Jacob said that it would be at the end of his presentation on the Cold-Boot attack.

The attack you're talking about was one way, and it relied on a lot of tech. I'm suggesting that there are possible other ways to fake a trusted CA, maybe not involving lots of tech. Perhaps breaking into the building where the information is stored. Or perhaps there's a publicly unknown break in SHA-1 that people are currently using to keep themselves afloat in a struggling economy.

Although unlikely, those avenues are still possible methods of pursuit-- and before the MD5 break a few years ago, I'd probably say they were all equally likely.

So you're saying there's no possible way to MITM an SSL stream? Yeah, that sounds reasonable, sure. [/sarcasm]

It isn't possible without setting up an entirely new version of SSL that incorporates approved CA's. ... and useless information...

Sure, I'm saying the OP could do the math himself. After all, we're all big boys and girls here and we can all read Applied Cryptography, the Handbook of Applied Cryptography, or hey, maybe even the OpenSSL source code.

[Sparda]

So you're saying there's no possible way to MITM an SSL stream? Yeah, that sounds reasonable, sure. [/sarcasm]

I never said that, but you are correct. The difference been the 'home made' encryption and SSL is if SSL is used you can tell when you have been MITM'ed becasue your browser won't recognise the CA. If you use the home grown stuff there is no direct method of knowing if the public key the server handed the client has been tampered with.

[digip]

I don't really see what the argument is though...PHP is not encrypting anything other than what it stores on its side as a satled hash or file, whatever. Its not that it can't encrypt files, its that in order to do that, you have to send the plain data to the server first, and if that communication isn't encrypted via SSl or such, its open to any one sniffing the line.

The answer has been given several times now by Sparda. Unless the communication is on a secure channel, like SSL,TLS, etc, then all information is transmitted is in the open and anyone sniffing the communications can capture it and resend it, replay a captured packet later on. Even if the server encrypts the data, you still have to be able to send it to the server before it can encrypt it, and that info will be sent in the clear. If using SSL or a variant there in, all your traffic is sent securlty between you and the server, encrypted from prying eyes. There is also Internet Key Exchange (IKE or IKEv2) communications between two networks but I think that requires a special setup on the web server itself and I'm not sure if that encrypts it more than it is just an authorization service.

[aeturnus]

I don't really see what the argument is though...PHP is not encrypting anything other than what it stores on its side as a satled hash or file, whatever. Its not that it can't encrypt files, its that in order to do that, you have to send the plain data to the server first, and if that communication isn't encrypted via SSl or such, its open to any one sniffing the line.

The answer has been given several times now by Sparda. Unless the communication is on a secure channel, like SSL,TLS, etc, then all information is transmitted is in the open and anyone sniffing the communications can capture it and resend it, replay a captured packet later on. Even if the server encrypts the data, you still have to be able to send it to the server before it can encrypt it, and that info will be sent in the clear. If using SSL or a variant there in, all your traffic is sent securlty between you and the server, encrypted from prying eyes. There is also Internet Key Exchange (IKE or IKEv2) communications between two networks but I think that requires a special setup on the web server itself and I'm not sure if that encrypts it more than it is just an authorization service.

No one's arguing against your ability to sniff cleartext, digip. I believe the suggestion was to use Javascript to encrypt the data before sending it to the server.

Sparda,

The method for the determining if the certificate is valid or not would be the same regardless of whether or not you use the SSL libraries. Your operating system has the trusted CA cache, why can't your home-brew method verify against them?

I don't mean to insult anyone's intelligence, but I think the problem is that there's some confusion between implementing a protocol and that protocol "being encryption". SSL is a set of protocols. You can re-implement those protocols in another language without using pre-made libraries and they will act just the same. You don't suddenly lose the ability to verify RSA certificates by using your systems trusted roots just because you choose to not use mod_ssl.

[Sparda]

Sparda,

The method for the determining if the certificate is valid or not would be the same regardless of whether or not you use the SSL libraries. Your operating system has the trusted CA cache, why can't your home-brew method verify against them?

I don't mean to insult anyone's intelligence, but I think the problem is that there's some confusion between implementing a protocol and that protocol "being encryption". SSL is a set of protocols. You can re-implement those protocols in another language without using pre-made libraries and they will act just the same. You don't suddenly lose the ability to verify RSA certificates by using your systems trusted roots just because you choose to not use mod_ssl.

You can't reimplement SSL without been a valid CA. You can absolutely create a SSL certificate your self, just no ones browser will recognise it as been a valid one without it been signed by a CA that the browser recognises. A self signed SSL certificate connection is as vulnerable to MITM attacks as a plaintext http connection.

[aeturnus]

You can't reimplement SSL without been a valid CA. You can absolutely create a SSL certificate your self, just no ones browser will recognise it as been a valid one without it been signed by a CA that the browser recognises. A self signed SSL certificate connection is as vulnerable to MITM attacks as a plaintext http connection.

Your post is basically unintelligible. But I can try to surmise what you're trying to say, so please correct me if I'm wrong. Without the client being able to cryptographically validate the server's certificate, the connection can be MITM'd by someone presenting an invalid certificate.

Right, that's essentially how that sort of thing works. You can, however, create your own certificates and install it as a trusted root on the client machine through some other secure method. Given the OP's original constraints, this seems reasonable.

[Sparda]

Right, that's essentially how that sort of thing works. You can, however, create your own certificates and install it as a trusted root on the client machine through some other secure method. Given the OP's original constraints, this seems reasonable.

I want makes my web is secure with encryption at a private information likes username and password.

Every user of his site would have to have the certificate transmitted to them securely, this could be done through the post (though this is arguably not secure). This is not reasonable and more expensive than buying a SSL certificate from a CA.

[digip]

If using Javascript to encrypt it before sending, and someone is sniffing the data capturing the encrypted payload plus the javascript itself that encrypted it, wouldn't it be easy to script a decrypt from the payload and original encrypt script?