Re: [sqlite] SQLite Encryption Extension (SEE) and Public Domain Sqlite

2011-07-07 Thread Black, Michael (IS)
If you hash the username too you don't have that problem.

Passwords should always be a 1-way hash.

It's actually best to collapse username/password into a single one-way hash.

That way it's very difficult to crack it.

You can use a user "account#" value that users would have to track for support.





Michael D. Black

Senior Scientist

NG Information Systems

Advanced Analytics Directorate




From: sqlite-users-boun...@sqlite.org [sqlite-users-boun...@sqlite.org] on 
behalf of Simon Slavin [slav...@bigfraud.org]
Sent: Thursday, July 07, 2011 2:16 PM
To: General Discussion of SQLite Database
Subject: EXT :Re: [sqlite] SQLite Encryption Extension (SEE) and Public Domain 
Sqlite


On 7 Jul 2011, at 7:41pm, Prakash Reddy Bande wrote:

> I wanted to get an understanding of SQLite Encryption Extension. I am 
> currently using sqlite-3.7.2, and if I want to use SEE, would it be equally 
> compatible. Well, thehttp://www.hwaci.com/sw/sqlite/see.html page does not 
> give much information, i.e. do still build sqlite from public and inject 
> encryption or it is a parallel code base.

SEE is delivered as C source code the same way SQLite is.  If you currently 
compile SQLite into your application you just remove the SQLite .c and .h 
files, put the SEE ones in their place, and recompile.  You can then ignore the 
extra functions entirely (it'll read unencrypted SQLite databases) or use the 
extra functions by C calls or PRAGMAs.

I'm not familiar with the release schedule for SEE.  I doubt it's far behind 
the current release of SQLite.

> Well, all I want to actually do is store passwords in a column and hence it 
> should be encrypted. Of course, alternatively I can do encryption for that 
> value in my application. But I guess it is a nice option to keep the entire 
> db encrypted so that users cannot explore and accidently mess with it using 
> sqlite CLI.

The SEE set will work very well for that.

The problem with encrypting just columns of a database is that it allows people 
to mess with it.  For example, suppose I want to break into someone's account 
and I can see their username and encrypted password in a row.  I copy the 
contents of my own password field into their password field.  Then I can log 
into their account using my password.

Encrypting the entire database prevents this sort of thing.

Simon.
___
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


Re: [sqlite] SQLite Encryption Extension (SEE) and Public Domain Sqlite

2011-07-07 Thread Simon Slavin

On 7 Jul 2011, at 7:41pm, Prakash Reddy Bande wrote:

> I wanted to get an understanding of SQLite Encryption Extension. I am 
> currently using sqlite-3.7.2, and if I want to use SEE, would it be equally 
> compatible. Well, thehttp://www.hwaci.com/sw/sqlite/see.html page does not 
> give much information, i.e. do still build sqlite from public and inject 
> encryption or it is a parallel code base.

SEE is delivered as C source code the same way SQLite is.  If you currently 
compile SQLite into your application you just remove the SQLite .c and .h 
files, put the SEE ones in their place, and recompile.  You can then ignore the 
extra functions entirely (it'll read unencrypted SQLite databases) or use the 
extra functions by C calls or PRAGMAs.

I'm not familiar with the release schedule for SEE.  I doubt it's far behind 
the current release of SQLite.

> Well, all I want to actually do is store passwords in a column and hence it 
> should be encrypted. Of course, alternatively I can do encryption for that 
> value in my application. But I guess it is a nice option to keep the entire 
> db encrypted so that users cannot explore and accidently mess with it using 
> sqlite CLI.

The SEE set will work very well for that.

The problem with encrypting just columns of a database is that it allows people 
to mess with it.  For example, suppose I want to break into someone's account 
and I can see their username and encrypted password in a row.  I copy the 
contents of my own password field into their password field.  Then I can log 
into their account using my password.

Encrypting the entire database prevents this sort of thing.

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