Allow sharing/importing/exporting of databases

[GoogleCodeExporter]

Some people want to use their existing PasswordSafe databases.  There
should be a way to import/export databases and possibly, more generally,
share databases (eg store them on a server from which any PasswordSafe
client may access them).

Sharing will likely reduce security minutely so it should be an option for
users rather than a default.

Original issue reported on code.google.com by noel....@gmail.com on 13 Nov 2008 at 6:00

[GoogleCodeExporter]

There may be crypto export restrictions (eg encrypted communication) related to 
implementing this feature so I'm lowering it's priority.

Original comment by noel....@gmail.com on 17 Nov 2008 at 6:45

• Added labels: Priority-Low
• Removed labels: Priority-Medium

[GoogleCodeExporter]

How about just letting the user open & save to a .psafe3 file on the sdcard?

Original comment by cpi...@gmail.com on 28 Jan 2009 at 9:38

[GoogleCodeExporter]

This would be a very good first step, but since the sdcard isn't protected in 
any
way, any app can steal that information.  The user needs to be very aware of 
this
trade-off.

It's been suggested that a future version should split the file into two; the 
part
that contains the salt will remain on the phone (with some way to copy it 
manually)
while the rest can be placed somewhere in the cloud.  Doing this will allow 
automatic
sync'ing of the database while maintaining its security.

Original comment by noel....@gmail.com on 28 Jan 2009 at 11:25

[GoogleCodeExporter]

Original comment by noel....@gmail.com on 1 Feb 2009 at 1:47

• Added labels: Priority-Medium
• Removed labels: Priority-Low

[GoogleCodeExporter]

Several people have asked for this feature.

Original comment by noel....@gmail.com on 2 Feb 2009 at 4:54

• Added labels: Priority-High
• Removed labels: Priority-Medium

[GoogleCodeExporter]

Sure, its important to be aware of that, but you face the same issue with all 
other
.psafe3 compatible apps such as Password Safe on windows, or Password Gorilla on
Mac/Linux

Original comment by cpi...@gmail.com on 2 Feb 2009 at 10:32

[GoogleCodeExporter]

This is true.

Another issue is that the sdcard can be popped out and copied.  In this 
respect, it
is as secure as a floppy disk or usb drive.  As such, the import feature should
remove the original file once it's been copied.

I'm not arguing that this feature shouldn't be done.  I should've said before 
that
the user must be made aware of the trade-offs (eg as some sort of warning) 
rather
than implying it's up to the user to know without any assistance from the app.

Original comment by noel....@gmail.com on 3 Feb 2009 at 12:18

[GoogleCodeExporter]

If the app is secure and correct, then I can embed my psafe3 file in my sig and 
not worry about it being 
broken.   If this app is to have any real success, it needs to be able to read 
the psafe3 format and display 
it.

Original comment by christopher.wanko on 5 Feb 2009 at 7:43

[GoogleCodeExporter]

I'm working on allowing psafe3 files to be imported and exported.

It's true that the files are difficult to attack.  It would be even more 
difficult
for them to be attacked if they can't be read off the sdcard by default.  For
example, if the database were on the sdcard and an attacker copied it, they 
have all
the time in the world, along with any computer resources they may have, to brute
force the password.

I've also created a separate issue item to address splitting the file so it may 
be
transmitted via separate channels forcing the attacker to have to eavesdrop on 
both
channels to gain access to the full file.

Original comment by noel....@gmail.com on 6 Feb 2009 at 1:43

[GoogleCodeExporter]

I don't think your concern about access to the sdcard copy of the file is 
warranted.
 First of all, access is predicated on someone getting your phone, which is likely
rare.  After getting your phone, the unauthorized individual has to recognize 
the
application and meaning of a psafe3 file, even more rare.  Third, that 
individual
also has to have at his or her disposal the means to brute-force an 
AES-encrypted
file, which has never been accomplished and likely will not in a single person's
lifetime.

So what I'm saying is this: if your first priority is to be able to read an 
arbitrary
 psafe3 file, given the correct passcode, then you will have developed a meaningful,
useful solution for existing Password Safe users with Android devices.  Nothing 
else
in your development timeline matters right now.

Where I'm coming from: 15 years of professional s/w development on mobile 
devices,
mainframes, midrange computers, and desktops using all sorts of operating 
systems.  I
know a little about how s/w gets built, and my friendly advice is to attack the 
file
reading problem first.  And I would love to help.

-C

Original comment by christopher.wanko on 6 Feb 2009 at 3:36

[GoogleCodeExporter]

Yes, importing and exporting of psafe3 files is taking a much higher priority 
than
splitting the file.

Help would be /much/ appreciated.  Let me know so we can coordinate.

