Comments on: Creating a Crypter Class with PHP http://net.tutsplus.com/tutorials/php/creating-a-crypter-class/ Web Development & Design Tutorials Mon, 22 Mar 2010 15:27:11 +0000 http://wordpress.org/?v=2.9.2 hourly 1 By: Nox http://net.tutsplus.com/tutorials/php/creating-a-crypter-class/comment-page-1/#comment-154377 Nox Tue, 29 Dec 2009 11:40:59 +0000 http://net.tutsplus.com/?p=6941#comment-154377 Globals...oh my... Globals…oh my…

]]> By: Bo Hunter http://net.tutsplus.com/tutorials/php/creating-a-crypter-class/comment-page-1/#comment-140672 Bo Hunter Wed, 02 Dec 2009 18:53:21 +0000 http://net.tutsplus.com/?p=6941#comment-140672 Man, you people beat all I've ever seen. It's like all you want to do is attack someone for writing a simple encryption article that is just that, a simple encryption class that yo can use to encrypt or decrypt data. But no he needs to explain ever little detail including what interfaces are and how there are used when to use them and when not. I would assume that people reading this would have some php knowledge of some degree. If people need that kind of detail then there are plenty of books dedicated to the subject. I encourage you or anyone else to write your own article and show use how it's done. Man, you people beat all I’ve ever seen. It’s like all you want to do is attack someone for writing a simple encryption article that is just that, a simple encryption class that yo can use to encrypt or decrypt data. But no he needs to explain ever little detail including what interfaces are and how there are used when to use them and when not. I would assume that people reading this would have some php knowledge of some degree. If people need that kind of detail then there are plenty of books dedicated to the subject. I encourage you or anyone else to write your own article and show use how it’s done.

]]> By: Vilson http://net.tutsplus.com/tutorials/php/creating-a-crypter-class/comment-page-1/#comment-116831 Vilson Fri, 09 Oct 2009 13:45:56 +0000 http://net.tutsplus.com/?p=6941#comment-116831 How to encrypt the php code? How to encrypt the php code?

]]> By: InsiteFX http://net.tutsplus.com/tutorials/php/creating-a-crypter-class/comment-page-1/#comment-116415 InsiteFX Thu, 08 Oct 2009 04:53:19 +0000 http://net.tutsplus.com/?p=6941#comment-116415 Patrick, There is another article on here that metions about multiple re-hashing that exally weakens the encryption. Christian, very nice article, do not let others put you down, keep up the good work and stick to it. The whole point of these tutorial are to teach new comers how to do things! Enjoy InsiteFX Patrick,

There is another article on here that metions about multiple re-hashing that exally weakens the encryption.

Christian, very nice article, do not let others put you down, keep up the good work and stick to it. The whole point of these tutorial are to teach new comers how to do things!

Enjoy
InsiteFX

]]> By: Christian Beikov http://net.tutsplus.com/tutorials/php/creating-a-crypter-class/comment-page-1/#comment-115512 Christian Beikov Mon, 05 Oct 2009 19:57:17 +0000 http://net.tutsplus.com/?p=6941#comment-115512 Hello! So first of all, if you read the tutorial you would know that I recommend AES-256 and in this class i just showed an example! Next is the MCRYPT_RAND. Maybe here are some windows users too and they wonder why that script is not working on their servers if I would use such UNIX functions. I wanted to make that class work everywhere so that's the point. And last, you are porbably right what you wrote about the ECB. Didn't thought about that but thanks for you advice, I will change that. So finally you didn't discouraged me, criticism is always okay and if I think something is not okay then I will tell you of course! I hope you enjoyed the general stuff about encryption and so on even if you disliked some things in that tutorial! Hello!

So first of all, if you read the tutorial you would know that I recommend AES-256 and in this class i just showed an example!

Next is the MCRYPT_RAND. Maybe here are some windows users too and they wonder why that script is not working on their servers if I would use such UNIX functions. I wanted to make that class work everywhere so that’s the point.

And last, you are porbably right what you wrote about the ECB. Didn’t thought about that but thanks for you advice, I will change that.

