RE: [PHP] [announce] OPiuM -- stock Options Portfolio Manager

> > I have to say I'm very displeased with the whole way I *had* to > build the > > database. It seems to me that security in databases should be > paramount, and > > the ENCODE/DECODE functions feel like an afterthought. Like, > "oh yeah, let's > > just slap this stuff in and have it only work on strings!". I > would love to > > They don't only work on strings, it's just that they return > strings. http://www.mysql.com/php/manual.php3?section=Miscellaneous_functions ENCODE(str,pass_str) Encrypt str using pass_str as the password. To decrypt the result, use DECODE(). The results is a binary string. If you want to save it in a column, use a BLOB column type. DECODE(crypt_str,pass_str) Descrypts the encrypted string crypt_str using pass_str as the password. crypt_str should be a string returned from ENCODE(). and YES, I did try them on DATE and INT fields, even on CHAR and VARCHAR -- you MUST use CHAR BINARY or VARCHAR BINARY or they won't decode. The other types won't even encode. you get 0 or 000-00-00 in the table. > While the extension you mentioned would be interesting, thank you. I was rather pleased with them myself ;-) > it would also completely break > things like indexes and queries. WHAT?! You can't INDEX an ENCODED field currently either (well, you prolly can, but what good does it do you, when you search, you're searching for the DECODED'd value, not the ENCODED one) and the extensions mentioned clearly illustrated both an INSERT and a SELECT. it's not rocket science. it's basically just easing the amount of ENCODE/DECODE fields you have to get back. plus it eliminates the need to say, SELECT DECODE(blah,'secret') AS blah... otherwise the field is basically useless in PHP without using the row[index number] (yuk). > think you're trying to put too much in the database. I'm only extending and making a built in 'feature' more user friendly, transparent and secure. > Another > approach would be to define objects for > all of your records, use serialize() to turn each object into a > string (which could be encoded using > the mcrypt functions) and store that. Once you retrieve that > object back, use unserialize() to > restore it. this isn't at all secure IMHO. anyone can unserialize the data then. My way, only the user who knows the key 'secret' can undo their own data. d.