Open GoogleCodeExporter opened 9 years ago
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
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
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
Original comment by noel....@gmail.com
on 1 Feb 2009 at 1:47
Several people have asked for this feature.
Original comment by noel....@gmail.com
on 2 Feb 2009 at 4:54
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
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
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
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
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
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
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
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
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
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
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
The project is dead, Vito.
Original comment by christopher.wanko
on 29 Apr 2010 at 1:45
why do you say this project is dead?
Original comment by mstave...@gmail.com
on 1 May 2010 at 8:24
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
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
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
Original issue reported on code.google.com by
noel....@gmail.com
on 13 Nov 2008 at 6:00