On 30 Aug 2011, at 2:59am, Teg wrote: > PI> If someone was ambitious enough they could attach a debugger to your > PI> application, extract key used to decrypt the database and obtain all > PI> the sensitive information you have. So if you really want to protect > PI> your database against those who is able to attach a debugger you > PI> shouldn't use SQLite. > PI> Pavel > > This is the key. It depends on how secure you need it to be. If it > really needs to be secure then having the encryption key in memory or > in the application means it's not all that secure. This isn't a > limitation of SQLite though. It's a limitation of running a program on > someone else's hardware.
Right. Which is why professional banking software keeps all its data on the computers belonging to the bank, not on customer computers. > You could encrypt the SQL and then decrypt right before usage then > clear it from memory. Won't stop a debugger but, it will stop them > from pulling the strings out of your application directly. Yep. There are techniques for doing all this. But physical possession of the hardware trumps them all. Because they can decompile your app and figure out what it's doing. The only way around it is to have a user remember the decryption key. Not a password which lets them into the system, but the actual key which is needed to decrypt the data. Simon. _______________________________________________ sqlite-users mailing list [email protected] http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
