This is a PHP 5 library I've been developing over the past year and a half. It's not an MVC framework, but rather a modular collection of classes to help with common PHP usage patterns and security. More like the Zend Framework than something like Cake, but at the same time simpler and lighter-weight than Zend.
I've spent a good amount of time on documentation and trying to make the code and the site as usable as possible. I'm looking forward to getting some feedback!
At first glance, it looks really useful. And great job on the documentation. I know from experience taking a passion project and turning it into something other people can easily utilize is a lot of work. Thank you for making the effort and taking the time to share it with us!
I love it. Don't get discouraged by the lack of comments here! I'll be giving it a shot next time I need to do a small marketing site. Looks like it'll cut my hours sharply.
Glancing at the documentation I can tell it will easily solve a lot of the reoccurring issues I usually deal with on small projects. I'm definitely going to give it a try.
This looks really useful. It's nice to see libraries that try to do just a few things really well without taking over everything else.
I have a couple minor quibbles about the crypto though (although, IANAC so take this with a grain of salt):
In your symmetric encryption routine, you include an HMAC of the encrypted IV and the ciphertext by computing HMAC_k($encrypted_iv . $ciphertext). This is problematic because an attacker can shift data from the end of the IV to the beginning of ciphertext without being caught immediately. Presumably it will garble the message in a way that will be noticed, but that's not a great assumption to make. At the very least it lets the attacker cause the script to spew warnings by passing an empty IV.
Using Triple-DES to encrypt an IV for AES also strikes me as a little weird. If you include the IV in an HMAC, you don't gain anything by encrypting it (since the entire point of encrypting the IV is to prevent someone from modifying it in transit).
Thanks for taking the time to check it out, it is encouraging to see positive and constructive feedback.
I'll be sure to change the hmac to use a separator for the iv and ciphertext, that's a subtle vulnerability that you articulated well.
I think you are also correct about encrypting the iv being worthless. Thinking back to when I wrote this, I believe that I originally added the encryption for that purpose exactly, to prevent modification during transmission. I later added the hmac to prevent modification of the ciphertex, but I ended up adding the iv in there too. Thanks!
8 comments
[ 4.9 ms ] story [ 28.2 ms ] threadI've spent a good amount of time on documentation and trying to make the code and the site as usable as possible. I'm looking forward to getting some feedback!
I like that it's not a full blown MVC framework. Going to give it a try.
Thanks! David
Glancing at the documentation I can tell it will easily solve a lot of the reoccurring issues I usually deal with on small projects. I'm definitely going to give it a try.
Thanks!
I have a couple minor quibbles about the crypto though (although, IANAC so take this with a grain of salt):
In your symmetric encryption routine, you include an HMAC of the encrypted IV and the ciphertext by computing HMAC_k($encrypted_iv . $ciphertext). This is problematic because an attacker can shift data from the end of the IV to the beginning of ciphertext without being caught immediately. Presumably it will garble the message in a way that will be noticed, but that's not a great assumption to make. At the very least it lets the attacker cause the script to spew warnings by passing an empty IV.
Using Triple-DES to encrypt an IV for AES also strikes me as a little weird. If you include the IV in an HMAC, you don't gain anything by encrypting it (since the entire point of encrypting the IV is to prevent someone from modifying it in transit).
I'll be sure to change the hmac to use a separator for the iv and ciphertext, that's a subtle vulnerability that you articulated well.
I think you are also correct about encrypting the iv being worthless. Thinking back to when I wrote this, I believe that I originally added the encryption for that purpose exactly, to prevent modification during transmission. I later added the hmac to prevent modification of the ciphertex, but I ended up adding the iv in there too. Thanks!