Just a FYI, the Android coding style is being used.  If you spot any violations,
please let me know or fix them yourself.  Code reviews should also be done.  
I'm also
working on making the code more testable (and writing automated tests for it).

Thanks,
Noel

Original comment by noel....@gmail.com on 6 Feb 2009 at 4:05

[GoogleCodeExporter]

The only real purpose of the Android port for me would be to use the password 
safes I
currently use at work and at home.  Having my passwords with me all the time 
would be
sweet!  The simplest, for me, would to have a safe readable from the sdcard and 
then
I could pop it on via a USB connection.  When I saw that it couldn't read an 
existing
safe, I uninstalled it from my phone.

Original comment by ed.wi...@merrillcorp.com on 7 Feb 2009 at 5:23

[GoogleCodeExporter]

I've enlisted a colleague to help, he has more Java experience than I do -- I'm 
a
COBOL/ C/ SQL/ UNIX/ ksh guy.  We want to coordinate with you on this particular
issue, specifically what you've identified as blocker(s) preventing us from 
reading
in an arbitrary psafe3 file and displaying its contents.

-C

Original comment by christopher.wanko on 12 Feb 2009 at 4:19

[GoogleCodeExporter]

I'm also glad to help. My time will be limited in the coming weeks (having twins
soon!), but I'm going to go ahead and get the code and familiarize myself with 
it.
I'm a Java coder (and architect) since '96. Be glad to help in any way that I 
can.

Original comment by online%r...@gtempaccount.com on 23 Feb 2009 at 9:36

[GoogleCodeExporter]

Just an update status:  The app no longer crashes upon trying to open a database
created from another client.  All that's needed now are the actual import/export
functionalities.

Original comment by noel....@gmail.com on 26 Feb 2009 at 11:12

[GoogleCodeExporter]

why import/export? the real power of this apps can be to read the same file as 
used on 
linux/windows _without_ converting/exporting/importing. if i edit anything in 
the pws 
file i can simple copy back to linux and use it there again. the sdcard is 
exactly as 
secure as the phone itself. so it's not a valid reason at all.

Original comment by vitorl...@gmail.com on 28 Apr 2010 at 9:21

[GoogleCodeExporter]

The project is dead, Vito.

Original comment by christopher.wanko on 29 Apr 2010 at 1:45

[GoogleCodeExporter]

why do you say this project is dead?

Original comment by mstave...@gmail.com on 1 May 2010 at 8:24

[GoogleCodeExporter]

I'm giving this a try instead:  http://sourceforge.net/projects/passwdsafe/

Original comment by mstu...@gmail.com on 12 Aug 2010 at 7:46

[GoogleCodeExporter]

Chris, sorry for reactivating this old thread, but I've noticed a significant 
misconception on your part:

"individual also has to have at his or her disposal the means to brute-force an 
AES-encrypted file, which has never been accomplished"

You have probably confused brute forcing the AES *key* (which is indeed 
unlikely to happen in the foreseeable future) and brute forcing the user's 
passphrase from which the key is derived.

User's passphrases are typically much weaker with regards to actual entropy 
contained and are quite easy to brute force.

For example, suppose that you use lower, upper case, numericals and 2 distinct 
special characters in your passphrase. The character set used for your 
passphrase thus is 64 in size.

Suppose that you use a secure random passphrase generator for generating your 
passphrase (instead of making it up using your brain, which is somewhat 
predictable). 

This gives you effectively lg(64) = 6bits of entropy per character when 
building your passphrase.

To make full use of the key strength of the *smallest* possible AES variant 
(AES128), you'd need 128 bits of entropy in your passphrase.

So you'd have to generate a passphrase that has a length of at least 22 
characters (and completely random characters, for that matter, otherwise its 
entropy wouldn't be sufficient).

Do you really think that most (if any) users of the application would work with 
such a long 
passphrase? I have every reason to believe that they'd rather choose something 
much shorter and possibly less random, making it easily breakable.

This is true especially on mobile devices, where typing requires more effort, 
users will tend to chose simpler passphrases.

So I think that a feature that makes extracting the psafe3 file harder might 
really be of some use here, provided that it's optional and set through 
preferences.

Original comment by aleksand...@gmail.com on 3 Jan 2011 at 3:32

[GoogleCodeExporter]

It's not a misconception so much as an improper wording of the same basic 
problem: if you don't know how long my passphrase is, you have to check by 
brute-force (or rainbow table lookup) every possible input.

All I need is enough salt to invalidate the rainbow table option and we're back 
to brute force.  You're not getting into a psafe3 file in human lifetimes 
without a sidechannel attack or social engineering.

Original comment by christopher.wanko on 3 Jan 2011 at 5:26