Rob Cameron wrote: > 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?
Your database server should already support authentication. What database system are you using? One nice thing about that is that user management is no longer necessarily your problem. It's the DBA's responsibility. The user doesn't need to have a separate account for your program. If the database server supports the same authentication that the users use to log in to Windows, then they might not even need to log in to your program at all; the database could detect that the user is already logged in the Windows. > 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. Also, they would be unable to change their passwords. The INI file could not be world-writable without letting users destroy each other's account information. > 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. Note: Windows is a third-party componet. So is the database, I suspect. > 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. Not really. What you seem to be describing is security through obscurity. All a hacker needs to do is debug your program and wait for your program to unencrypt the data. Then the hacker can read the plaintext from your program's memory. I don't know how to solve that, but if you decide to write your own encryption code, you'll have to solve it. > 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); If you're afraid of someone hacking a third-party security package, then you have to assume it's been done to yours, too. I think it's better to just assume everyone already has the source code to your program. Don't rely on doing "secret things" in your program. Rely on a secret that not even you, the programmer, know. > - use an algorithm to select single characters from other innocent text > strings such as object names and thus assemble a password; That's just another secret that anyone monitoring the computer could discover. A hacker will debug your program and monitor disk activity. -- Rob _______________________________________________ Delphi mailing list -> [email protected] http://www.elists.org/mailman/listinfo/delphi
