Potential security whole: SQLite

[Dennis]

Hey there,

if you install SQLite, you can lookup the KeepassDroid Database and
take a look inside it. All usernames and notes are visible without any
encryption. I guess that's a potential security whole especially if
you have added additional passwords/security questions to the notes
section.

[Brian Pellin]

The database file is owned by the keepassdroid user and only readable by that user. If you have access to read that file, then you also have access to read the keepassdroid process's memory, which also contains this data unencrypted. So, I don't think this file represents a reduction in security.

Let me know if you think I'm missing something.

-Brian

On Jun 13, 2011 8:32 AM, "Dennis" <dennis...@gmail.com> wrote:

[dbareis [Windows Installer MVP]]

Hi,

A phone may or may not have any security (pin/pattern unlock), we
expect the DB to be encrypted
so that the DB password is enough protection (I do have simple an
unlock pattern). I'm pretty sure I could take the
SDCARD to my PC and do the same thing (I have reason other phone SQL
DBs that way.

From the Keepass site:

> KeePass database files are encrypted.
> KeePass encrypts the complete database, i.e. not only your passwords.
> The user names, notes, etc. are encrypted, too.

I don't think you should be reducing the security by not having it
encrypted,
I assume you do that for performance reasons (search etc), maybe OK to
create a temp copy unencrypted if that is possible if the user also
sets an option for that...

Bye
Dennis

> On Jun 13, 2011 8:32 AM, "Dennis" <dennis.kue...@gmail.com> wrote:

[Dennis]

Sorry about all the typos :-)
whole -> hole
SQLite -> SQLite Editor

So I have the sqlite editor on my phone which runs under general
access rights. If somebody finds my phone and guesses the login-swipe-
pattern which is not that un-easy, he could just start the sqlite
editor and view all tha data. That's why I want to suggest to add a
user option for encryption of the chached data.
I would rather wait 10 seconds more for accessing each entry if I know
that my data is safe.

Cheers

[Brian Pellin]

It looks like SQLLite editor runs as root. Otherwise, it shouldn't be able to read the database. If you let an app run as root, it can read the unencrypted database in your phone's memory. It doesn't sound to me like encrypting the sqllite db protects you against an application running as root from accessing your unencrypted database.

I'm open to consider changing the way it works, if there is a threat model that allows you to access the sqllite db, but not the keepassdroid proccess.

-Brian

On Jun 14, 2011 8:38 AM, "Dennis" <dennis...@gmail.com> wrote:

[riksa]

I implemented InMemorySearchHelper and replaced the SQLite based
search helper with it. Granted, it's not a great solution, but it did
fix a few unrelated bugs and it made this issue slightly harder to
exploit (you no longer have a file on a device you can read, you
actually need to access the data in memory). Since the interface of
the SearchHelper receives decrypted DB Entry objects, it would require
quite a bit more work to implement searching so that the data is
decrypted on demand, and not kept decrypted in memory. something //
TODO: later

https://github.com/riksa/keepassdroid/commit/bfbad507f958b4d681212d13e83e8df6ba5e33d6

On Jun 15, 6:58 pm, JNavas <john.na...@gmail.com> wrote:
> As a security professional, and with all due respect and appreciation,
> I do think you are missing something, and even more important, relying on
> assumptions.
> *"Assumption is the mother of all screw ups." [Wethern’s Law of Suspended
> Judgement]*
>
> A proper security app should only decrypt the *absolute minimum* amount of
> data for the
> *absolute minimum* amount of time, *never* write unencrypted data to
> persistent storage,
> and *overwrite* decrypted data as soon as possible.
>
> It's *impossible* to know all possible threat vectors. We must therefore be
> *paranoid* about
> protecting against *overlooked* threat vectors, particularly those arising
> from *security flaws
> elsewhere in the system*, a well-established principle known as
> "protection-in-depth".
>
> Since the complete database is encrypted, this puts the onus on KeePassDroid
> to
> maintain the *highest possible level of security* for *any and all* data in
> the database.
>
> My $0.02,
> John

[dbareis [Windows Installer MVP]]

Hi,

