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
On 12/03/2006, at 6:23 AM, Christian Miller wrote:
On Mar 11, 2006, at 2:04 PM, Michael Williams wrote:
I think for my purposes simply encrypting the DATABASE itself
would be better. Basically the only encrypted database will be
one of serial numbers and preferences. I don't really want to go
through the trouble of converting/encrypting each individual
entry; not to mention managing a seperate array. I realize that
the DB would be decrypted while working, but it would only be
referenced for very very very short periods of time at the
beginning of any piece of software's run to make sure they have a
valid serial number, etc.
Any suggestions for this? If not, I'll still take any input you
have that would make your previously proposed method "easier". ;)
I do something similar. I read the encrypted database at startup
(as a binary stream), decrypt it in memory, write out the decrypted
database as a binary stream in a temp location and then access it
from there. When the app quits, the temp database is deleted. You
could also read in the new version, encrypt it, and write out the
newly encrypted file in the "default" location.
Christian
Pariahware, Inc. Custom Software
<[EMAIL PROTECTED]>
<http://www.pariahware.com>
--
God loved you so much that He gave His only son Jesus. What have
you done with God's gift?
_______________________________________________
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>
