Are username and password stored in sqlite?

[Gaara]

When i create a replication request, does it store the entire URL including USERNAME and PASSWORD in plaintext in sqlite? Am asking only because i went thru the db and i was able to read the info straight out of it.

Isnt this unsecure?

[Jens Alfke]

On Jun 28, 2012, at 1:53 AM, Gaara wrote:

When i create a replication request, does it store the entire URL including USERNAME and PASSWORD in plaintext in sqlite?

Only if you put the username and password into the URL when you created the replication. It's better to use the Keychain or NSURLCredentialStore instead, as described on the wiki.

Am asking only because i went thru the db and i was able to read the info straight out of it.

Isnt this unsecure?

On iOS it's less insecure than you'd think, because (a) apps are sandboxed so other apps can't see your files, and (b) all app files are stored on-disk encrypted anyway.

But yes, it's still better not to do this, if you can avoid it.

—Jens

[Akash]

Ok i totally forgot to mention that fact that i was referring to Android :)

--
Adrenaline Junkie

[Jens Alfke]

On Jun 28, 2012, at 9:06 AM, Akash wrote:

Ok i totally forgot to mention that fact that i was referring to Android :)

Ah, OK :)

I don't know much about Android, but I assume it probably has some sort of secure password storage system similar to the iOS/Mac Keychain, and/or an API for programmatically supplying credentials for HTTP requests. I don't know if Marty has implemented support for that yet in the Android TouchDB replicator.