So finally you didn’t discouraged me, criticism is always okay and if I think something is not okay then I will tell you of course! I hope you enjoyed the general stuff about encryption and so on even if you disliked some things in that tutorial!

]]> By: Dustin http://net.tutsplus.com/tutorials/php/creating-a-crypter-class/comment-page-1/#comment-114306 Dustin Fri, 02 Oct 2009 07:17:26 +0000 http://net.tutsplus.com/?p=6941#comment-114306 If you ask me this was a very nice, simple tutorial which goes over symmetric-key based encryption, very useful for a person just getting familiar with Cryptography. The security of this encryption lies within the key, therefore putting the burden of it's security where the script resides. A very practical application to make this even stronger would be to pull it's functionality from another secure location, just in case the application which uses it fails to protect the source. MD5 is not recommended for one way hashing passwords on a live deployment anymore, even with a salt. However it is still very useful for (as Patrick said) preventing file manipulation by matching, and within a learning environment. SHA-1 hashing is by far, better than MD5, but not flawless. If you ask me this was a very nice, simple tutorial which goes over symmetric-key based encryption, very useful for a person just getting familiar with Cryptography.

The security of this encryption lies within the key, therefore putting the burden of it’s security where the script resides. A very practical application to make this even stronger would be to pull it’s functionality from another secure location, just in case the application which uses it fails to protect the source.

MD5 is not recommended for one way hashing passwords on a live deployment anymore, even with a salt. However it is still very useful for (as Patrick said) preventing file manipulation by matching, and within a learning environment.

SHA-1 hashing is by far, better than MD5, but not flawless.

]]> By: pix http://net.tutsplus.com/tutorials/php/creating-a-crypter-class/comment-page-1/#comment-114084 pix Thu, 01 Oct 2009 20:15:50 +0000 http://net.tutsplus.com/?p=6941#comment-114084 Hmm thanks for tut Hmm thanks for tut

]]> By: Unknown_sucker http://net.tutsplus.com/tutorials/php/creating-a-crypter-class/comment-page-1/#comment-112938 Unknown_sucker Tue, 29 Sep 2009 12:09:09 +0000 http://net.tutsplus.com/?p=6941#comment-112938 I'm all for making cryptography easier to use by programmers, it's a complicated area with many pits to fall into, however this class falls into almost everyone of them. As already mentioned the cipher mode ECB is just plain wrong and the key should be salted and hashed. Use something like sha256 when you're using a 256-bit algorithm. Another big problem is using the system random number generator, MCRYPT_RAND, when generating the IV. It doesn't provide much in terms of entropy (which is very important when generating the IV) sadly it's the only option on windows, but if you're on Unix you should use MCRYPT_DEV_RANDOM or MCRYPT_DEV_URANDOM for generating the IV. (Probably MCRYPT_DEV_URANDOM since it's non-blocking.) If you're stuck on windows you need to call srand(), according to the php documentation, before generating any IV. Lastly I don't see the point of defaulting to MCRYPT_BLOWFISH for the cipher. AES-256 is the standard and most tested one and the one that should be used in most cases. If you need to use another one, then you change it! Having the user change to MCRYPT_RIJNDAEL_256 manually every time isn't very good API design IMHO, but I digress. Hopefully I haven't discouraged the author too much, but these are some serious security issues which sadly lingers around in various corners of the internet and they need to be addressed. I’m all for making cryptography easier to use by programmers, it’s a complicated area with many pits to fall into, however this class falls into almost everyone of them.

As already mentioned the cipher mode ECB is just plain wrong and the key should be salted and hashed. Use something like sha256 when you’re using a 256-bit algorithm.

Another big problem is using the system random number generator, MCRYPT_RAND, when generating the IV. It doesn’t provide much in terms of entropy (which is very important when generating the IV) sadly it’s the only option on windows, but if you’re on Unix you should use MCRYPT_DEV_RANDOM or MCRYPT_DEV_URANDOM for generating the IV. (Probably MCRYPT_DEV_URANDOM since it’s non-blocking.) If you’re stuck on windows you need to call srand(), according to the php documentation, before generating any IV.

Lastly I don’t see the point of defaulting to MCRYPT_BLOWFISH for the cipher. AES-256 is the standard and most tested one and the one that should be used in most cases. If you need to use another one, then you change it! Having the user change to MCRYPT_RIJNDAEL_256 manually every time isn’t very good API design IMHO, but I digress.

