True. Depending on the data sensitivity (Say a phone book) the restriction may be to allow or deny access to modifying phone numbers, changing names, or what have you. It may all be 'public knowledge' within the domain of who has access, so reading the data may not be the security hotspot. But changing the data is the major concern, so encryption doesn't need to come into play.
The other thing is who is going to have access to the data. If everyone who'll be using the data has no concept of what a database engine is, then that might be secure enough for the application. Good or bad design, not a debate I'm going to get into. On Fri, May 20, 2016 at 9:34 AM, Jason H <jhihn at gmx.com> wrote: > > > > Sent: Friday, May 20, 2016 at 6:44 AM > > From: "Richard Hipp" <drh at sqlite.org> > > To: "SQLite mailing list" <sqlite-users at mailinglists.sqlite.org> > > Subject: Re: [sqlite] Password Protect SQLite DB > > > > On 5/20/16, Agarwal, Rajesh <Rajesh.Agarwal at snapon.com> wrote: > > > Not encryption, to password protect the db file. > > > > How is it possible to "password protect" a file without encrypting it? > > -- > > D. Richard Hipp > > drh at sqlite.org > > _______________________________________________ > > sqlite-users mailing list > > sqlite-users at mailinglists.sqlite.org > > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > > > Quite simple (pseudocode): > database_password = get_password(filename); > if (input_password != database_password) return error; > > However this approach as you intuitively recognized is not any "real" > protection at all. It's just an inconvenience step > > > _______________________________________________ > sqlite-users mailing list > sqlite-users at mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users >