On Jul 6, 2:26 am, riksa <riku.sal...@gmail.com> wrote:
> I implemented InMemorySearchHelper and replaced the SQLite based
> search helper with it. Granted, it's not a great solution, but it did
> fix a few unrelated bugs and it made this issue slightly harder to
> exploit (you no longer have a file on a device you can read, you
> actually need to access the data in memory). Since the interface of
> the SearchHelper receives decrypted DB Entry objects, it would require
> quite a bit more work to implement searching so that the data is
> decrypted on demand, and not kept decrypted in memory. something //
> TODO: later
>

> https://github.com/riksa/keepassdroid/commit/bfbad507f958b4d681212d13...

Excellent, I was thinking I was going to have to look for an
alternative
product for both my phone and desktop :-)

Bye,
Dennis

[Brian Pellin]

There is no point in worry about the search db being unencrypted in
memory, since your database in already unencrypted in memory.

I wonder if a better approach would be to make search loop over the
groups and entries in the existing PwDatabase object instead of making
a duplicate of all of those strings and putting them instead a
HashMap.

-Brian

[riksa]

It's in memory, unencrypted, when it has been decrypted and hasn't
been garbage collected. The DB is on device, accessible, always
(after it is initially created). After reboot for example, the DB is
readable, but the memory contains nothing of interest.

I know this is getting pedantic, but as I said in the commit log, I
fixed two unrelated issues, and as a side effect it also made this
issue slightly less exploitable. TBH I see little reason in using DB
for this job anyway...

On Jul 6, 12:48 am, Brian Pellin <bpel...@gmail.com> wrote:
> There is no point in worry about the search db being unencrypted in
> memory, since your database in already unencrypted in memory.
>
> I wonder if a better approach would be to make search loop over the
> groups and entries in the existing PwDatabase object instead of making
> a duplicate of all of those strings and putting them instead a
> HashMap.
>
> -Brian
>
>
>
>
>
>
>
> On Tue, Jul 5, 2011 at 11:26 AM, riksa <riku.sal...@gmail.com> wrote:
> > I implemented InMemorySearchHelper and replaced the SQLite based
> > search helper with it. Granted, it's not a great solution, but it did
> > fix a few unrelated bugs and it made this issue slightly harder to
> > exploit (you no longer have a file on a device you can read, you
> > actually need to access the data in memory). Since the interface of
> > the SearchHelper receives decrypted DB Entry objects, it would require
> > quite a bit more work to implement searching so that the data is
> > decrypted on demand, and not kept decrypted in memory. something //
> > TODO: later
>

> >https://github.com/riksa/keepassdroid/commit/bfbad507f958b4d681212d13...

[riksa]

Alredy there in my fork. Pending pull and release from brian.
On Jul 18, 6:02 pm, JNavas <john.na...@gmail.com> wrote:
> Good. Thank you.
>
> p.s. I would like KeePassDroid search logic to be identical to KeePass;
> e.g., simple substring search instead of regular expressions
> ("wells" finds WellsFargo instead of needing "wells*")..

>
>
>
> On Tuesday, July 5, 2011 9:26:25 AM UTC-7, riksa wrote:
>
> > I implemented InMemorySearchHelper and replaced the SQLite based
> > search helper with it. Granted, it's not a great solution, but it did
> > fix a few unrelated bugs and it made this issue slightly harder to
> > exploit (you no longer have a file on a device you can read, you
> > actually need to access the data in memory). Since the interface of
> > the SearchHelper receives decrypted DB Entry objects, it would require
> > quite a bit more work to implement searching so that the data is
> > decrypted on demand, and not kept decrypted in memory. something //
> > TODO: later
>
> >https://github.com/riksa/keepassdroid/commit/bfbad507f958b4d681212d13...
>

> > > > On Jun 14, 2011 8:38 AM, "Dennis" <denn...@gmail.com> wrote:

[Brian Pellin]

I decided to take a different approach. I didn't want to create a
second copy of all of the strings in memory.

As of version 1.9.4, search is happening directly over the existing
database that is in memory. No more sqlite database of your database
strings.

-Brian