Hopefully I haven’t discouraged the author too much, but these are some serious security issues which sadly lingers around in various corners of the internet and they need to be addressed.

]]> By: Christian Beikov http://net.tutsplus.com/tutorials/php/creating-a-crypter-class/comment-page-1/#comment-112852 Christian Beikov Tue, 29 Sep 2009 07:48:17 +0000 http://net.tutsplus.com/?p=6941#comment-112852 This is just an example of how you can make that. I think I explained everything really clearly so you can easily change something. You don't have to use this class 1:1 in your project. Concerning the base64 encode/decode, I don't know who will use the class and in which way but maybe someone who doesn't know much about that topic will use the data in an url for example and then it might not work. So if you are able to read and understand that you can easily change the source! You will see a nice example soon, just wait for the nettuts editor to post the new tutorial. This is just an example of how you can make that. I think I explained everything really clearly so you can easily change something. You don’t have to use this class 1:1 in your project. Concerning the base64 encode/decode, I don’t know who will use the class and in which way but maybe someone who doesn’t know much about that topic will use the data in an url for example and then it might not work. So if you are able to read and understand that you can easily change the source!
You will see a nice example soon, just wait for the nettuts editor to post the new tutorial.

]]> By: Bjørn Langfors http://net.tutsplus.com/tutorials/php/creating-a-crypter-class/comment-page-1/#comment-112683 Bjørn Langfors Mon, 28 Sep 2009 21:56:40 +0000 http://net.tutsplus.com/?p=6941#comment-112683 @Patrick There's no need to hide the salt. If you, for example, generate a random 128 bit salt whenever you need to store a password, you can safely store that salt as-is alongside the hashed password to make all precomputation attacks (eg. rainbow tables) utterly infeasible. Another method, which is mentioned in the wikipedia article below, is key strengthening, which simply is re-hashing the hash a number of times before you store it. The user won't notice the extra few milliseconds it takes to re-hash the submitted password a thousand times, but if you're precomputing millions of hashes those extra milliseconds add up fast. http://en.wikipedia.org/wiki/Rainbow_tables#Defense_against_rainbow_tables There is a relation between salts and IVs (initialization vectors) which I miss more information about in the article. In addition, the author fails to mention the merits of the different encryption modes and most importantly why you shouldn't use ECB for anything serious. Put simply, using a block-cipher in ECB (electronic codebook) mode is like hashing without a salt. In ECB-mode Each block of plaintext is encrypted separately, which might reveal a lot of pattern information. (There is a very visual example of this in the wikipedia article cited below). The same plaintext will always produce the same ciphertext, which is something you want to avoid. A better approach is to use CBC (Cipher-block chaining) mode with a randomly generated IV. As the name implies, in CBC mode each block of plaintext is XORed with the previous block of ciphertext which makes any block dependant of the blocks processed up to that point. This avoids revealing pattern information, and with a randomly generated IV you won't get the same ciphertext given two identical plaintexts. The IV should be stored alongside the encrypted data (just like salt if you were storing hashed passwords). The key itself could (and should) be strengthed via several hashing iterations. http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation#Electronic_codebook_.28ECB.29 @Patrick

There’s no need to hide the salt. If you, for example, generate a random 128 bit salt whenever you need to store a password, you can safely store that salt as-is alongside the hashed password to make all precomputation attacks (eg. rainbow tables) utterly infeasible.

Another method, which is mentioned in the wikipedia article below, is key strengthening, which simply is re-hashing the hash a number of times before you store it. The user won’t notice the extra few milliseconds it takes to re-hash the submitted password a thousand times, but if you’re precomputing millions of hashes those extra milliseconds add up fast.

http://en.wikipedia.org/wiki/Rainbow_tables#Defense_against_rainbow_tables

There is a relation between salts and IVs (initialization vectors) which I miss more information about in the article. In addition, the author fails to mention the merits of the different encryption modes and most importantly why you shouldn’t use ECB for anything serious.

Put simply, using a block-cipher in ECB (electronic codebook) mode is like hashing without a salt.

In ECB-mode Each block of plaintext is encrypted separately, which might reveal a lot of pattern information. (There is a very visual example of this in the wikipedia article cited below). The same plaintext will always produce the same ciphertext, which is something you want to avoid.

A better approach is to use CBC (Cipher-block chaining) mode with a randomly generated IV. As the name implies, in CBC mode each block of plaintext is XORed with the previous block of ciphertext which makes any block dependant of the blocks processed up to that point. This avoids revealing pattern information, and with a randomly generated IV you won’t get the same ciphertext given two identical plaintexts. The IV should be stored alongside the encrypted data (just like salt if you were storing hashed passwords). The key itself could (and should) be strengthed via several hashing iterations.

http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation#Electronic_codebook_.28ECB.29

]]>