SQL con.ChangePassword

[RB Smissaert]

Noticed that with an encrypted SQLite database file you can change to a new password without specifying the old password. I know that to do this you have to be connected first (with the old password), but I wonder if it wouldn't be safer to only allow you to change the password by specifying both the old and the new password.

RBS

 

[Erel]

I see your point. However as you wrote, without the password you will not be able to open the database and therefore not be able to change or remove the password.

 

[RB Smissaert]

This password thing is always a bit difficult to comprehend and I can't really argue precisely, but I have a feeling that somehow it will be safer when you have to pass both the old and the new.
Maybe Graham could comment as I think he is into this.

RBS

 

[RB Smissaert]

Maybe Graham could comment

I meant Agraham.

RBS

 

[agraham]

I could write you a chapter of a book on this. Briefly, for a multi-user database accessed by people with different levels of permission to view and change things, for example Oracle, then yes, it is not secure to assume that having the database open is sufficient permission to change anything. However SQLite is not that sort of database. Once an encrypted database is open then the user can do anything to the data and its' structure so it seems reasonable to allow him/her to change the password as well. If you want proper security then SQLite is not suitable for this purpose.

If you haven't read it then Appropriate Uses For SQLite details the sort of uses that SQLite was designed for. I particularly like this sentence that sums it up in a nutshell

Another way to look at SQLite is this: SQLite is not designed to replace Oracle. It is designed to replace fopen().

 

[RB Smissaert]

Thanks for your thoughts on this and I can see they make sense.

RBS

 

[Erel]

Thanks agraham. Interesting post.