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