There's also an old TouchDB issue requesting support for encrypting the sqlite database file. I think it's moot on iOS for the reasons I described, but it could be worth pursuing on Android. There is an open-source SQLite extension (http://sqlcipher.net/) that does exactly that. Of course, you then need to store the db encryption key somewhere secure …

—Jens

[Marty Schoch]

There is some support for passing in the authentication credentials
without putting them in the URL. But currently this is only available
by directly using TDDatabase. I need to find the right way to expose
this through Ektorp.

NOTE: If you store your TouchDB files in the application files
directory (which is what the demos do) there is similar sandboxing to
the iPhone. If you store your database files on the SDCard you have
much less protection. Again, I'm not suggesting you rely on this, not
putting the credentials in the URL obviously a better all-around
solution.

marty

[Akash]

Ok. Do you think you could out up a small code snippet to demonstrate this?

[Marty Schoch]

On Thu, Jun 28, 2012 at 1:21 PM, Akash <aka...@gmail.com> wrote:
> Ok. Do you think you could out up a small code snippet to demonstrate this?

1. Pull the latest code. We had low-level support for specifying an
HttpClientFactory for a single replication. I added support for
specifying a single factory at the server level that gets used by
default for all replications.

2. Take a look at the sample code here:

https://github.com/couchbaselabs/TouchDB-Android/wiki/Replication-Without-Credentials-in-the-URL

This works for me, but there is still room for improvement.

marty

[Marty Schoch]

Also, even though this gets them out of the URL, you still have to
store/retrieve them from somewhere. As is noted in this bug, even the
email accounts and passwords on Android are stored in plain text in a
sqlite database:

https://code.google.com/p/android/issues/detail?id=10809

The only reason the issue is marked "released" is that now they
support full-device encryption.

marty

[Che Jami]

I would like to add that given the possibility of a rooted device, you should assume that all files/databases on the device (whether on internal or external storage) can be accessed. You should focus more on encryption, obfuscation and/or obscurity.

[Marty Schoch]

1. The solution I posted yesterday allows you to store a password in
whatever way you deem safe enough for your application. This includes
the option of not storing it at all and prompting the user for it each
time.

2. If you allow for rooted devices, the only solution is to encrypt
data with information that is NOT stored on the phone. Keychain type
APIs encrypt the data with keys stored on phone. You must assume they
are also compromised on a rooted device. This means you means you
are back to prompting the user for some information.

Do you have any specific proposals to improve the security of TouchDB?

marty

[Akash]

Precisely why I brought up the question. Securing the code is an issue which can be solved by the problems u said...but what happens is that the replication URL goes and sits in the sqlite DB as plain text. My question was how to avoid that.

That too in the case of continuous replication. Marty has suggested a method for single replication and I don't know if that's the solution for my problem but that seems to be the only one.

I still am not able to figure out how to not expose the user name password.

(Android touchdb is the env, jus to clarify)

[Marty Schoch]

On Fri, Jun 29, 2012 at 11:45 AM, Akash <aka...@gmail.com> wrote:
> Precisely why I brought up the question. Securing the code is an issue which
> can be solved by the problems u said...but what happens is that the
> replication URL goes and sits in the sqlite DB as plain text. My question
> was how to avoid that.
>
> That too in the case of continuous replication. Marty has suggested a method
> for single replication and I don't know if that's the solution for my
> problem but that seems to be the only one.
>
> I still am not able to figure out how to not expose the user name password.
>
> (Android touchdb is the env, jus to clarify)

The solution described here:

https://github.com/couchbaselabs/TouchDB-Android/wiki/Replication-Without-Credentials-in-the-URL

works for continuous and non-continuous replications. It will also
work for replications you place in the _replicator db (in the future
once its implemented).

The important thing to understand is that every time you start TouchDB
you have to tell it what the credentials are, because using this
approach we do not store them anywhere.

marty

[Jens Alfke]

On Jun 29, 2012, at 5:57 AM, Marty Schoch wrote:

2.  If you allow for rooted devices, the only solution is to encrypt
data with information that is NOT stored on the phone.  Keychain type
APIs encrypt the data with keys stored on phone.

In the case of Apple's keychain implementation (on iOS and Mac) the encryption key is based on the user's password or PIN, so it's not stored on the device.

I've heard that the default 4-digit PINs used on iOS aren't very secure if the device is rooted, because an attacker with sufficient privileges can brute-force the keyspace pretty quickly; but the alternative alphanumeric password is secure.

—Jens

[Marty Schoch]

Ah you are correct, I was looking at outdated information.

So, the closest thing Android has to this is:

http://developer.android.com/reference/android/security/KeyChain.html

It was only introduced in ICS (4.0), and it can't be used for
username/password storage. It can however be used for storing private
keys and certificates. It should be possible to combine this with the
code I've already mentioned to set credentials on underlying HTTPS
connections.

If anyone is interested in exploring this and reporting back that
would be great. (there is an informative blog post with sample code
here: http://nelenkov.blogspot.com/2011/11/using-ics-keychain-api.html)

marty

[Akash]

Thank you :)

[swiftugandan]

I think this http://sqlcipher.net/sqlcipher-for-android/ would address the problem of local database security.

[Akash]

Can one of the main touchdb creators confirm if sqlcipher can be used successfully and integrated as mentioned on the site that is provided?

--
Adrenaline Junkie

[Marty Schoch]

On Sat, Jul 14, 2012 at 8:50 AM, Akash <aka...@gmail.com> wrote:
> Can one of the main touchdb creators confirm if sqlcipher can be used
> successfully and integrated as mentioned on the site that is provided?
>
>
> On Sat, Jul 14, 2012 at 5:04 PM, swiftugandan <pmun...@gmail.com> wrote:
>>
>> I think this http://sqlcipher.net/sqlcipher-for-android/ would address the
>> problem of local database security.

I think this could be offered as an option in the future. But, it
looks like the best way to integrate it would be after we have a more
pluggable storage mechanism. I think this kind of reorganization will
be after 1.0.

marty

[Akash]

Okie :) thank you for letting us know

[Jens Alfke]

On Jul 14, 2012, at 8:50 AM, Akash <aka...@gmail.com> wrote:

Can one of the main touchdb creators confirm if sqlcipher can be used successfully and integrated as mentioned on the site that is provided?

This is issue #1 by the way. (Not in priority, just in order created :)

Feel free to add comments there if you have suggestions or questions.

—Jens