Security Question

[BigChimp]

Keep on going Elmug, you'll convince them.

Database passwords are inherently secure and can never be intercepted (not even by patching the program that processes them by intercepting every single character that the user types).

So, setting up a database just to store your encryption key used to e.g. encrypt your mail messages makes perfect sense and does not increase your system's attack surface at all. You would never have to worry about attackers gaining access to either the database password or the encryption keys.

[Elmug]

Keep on going Elmug, you'll convince them.

Database passwords are inherently secure and can never be intercepted (not even by patching the program that processes them by intercepting every single character that the user types).

So, setting up a database just to store your encryption key used to e.g. encrypt your mail messages makes perfect sense and does not increase your system's attack surface at all. You would never have to worry about attackers gaining access to either the database password or the encryption keys.

Big Chimp,

You are wrong in stating of me setting up a database just to store passwords.

Databases are set up (me and most people) to store data, and the passwords are typically just another table of the database, which the database management system uses to grant access to users of the database.

I am sorry to say that I am finding your arguments without sense, specially those where you state that I am "trying to convince people".

There is no ned for that. Professional IMS people store passwords in the database. You know that, and that is the basis for my stating that your arguments don't have sense.

[BigChimp]

The fact that I understand why goodname made that joke probably indicates that both he and I must be wrong.

If you find my arguments without sense, I don't understand: earlier on you seemed to say using databases doesn't increase attack surface. Now I confirm that and you say my arguments are without sense? Which is it?

passwords are typically just another table of the database, which the database management system uses to grant access to users of the database.

Professional IMS people store passwords in the database.

I thought database management systems stored passwords in the database (e.g. via CREATE USER statements)... well, live & learn.

So what database do you think the OP should use to store the encryption key for his USB stick DBFs? Sqlite? Firebird embedded?

[KpjComp]

I thought database management systems stored passwords in the database (e.g. via CREATE USER statements)... well, live & learn.

In what way is @Elmug saying differently?,  using a statement like above ends up storing the password in some sort of system table.  Or are you just having one of those days @Bigchimp?

[goodname]

The original recommendation by Elmug was to add a database to an application that didn't currently use a database. This database would hold encryption keys and nothing else. The right to the use the key was automatically granted by the ability to run the application so the right to open the database would also be automatically granted as well.

[BigChimp]

I thought database management systems stored passwords in the database (e.g. via CREATE USER statements)... well, live & learn.

In what way is @Elmug saying differently?,  using a statement like above ends up storing the password in some sort of system table.  Or are you just having one of those days @Bigchimp?

Just thought that the RDBMS would store the passwords hashed so you could never retrieve the plaintext value... obviously not. Otherwise Elmug could never get the encryption key out of the db again to decrypt the DBF.

Still, I'm looking forward to Elmug's suggestions.

[KpjComp]

The original recommendation by Elmug was to add a database to an application that didn't currently use a database.

I'd agree adding a database layer is a bit over the top if this application is not currently using such.  My example ExcryptionTest.zip attached does the same without this layer.   In a way a good database with encryption level security should apply this same technique.   The only thing I'm not sure with this technique for the OP, is his protection against unauthorized access, or authorized access?.  Because if the user has the encryption password, then it's no use against authorized access.   What I mean by this, using a encryption passwords are fantastic against loss of data, eg.  you left you laptop on the train and it had personal information stored, our government has a knack of doing this.

Just thought that the RDBMS would store the passwords hashed

Most definitely, but I'm not sure @Elmug is wanting to retrieve this password again, but only use the database security for granting access to other parts of the database that has the information required.  But I might be wrong, I'll leave @Elmug to explain.

[Elmug]

The original recommendation by Elmug was to add a database to an application that didn't currently use a database. This database would hold encryption keys and nothing else. The right to the use the key was automatically granted by the ability to run the application so the right to open the database would also be automatically granted as well.

Goodname,

You need, would say, to improve your reading/comprehension skills:

This was my first statement:

I'd say that any data that needs to be secure, be in a database, and let its engine handle the password authentication.

If you elect to guess what this means, and is in plain text, even if you were to manage to decrypt code or data, if you add to the contents, you could lead yourself or others astray.

Since you misread: What this means, to the original OP, is put all your data in a database that uses passwords, let your application manipulate the data.

Now, since maybe this also needs to be told: If there is no use for specialized manipulation of data (math, calculations, etc.) then likely there is NO NEED for applications, since the SQL language that free and very powerful database manager engines INCLUDE is VERY POWERFUL.

The standard ANSI SQL language has math capabilities, in addition to very powerful predicate calculus basis. Things that could be extremely difficult to program.

