Re: Re: ENCRYPT() in MySQL

on 30/07/02 7:45 AM, Richard Lynch (rich@phpbootcamp.com) wrote: > You're barking down the wrong well. :-) LMAO > AES_ENCRYPT/AES_DECRYPT is using 128-bit encryption, which would be fine, > but *ANYBODY* who manages to read your "password" (aka "key_string" in the > arg_list) could snatch the CC#s. Since PHP can read the source to execute > to get the password, that makes this suitable *ONLY* if: > 1. You are using SSL (HTTPS) > 2. You *NEVER* store the password anywhere -- It must be typed by a human > into the web-page to store/retrieve the CC#s. > That doesn't sound like what you want. Wouldn't I have this same problem with ANY string encrypted with a key? Either way the key has to be stored on the server in the most secure way possible. They also mentioned with AES_* that you could set the key at connection, then NOT send it with each query. I think AES_* is only available on MySQL 4+, so it's ruled out anyway. > DES_ENCRYPT/DES_DECRYPT is using DES which doesn't totally suck, but, again, > the issue is the des_key_files. If *THOSE* are secure from prying eyes, but > MySQL can still read them somehow, it might be "okay"... But making it > possible for MySQL to read them, but not "too open" for other users is > somewhat of an oxymoron, maybe. I dunno enough about how MySQL accesses > these files and if it starts as 'root' like Apache and then does 'su' or > what, but I'd be very, very careful figuring out *exactly* how MySQL can > read these files safely, but a rogue user should have *NO* *CHANCE* at > getting to them. DES_* requires MySQL to config'd with SSL, which it hasn't been, so this option is also shot down. > Bottom line -- You've *GOT* to make sure you have no chinks in the armour. Thanks *HEAPS* for your info. I emailed my ISP to bitch to them about all this s**t, and they're putting together a new Linux package at the moment which has mcrypt() support... so hopefully in a minth or so, things will be cool... otherwise, it'll be time to move hosts :) Justin French