md5 is a hash function, not encryption. It's good for trap-door password encryption and fingerprinting, but that's about it.
RB's database is sqlite3, and it doesn't do AES_(EN|DE)CRYPT. The feature request should go to sqlite.org... OTOH, there is a commercial solution at http://www.sqlcrypt.com for [supposedly, I haven't tried it] seamless encryption of the whole database. But this is not the same thing entirely. Anyway, 149$ for that is a bit expensive I'd say, as this could be easily replicated in RB with openssl's encryption functions. Maybe that's a good subject to broach in RBDeveloper... -- dda libcurl4RB, [S]FTP transfers made easy http://sungnyemun.org/?q=node/8 RBDeveloper Columnist, "Beyond the Limits" http://rbdeveloper.com On 3/11/06, Tom Benson <[EMAIL PROTECTED]> wrote: > Does RB's internal Database not have inline Encryption and Decryption > functions similar to MySQL??? > > I use AES_ENCRYPT and AES_DECRYPT all the time, and you can use them > inline with queries and it will work just fine.. > > i.e. SELECT * FROM secure_table WHERE secure_field = (AES_DECRYPT > ('decrypted_value' , 'encoding_key')) > > This gives standard AES 128bit encryption. > > There are many other encryption and compression functions built into > MySQL also, including DES encryption if you have a secure SSL > connection to your database (which you should have for a secure > database, either that or a locally hosted DB). > > Another cool function is MD5(). Currently there is (I believe) no way > to decrypt MD5 encrypted information. So what is it good for?? Mostly > checking for known quantities. e.g. > > 1) A user creates an account and the database sets his password field > to be MD5() encoded > 2) The password is then written as a nonsense string. Even if a DB > admin has read access to that table he cannot find out what the users > password is. > 3) When the user enters their password for verification, you simply > MD5() encode their entered password and compare the encrypted value > to the databases field. No password are ever sent plain text this > way, it's a great implementation (providing no one ever breaks MD5 > encryption...) > > To make a long story short, if RB's internal DB does not have inline > encryption functions, someone somewhere had better create a feature > request. I don't use it enough, but that may all change with the new > multi user server engine they've got in the wings, if it lives up to > their wild claims of speed. Who knows? > > - Tom
_______________________________________________ Unsubscribe or switch delivery mode: <http://www.realsoftware.com/support/listmanager/> Search the archives of this list here: <http://support.realsoftware.com/listarchives/lists.html>
