Re: [Freesafe-devel] jFreeSafe backup and restore updates

[Marai L. <at...@at...>]

On Sun, 3 Feb 2008 19:34:55 -0500
"Alex Kotchnev" <ako...@gm...> wrote:

  Hi,

> else, as there is no need to mess around with both server and client
> side : all that the server does is to store and retrieve the encrypted
> data

Yes, I got it.

>    I don't think there is anything there describing your proposed
> authentication scheme. The current setup only does the PBE and sends

Then probably I forgot to check it in, as usual. :)

> the encrypted data to the server. One minor improvement would be to
> include some kind of authentication at the server before accepting a
> backup or retrieving one, as currently any backup files are available
> without authentication (e.g. anyone could potentially pull any backup
> (and attempt a brute force) if the backup server is left up and
> running).

Well, with strong crypto that wouldn't be a problem. As there is the
network between the phone and the server, you can assume that the backup
data will be bruteforced. Period. The easiest would be to use https but
MIDP does not support messing around with the certificates and that would
be needed to prevent man-in-te-middle attacks.

>    These are all good ideas, the question is whether you or I would
> have the time to commit to implementing something more complex. At

I'm willing to work on it, it just seemed to much at once to get the
protocol, the ui and the app logic (storing keys, etc) right at once. Now
you did some of it, so it doesn't look that much anymore :).

> least on my side, I am pretty busy : the only reason that I was able
> to set aside time to add this feature is that I'm changing my phone
> and I needed a good way of moving my data from one phone to the other.

I have to admit, that I was too lazy to do that. I let my data go with my
9500 and now I don't use the app on my 6120. I'm kind of busy too, but as
I became a freelancer in September things have changed a lot. Sometimes
I'm too busy then I usually have free periods. I know I promised that I
would work on it last year, during my sabbatical, but I found that I
wasn't able to achive anything. I needed to have a break.

>     I would urge you to review these changes and make sure that they
> would work for you as well. The stronger crypto would be great;
> however, I would imagine something similar could be accomplished if we
> just require a long enough (and complex enough) password for the PBE

Well, that would be almost as long as a sensible strong key. Another
thing that I thought of for sharing a secret between the mobile and the
server is using an alpanumeric encoding instead of a simple hexadecimal.
It could be just lowercase letters and numbers, then it's 36 symbols.
That's about 5 bits/symbol, which means 26 characters for a 128 bit
random key. That's quite acceptable for occasional bacups I think. 

> solution that is there right now. My point overall is that it would be
> most beneficial to the project to have a working solution for backup
> and restore and having one that is just "good enough" would be better

Sure. I'm susceptible to perfectionism and I always have to remind myself
to go for the good enough solution first.

>     I was also thinking of the possibility of allowing server side
> editing of the "keyring" that is backed up to the server. The idea is

Yes, I had that idea in my mind when I started this backup thingy (if I
can say that I started it at all). I wanted to have a PC application and
I still want to have it very much as the one I use is a piece of crap.
There is a java version of PasswordSafe but unfortunately that is also
very lame UI wise. It's a shame, because I liked the original windows
version a lot. But the PC UI is not a problem, I'll be happy to do it
once I released the initial backup functionality.

> that it is often cumbersome to have to do data input on the device
> (e.g. unless you have a qwerty type device), and it would be VERY
> beneficial to be able to drop a backup to the server, edit it, and
> restore it back to the device with the updated values.

There would be an even better solution that I did a prototype of for my
previous employer. I'm quite sorry that I didn't come up with the idea or
that we didn't publish it. I might ask my ex-boss how acceptable it would
be for me to do that.

>     One  other problem that I became acutely aware of is how sensitive
> the application is to changes in the field layout of the stored
> records because they are stored in a binary format. The problem was

Yepp. I always wanted to create a generic Entry type with autogenerated
Forms. Using that would eliminate this problem as well. However it's not
completely trivial in the MIDP environment as we don't have reflection
and using Hashtables in each entry would probably waste a lot of memory.
But this could be profiled.

>    Finally, I'm not sure what you use for your development, but if
> attracting other developers is any kind of priority or interest to
> you, the current setup with a plain ant build is not very developer
> friendly : e.g. it works well to produce the build artifacts, but if
> you want to try to do anything more than that (e.g. debug the app,
> server or client side) it is not very friendly. I'm a big fan of

I'm also on NetBeans. The Mobility Pack is quite cool but it wasn't there
in 2002 when I started the project and I always wanted the project
to remain IDE agnostic exactly because I thought of other developers who
might use a different environment. I know it wasn't worth it since it's a
very small project.

> whole bunch of other things. I think it would be extremely useful to
> have something like this committed into the repository so that if a
> new user wants to tweak the app they can get a quick start in no time.

The debugging should work, as there is a linux shell script that starts
the application in the emulator with debugging enabled. You just have to
attach the debugger. I know it's one step more than from the IDE but it
works for the Eclipse guys too. However, I'll review what I could do
about it.

I started to use the Mercurial VCS lately and I like it a lot and I'm
planning to move the whole project under it. I think I'll keep the
sourceforge repository as well and push the changes there from time to
time but I'll use Mercurial locally and to work with the contributors
(well, that's you :) ). BTW it has a very nice NetBeans support. It
allows you to do the commits locally and then other developers can pull
the changes from you to their repository. Would you mind start using
that? I can publish a URL where you could pull the latest revision from
after integrating your patch and from then on you could use it.

  Laszlo