Password encryption

[RB Smissaert]

Trying to workout SQLite database security for the following situation:

I have a clinical database (Firebird database with patient data) from which I download data daily and unattended and move that data to a SQLite file.
This process is done in VBA and VB6. The previous SQLite file (from the previous day) is just killed, so no trace of that is left and a completely new file is made from fresh data from the Firebird database.

This SQLite file is this then copied to a WM device and the data is accessed with a Basic4PPC interface.

Security of all this should be as follows:
The SQLite file will be encrypted. This has to be done in VB or VB6 on the desktop and it can be done either when the SQLite file is newly created or after the file has been filled with data.
To connect to this SQLite file with the B4P interface the user will have to supply a password that allows connecting to the encrypted SQLite file.

As I see it the B4P side of things is simple, just input the right password and you can connect and see the data. With the new B4P 6.8 this is easy and as far as I can see performance is very good, meaning having the SQLite file encrypted doesn't make it much slower.

The difficulty is with the VBA/VB6 side of things. Once the user has chosen a password this will have to be stored somewhere as it will need to be used everytime a new SQLite file is made and encrypted. So, this password willl need to be hashed or whatever and stored somewhere in an altered form.
Then there also needs to be the option to alter the password, either from the WM device or from the desktop application that does the daily data download.

Would there be a safe way to handle the above situation and what would be the best algorithm to do this? I just had a look at a VB implication of Blowfish
and that looks promising.
Thanks for any thoughts/advice on this.

RBS

 

[agraham]

What exactly are you trying to secure and from whom? Access to the data on the device where only a user who knows the password can access it?

What security, if any, is needed on the unattended desktop? Is it available to other people or is it physically secure? If it's physically secure then you don't really need to protect the password in your VB6 code. If the desktop is available to others what do they have access to on it?

If you want to remotely change the password and not transmit it in clear then it will need to be protected in some form. This opens another layer of issues. Is the level of threat/interception high enough to warrant this complication for what is a very brief, and possibly only theoretical, exposure or is this getting a little paranoid if it is only casual inquisitiveness about personal data that you are protecting against.?

 

[RB Smissaert]

This is a SQLite database on a WM device and the main thing to worry about is losing the WM device, somebody picking it up and looking at the unprotected data of that SQLite file. I am not that worried about the desktop, but it would have just have the same protection as the WM device in any case.
This SQLite file will be made daily, un-attended via the Windows task scheduler, so the user can't enter the password manually.
Protection is important as this is confidential patient data.

RBS

 

[agraham]

I am not that worried about the desktop,

From what you say its all entirely under your control for your own use so I would do the simple and obvious (and easy). Put the password in your VB6 code and not worry about protecting it assuming the machine is physically protected. If the password ever becomes compromised or you just want to change it you have to go to the desktop machine and edit the file otherwise you just download the file every day and open it on the device using the password in your head. Simple, staightforward and uncomplicated - that's always best

 

[RB Smissaert]

Put the password in your VB6 code

That was my first thought. As you say it is simple and secure as it is very hard to de-compile a VB6 dll. The problem is that all users will then have the same password and there is more chance it coming out in the open. Also as the password is not personalised it will have to be a simple one, again making it more likely it will make the data un-safe.
I am thinking now about using RC4 with the key in the VB6 .dll and the encrypted password in my application .ini file.

RBS

 

[agraham]

all users

Ah, you didn't mention that! You said " I download data daily" so I asumed a single user which is why I commented "under your control for your own use". You can never have too much information in assessing these scenarios.

I assume multiple users imply individual copies of the data file each with their own password so even a password is leaked only that one users' device is compromised. Again I would keep it simple and assuming the desktop is secure keep all the passwords in the VB6 code or in an ini file associating a filename with a user. You could encrypt that ini file with a password burnt into the VB6 code, and from what you say that would be reasonably secure.

Then it would be easy to have an ini file on the device indicating the filename to download for the assigned user of that device, assuming each user always has the same device. Otherwise you could get the users name from him/her when they start the device download and load the correct file for the user.

If you are not careful you can end up writing more code for the administration of the security than for the actual application.

 

[RB Smissaert]

keep all the passwords in the VB6 code

That would be nice, but how can I get a password, supplied by the user in the VB6 code, without re-compiling the dll?

RBS

 

[agraham]

how can I get a password, supplied by the user in the VB6 code, without re-compiling the dll?

You probably can't. Only you can decide whether the frequency of it being required makes the few minutes it would take a burden. You could keep the user/password list in a data file needing a simple edit. If you judged it needed to be encrypted you could encrypt it with a key burnt into the VB6 code if you judge that to be secure enough. If encrypted you would need to write a small utility to decrypt, update and re-encrypt that data file and so it goes on...

 

[RB Smissaert]

OK, thanks for the assistance and I will work something out.

RBS

 

[RB Smissaert]

Just to say that this is now all fixed. User supplies a password that is encrypted and stored and then in a .dll this is decrypted with a key that is only in the .dll. Looks secure enough to me and simple as well.

RBS