On top of that, when an SQL database engine (and most are now days) is used, THERE ARE many software applications that allow specialized and conventional extraction of data from a database WITHOUT having to write applications. Thererfore, even if quite a bit of math might be needed, there may be cases in which no application writing might be needed. See? You get BOTH of the options.

The joke for you to learn is that YOU'd still be required to produce credentials (vulgar: password).

[BigChimp]

Ah, I see, Elmug: your solution is to have the OP dump his DBF for something else.

What file-based database (because it needs to store data on an USB stick) offering encryption of the data that works with Lazarus would you suggest?

[Elmug]

Ah, I see, Elmug: your solution is to have the OP dump his DBF for something else.

What file-based database (because it needs to store data on an USB stick) offering encryption of the data that works with Lazarus would you suggest?

BigChimp,

I do not have enough basis of real needs, value/importance of the data, etc., to recommend one, not meaning to be hard-headed.

Yet, without a question, one first thing might be to learn the SQL (query language) basics. That could be an eye-opener for someone who needs to manipulate data.

Most of the databases that are for desktop use would do for him to explore and determine if one fits his need.

I use SQLite3 right now for some research on databases that I am doing. But the plan is to move everything to Postgress or Oracle.

I did find, though, that SQLite3 is very very powerful and versatile. It does not use passwords, but for development it is great.

So, for learning, it'd be OK. And for storing critical data can be used if you encrypt the entire folder(s) with 7-Zip, with password, after use. That simple discipline, additionally, allows easy back-up to external storage, local or remote.

Of course, with Lazarus, I do hit the SQLite with .exe applications and am finding Lazarus an excellent development platform.

In fact, I chose Lazarus because it is a replica of Delphi, and most of you all know that Delphi was written to work with databases.

[KpjComp]

What file-based database (because it needs to store data on an USB stick) offering encryption of the data that works with Lazarus would you suggest?

SQLCipher would be handy for USB sticks, it's based on SQLite
http://sqlcipher.net/

So should work with current Lazarus Api bindings.

[Elmug]

Echoing KpjComp,

Here's a list of add-ons for SQLite3, some of which even add a little bit of Google capability (written by Google engineer). Most are free, or at least allow a free trial.

http://www.sqlite.org/cvstrac/wiki?p=ManagementTools

[BigChimp]

I do not have enough basis of real needs, value/importance of the data, etc., to recommend one, not meaning to be hard-headed.

So, for learning, it'd be OK. And for storing critical data can be used if you encrypt the entire folder(s) with 7-Zip, with password, after use.

Thank you.
So you say he should encrypt the database file after use... eehmm... just like the OP is doing now , right?
You're saying he should switch to another database (you don't know which).... and then encrypt it like he's doing now???
Ok.
Can't see why that took so many posts... but I'm glad to know your suggestions.

[Elmug]

I do not have enough basis of real needs, value/importance of the data, etc., to recommend one, not meaning to be hard-headed.

So, for learning, it'd be OK. And for storing critical data can be used if you encrypt the entire folder(s) with 7-Zip, with password, after use.

Thank you.
So you say he should encrypt the database file after use... eehmm... just like the OP is doing now , right?
You're saying he should switch to another database (you don't know which).... and then encrypt it like he's doing now???
Ok.
Can't see why that took so many posts... but I'm glad to know your suggestions.

As said, for a desktop database that does not use passwords, and does not use encryption, an alternative is to compress the folder(s) with 7-Zip or similar, which does have the option to encrypt the folder(s) resulting in a SINGLE file that is easy to move/copy for backup purposes.

The UN-zipped folder, for security or whatever reason, can then be wiped out.

Also, SQLite3 can be worked at a USB stick, and if you take that to Fort Knox for safekeeping, maybe there is no need to encrypt it.

[BigChimp]

Ok, Elmug, so you're saying to do something like this:

My case is a lot specific:

A- My program is a finance manager (hot target for malicious people)
B- Portable, runs at usb disks (pendrives)
C- Because of portability, the database needs to be local (I'm using DBF)
D- Table files won't be stored in disk while decrypted (in TMemoryStreams)
E- The DBF's engine doesn't support encryption, so I can load it in memory and store it encrypted in disk
F- I'm thinking about encryption by user key, but if user lost the password, will be impossible to recover data
G- If I store keys in a separated file, is so easy to find it (search by creation date, modification date and so many ways, too, I will lost the portability)

I implemented many protections (against AutoIt, O'Matic, brute force [with temporized login, changing the memory addresses, etc], capturing coordinates of clicks, changes in executable file, etc, etc, etc), but with storing cryptographic keys I'm not doing a good job.

So, have anyone more ideas that can help me?
Suggestions that can help me with another protections?