Well there you go.
I've never used MD5 for anything other than passwords, so never went
into it in too much detail. Good to know....
Tom
On 12/03/2006, at 7:52 AM, dda wrote:
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>
All questions and answers unless otherwise stated are in Relation to
Mac OS X 10.4 and later.
_______________________________________________
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>
