Encryption method for PasswordInput datatype

[GoogleCodeExporter]

PasswordInput is a datatype to store user's password input. It has a UI that 
mask user input, and 
persist the input string. 

PasswordInput should have some encryption feature so that the plain text are 
protected when it is 
stored into the database. 

Since the password needs to be retrieved and used for certain services, (like 
Sending Gmail) so 
simple hash algorithms are not feasible, both encrypt/decrypt methods needs to 
be provided. 

Original issue reported on code.google.com by EHo...@gmail.com on 16 Dec 2009 at 2:52

[GoogleCodeExporter]

Start to take a look at this issue.

Original comment by renc...@gmail.com on 26 May 2010 at 12:16

[GoogleCodeExporter]

Here are some of the approach I have considered so far for this problem. 
Approach 1 & 
2 also includes some sample source code that shows how I would implement them. 
Note 
that these codes covers only the twitter action and as of r699, gmail actions 
also 
use passwords.

1. Encrypt passwords stored in DB. (please refer to cipher directory)
To make it simple, the following invariant must be followed - password string 
in the 
action class is always encrypted. As long as this invariant is followed, there 
shouldn't be a case were a password becomes irrecoverable because it was 
encrypted or 
decrypted twice in a row.

The problem I see with this approach is that we need an encryption mechanism 
where 
the cipher text is recoverable, otherwise, we wouldn't be able to extract the 
original password and pass it to jtwitter. I think this is a  problem because 
if we 
can recover the password, then others can do it too. To make things worse, our 
code 
is open source so the method on how to decrypt the password is available to the 
public. 

2. Use OAuth. (please refer to oauth directory)

Almost the same problem as approach 1. Since we need to store the token, it 
should be 
placed somewhere that it can't be compromised. This may be actually worse than 
approach 1, because the user can change the password if the password is 
compromised, 
but I don't think the user can invalidate the OAuth access token.

3. Use Android's AccountManager.

This approach has not yet been fully studied, but it requires API level of at 
least 
5. Sample use can be seen on android documentation online:
http://developer.android.com/resources/samples/SampleSyncAdapter/index.html

The source is also available on the android SDK under the directory:
samples/android-x/SampleSyncAdapter

note that x is a number, in my computer, both android-7 and android-8 had this 
directory.

Related discussion can also be found on:
http://groups.google.com/group/omnidroid-devel/browse_thread/thread/dab55b1d6967
a6ac

Attached file contains sample codes.

Original comment by renc...@gmail.com on 1 Jun 2010 at 6:31

Attachments:

• issue47.tgz

[GoogleCodeExporter]

Current status: on hold.
Reason: AccountManager looks promising and we want to use it, but it requires a 
higher 
API level, which could potentially leave out old android users. So this has 
been put on 
hold for the moment.

Original comment by renc...@gmail.com on 2 Jun 2010 at 12:20

[GoogleCodeExporter]

Original comment by case.and...@gmail.com on 2 Jun 2010 at 2:18

• Added labels: Security

[GoogleCodeExporter]

One approach I can think of is to use PBE (Password based encryption). It is 
basically an encryption scheme where a password will be used in the 
cryptographic process. The idea is to ask the user for a master password that 
will be used in PBE. The downside is since we can't store the master password 
in the DB for security reasons, we need to ask the master password from the 
user every time the phone boots which can ruin the user experience. 
Alternatively, we can also provide the user with the option of storing the 
password less securely for convenience...

Original comment by renc...@gmail.com on 22 Jun 2010 at 3:52

[GoogleCodeExporter]

Original comment by case.and...@gmail.com on 6 Jul 2010 at 2:22

[GoogleCodeExporter]

I have taken a deeper look at the AccountManager and we can definitely use it. 
But are we really not going to address this security concern till the next 
release? I am also planning to have this released together with issue 89 since 
changes in both of them would require users to setup their account again. And 
having them in one release would only require the users to do the adjustment 
once.

Original comment by renc...@gmail.com on 15 Jul 2010 at 4:09

[GoogleCodeExporter]

If you're not planning to use the AccountManager, then I don't see any reason 
why this can't be applied before the initial release.

Original comment by case.and...@gmail.com on 15 Jul 2010 at 4:50

[GoogleCodeExporter]

Since using AccountManager or not is going to greatly affect the code I want to 
hear about your opinion on this. I have listed some of the points about 
AccountManager:

AccountManager pros:
1. Does not need another table to support multiple accounts.
2. Integrated solution with the Android system.

cons:
1. Needs at least API level 5.
2. We are trusting Google is doing a good job in keeping the user credentials 
secure.

In house cons:
1. As stated in the issue, I couldn't think of any way of having a truly secure 
solution but it can deter potential attackers.
2. Need separate table if we need to add multi-account support for each 
application.

Original comment by renc...@gmail.com on 15 Jul 2010 at 5:49

[GoogleCodeExporter]

I said my peace (no one replied) in :
https://groups.google.com/group/omnidroid-devel/browse_thread/thread/46841a21232
fa7f1

[start re-post]

Application Account Management
-------------------
Randolph brings about the point about application account management
again in Issue99.  It begs the question of whether we want to build
out a more robust account management system inside our application or
possibly integrate with the Android-5 AccountManager.  I don't think
there is really much to be gained by staying with an outdated API
level in a fast changing mobile market.  If upgrading to a higher
version will provide us with critical functionality that we want to
take advantage of we probably want to migrate as soon as possible.  By
as soon as possible though I think I'm thinking after the 1.0
Milestone has been reached.  The question continues to remain as to
how much functionality the android-5 AccountManager will buy us.  With
how tightly we'll want to integrate account configuration with
Omnidroid would leveraging it be a substantial benefit?  If we can't
integrate well with it, or it doesn't provide the functionality we
want or need, then we probably want to build this out ourselves.  If
it would provide a great benefit, then I think we should slate the
better backend support of account management as a post 1.0 Milestone.
So here's my current 2.0 proposal:

2.0 Release Milestone Strategy
-------------------
Omnidroid 2.0 main feature advancements:
  - Integration with remaining standard set of apps
(Calendar/Email/Music/Contacts/etc.)
  - Enhanced Account Management

Proposal if an Android-5 AccountManager is the way to go:
 - Omnidroid 1.0 compatible with Android-4+ (1st generation) devices.
 - Omnidroid 2.0 compatible with Android-5+ (2nd gen) devices.

Proposal if an in-house AccountManager is the way to go:
 - Omnidroid 1.0 compatible with Android-4+ (1st generation) devices.
 - Omnidroid 2.0 compatible with Android-4+ (1st & 2nd gen) devices. 

[/end-repost]

I read this interesting blog post about supporting older platforms that doesn't 
sound too bad:
http://android-developers.blogspot.com/2010/07/how-to-have-your-cupcake-and-eat-
it-too.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+blogspot%
2FhsDu+%28Android+Developers+Blog%29&utm_content=Google+Reader

If we provide the API-4 support in-house, but use AccountManager in future, we 
can wrap it with some generic and continue to support the API-4 version.

Thoughts?

Original comment by case.and...@gmail.com on 15 Jul 2010 at 6:07

[GoogleCodeExporter]

interesting, I've heard this somewhere before, assuming you speak decent 
english, i wonder why "said my peace" not "said my piece"?

Original comment by sv767%ny...@gtempaccount.com on 15 Jul 2010 at 6:31

[GoogleCodeExporter]

lots of typing, little proofreading

Original comment by case.and...@gmail.com on 15 Jul 2010 at 7:34