First of all, why are you even storing the password for encrypted
text? Allow the user to create a "Key" the first time they logon and the
encryption routine can use it to do its work. The only downside is of
course that if the user forgets the key he or she used there's no way to
recover the data. But the main thing is that there's no way for anyone else
to get it either!
Also, when ever I've had to keep large amounts of text safe...text
that may be edited by the user at anytime and thus cannot be hard coded, I
use either an encrypted text file, or if a dB app, a blob field in an
APP_Table. Again, in either case I use an encryption key that only the user
knows and is not stored anywhere.
Finally, I had one situation where there were a number of users,
each one having the need to store encrypted data, but that the owner of the
business wanted access to in case of an emergency. So I created a user
table which held encrypted versions of the "Keys" each user employed to
encrypt their own work. These encrypted versions were encrypted with a Key
only the owner knew and which he kept at home in a safe. HtH's.
from Robert Meek dba Tangentals Design CCopyright 2006
Proud to be a moderator of "The Delphi Lists" at elists.org
(["An unused program is the consequence of a higher logic!", nil]) As
written in The Compendium of Accepted Robotic and Surrlogic Theorems Used in
the Self Analysis of Elemental Positronic Pathways...1st Edition Revised
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Rob Cameron
Sent: Friday, January 26, 2007 6:08 AM
To: [email protected]
Subject: Secure text in apps
Good day to you all!
This is a very common problem which I have partly solved in a variety of
ad hoc ways over the years but would appreciate advice on.
I want to store small amounts of text in an application, as securely as
possible. Typical examples might be user-names and passwords, or other
validation data such as license period dates, etc. The simple way is to
provide an INI file or similar, use the password to encrypt itself,
require the user to log in and use a successful password check as the
key to open more doors.
However, if a multi-user app requires access to a database - it implies
the app knows the path, user and password for the DB - before asking
individual users to log-in. The individual user passwords are stored in
a USERS table in the DB, but how to store the user and password for the
DB itself? I suppose one solution is to have an INI file on every
client with a(n encrypted) list of all user details, but that is not a
nice solution. And I don't want users to have to go through two stages
of username/password entry to get into an app.
One solution I have used is the 3rd party components IceLicence and
SecureCode from IonWorx, both of which offer a "SecureStrings" property
where the text is stored encrypted - like a TStrings but
encrypted/decrypted on the fly. However, I am uneasy about 3rd party
components.
1. I lose control over how it is implemented but my clients have to
take my word that someone else's components are secure enough.
2. 3rd party, commercial solutions attract the attentions of crackers.
As far as I can tell the IonWorx products are high quality but there has
been debate and criticism of them on other forums, and claims that they
have been cracked which make me a bit uneasy.
3 I think an important part of security is the introduction of a bit of
eccentric, individualised coding for each project which makes it that
little bit more effort to crack and less worth it for just one product.
Other solutions I've tried, more or less successfully:
- use a mathematical method to compute a password (OK as long as the exe
is not reverse engineered);
- use an algorithm to select single characters from other innocent text
strings such as object names and thus assemble a password;
Both of these give headaches if you want to change passwords regularly.
Can anyone make suggestions, or point me at a web-page, tutorial etc
that might help? I appreciate that I will not be able to create a
perfectly uncrackable system, but just avoiding plain text saved in the
exe would be a good start.
Many thanks,
Rob
_______________________________________________
Delphi mailing list -> [email protected]
http://www.elists.org/mailman/listinfo/delphi
_______________________________________________
Delphi mailing list -> [email protected]
http://www.elists.org/mailman/listinfo/delphi
