-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Sambasivarao Vemula wrote: > I want to encrypt a perticular field in sqlite3 database.
You can use the SQLite Encryption Extension which will encrypt the whole database. This is by far the easiest approach and you won't have to worry about accidentally encrypting some fields and not others. After all if you are storing some valuable information, how do you know the rest won't be valuable either? http://www.hwaci.com/sw/sqlite/see.html > I want encrypt a password field in a table Encrypting the password is a very poor approach to password security. In particular if anyone ever gets the encryption key they will be able to extract all the passwords. Some people use the same password in multiple locations which means the compromise could have very far ranging effects. Best practise is to store a one way hash of the password. A one way hash is a checksum of the data that is computationally infeasible to recover the original data from. Two example hashes are md5 and sha1. http://en.wikipedia.org/wiki/Cryptographic_hash_function As an example you store the hash of a password. Later on if you want to check if someone knows the password you then hash what they supply and the two hashes should be identical. If someone manages to obtain your SQLite database, they won't be able to determine what the passwords are so there is less damage if there is a compromise. But wait, there is more. If rows store the same password then they will have the same hash which means if either user sees the file they can compromise the other user. In addition crackers have generated tables mapping all letter and number combinations for possible passwords up to a certain length and their hash values, called rainbow tables. Yes this is a large amount of data - one rainbow table is a 64gb download. But you can simply find a matching hash value and corresponding string that made it. The defense against this attack is to add random data to the password before hashing it, aka salting. You can store the salt in the clear. That helps considerably against the rainbow table attack and also means that different rows having the same password will have a different hash due to the different salt. http://www.codinghorror.com/blog/archives/000949.html http://en.wikipedia.org/wiki/Rainbow_table What this should teach you is that there is a lot of hard thinking that has to be applied. Anyone can design a security system they cannot crack, but that doesn't mean crackers won't be able to. There is a long history of compromise of "secure" designs. A very good thing to do is to get one or more security experts to review your plans. Bruce Schneier has written many good books about security if you want to improve your knowledge. http://www.schneier.com/ Roger -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkomElEACgkQmOOfHg372QT5ZgCggeaZ10VEpo69fsX2BmP7Im4t Q3gAoJ8s9dJO2YeYD+iHUaGl7FhZ2I+E =UwO+ -----END PGP SIGNATURE----- _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
