Re: [sqlite] Best practices for dealing with password protected database

[Simon Slavin]

On 31 Oct 2011, at 8:07am, Eugene N wrote:

> For your .NET application to use the, DB it must first decrypt it; That
> means, storing the plain version in ram; A memory dump will pronto show the
> contents of this sqlite database;

Physical possession of the hardware concerned is always an end to encryption 
methods.  Once they've got the computer it's just a question of how much time 
and effort they want to figuring out where you put the password.  That's one 
reason so many systems have just thin clients on your user's hardware and do 
all the secure stuff on a server back in headquarters.

Igor's approach is as good as any: use a password that doesn't look like a text 
string.  You can also introduce an additional step of scrambling the password 
you store in some way, so a cracker doesn't spot a mystery string in a 
configuration file and say "Well, I guess that's the password in plaintext.".

Simon.
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Best practices for dealing with password protected database

[Igor Tandetnik]

Bernd  wrote:
> This may not be really SQLite specific, but as it's at least SQLite
> related I thought I asked here.
> Our program ships with an encrypted SQLite database that has to be
> opened by the application to process some other data. As it's a .NET
> application, it's very easy to peek inside the source code (even though
> I'm planning to use an obfuscater tool). Are there any best practices on
> how to store the password to open the database?

Generate a random password when first creating the database. Encrypt it using 
ProtectedData.Protect and store the encrypted version somewhere (e.g in the 
registry, or in a file alongside the database file). Decrypt with 
ProtectedData.Unprotect before using.

This effectively encrypts the password with the user's Windows login 
credentials.
-- 
Igor Tandetnik

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Best practices for dealing with password protected database

[Eugene N]

Hello Bernd!

I have a very limited knowledge about such matters, but it seems to me
there is a caveat in the whole area of using encrypted data on a end-user
pc;

For your .NET application to use the, DB it must first decrypt it; That
means, storing the plain version in ram; A memory dump will pronto show the
contents of this sqlite database;

There is also handy way of using a debugger to find the function that
decrypts the db (by monitoring all standard .NET disk I/O, obviously the
function will have to read the file first);

So, given that you are aware of those issues, there is a way that has been
known to work in the past (for C programs)  - implement certain
anti-debugger techniques (program detected the presence of a debugger and
behaved differently or erratically);
Storing a password in an obscure manner (not a string! cause they can be
sniffed by 'strings' utility with ease) also is a good option; Using hash
to calculate password at run-time can aslo complicate the job of a will-be
hacker;

Hope that is helpful

Eugene


2011/10/31 Bernd 

> This may not be really SQLite specific, but as it's at least SQLite
> related I thought I asked here.
> Our program ships with an encrypted SQLite database that has to be opened
> by the application to process some other data. As it's a .NET application,
> it's very easy to peek inside the source code (even though I'm planning to
> use an obfuscater tool). Are there any best practices on how to store the
> password to open the database?
> To put things clear - we don't want to make the program absolutely
> hacker-proof, but simply avoid making it too easy for everybody to see how
> the database is structured and what it contains.
> __**_
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-**bin/mailman/listinfo/sqlite-**users
>
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

[sqlite] Best practices for dealing with password protected database

[Bernd]

This may not be really SQLite specific, but as it's at least SQLite 
related I thought I asked here.
Our program ships with an encrypted SQLite database that has to be 
opened by the application to process some other data. As it's a .NET 
application, it's very easy to peek inside the source code (even though 
I'm planning to use an obfuscater tool). Are there any best practices on 
how to store the password to open the database?
To put things clear - we don't want to make the program absolutely 
hacker-proof, but simply avoid making it too easy for everybody to see 
how the database is structured and what it contains.

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users