
Bluepass: an open trust no one password manager (fundraising) - antirez
https://bluepass.org/
======
geertj
Author here. Happy to answer any questions :)

~~~
616c
As someone who is a big supporter of Firefox Sync [0]:

What will this provide me over Firefox Sync, which has a built in encryption
layer on their (admittedly cloud) service? I can pull their code and host my
own Firefox sync server, and someone has written a special PHP-based version
for inclusion into OwnCloud. So, what is so special here except the use of
buzzword P2P? (See next question below.)

How will you do to P2P without some kind of centralized bootstrapping service
with the prevalence of NAT and people who do not know how to port-forward? (I
just saw the Github repos, so I will examine this myself in a bit.)

UPDATE: It would appear you are using mDNS and/or Zeroconf [1] to handle this?
I am still not sure how this will ease the NAT and/or syncing over public
Internet.

Why should I trust you? What have you done other than this project? Not to be
increasingly blunt, but you are not the Mozilla Foundation and your Github
repos do not show much other than work on co-routines and AD service wrappers.
That is useful to me, but I would like to see more security work and knowledge
of crypto libraries if I trust you with password manager code. What else do
you work on? Your blog does not show me too much, and I cannot find much
mention of you to warrant 60,000 USD for such a project. I am correct in
seeing you a Marketing/Product Manager? Sorry to be harsh, but honestly I
think most of HN would be worried about these points.

UPDATE: Ok, maybe I was a little too harsh; you do seem to have some more
experience than I had previously estimated, given some Googling and your
Linkedin profile, if legit. [2]

[0]
[http://docs.services.mozilla.com/sync/](http://docs.services.mozilla.com/sync/)
[1]
[https://github.com/geertj/bluepass/blob/master/bluepass/loca...](https://github.com/geertj/bluepass/blob/master/bluepass/locator.py)
[2] it.linkedin.com/in/geertj

~~~
geertj
Heh, well thanks for the honesty :)

> How will you do to P2P without some kind of centralized bootstrapping
> service with the prevalence of NAT and people who do not know how to port-
> forward? (I just saw the Github repos, so I will examine this myself in a
> bit.)

The P2P is done over local networks only. It uses multicast DNS for service
discovery. Bluepass syncs between your own devices only. As long as the
devices occasionally share a (W)LAN, it will work.

> Why should I trust you? What have you done other than this project? Not to
> be increasingly blunt, but you are not the Mozilla Foundation and your
> Github repos do not show much other than work on co-routines and AD service
> wrappers. That is useful to me, but I would like to see more security work
> and knowledge of crypto libraries if I trust you with password manager code.

Well, everybody has to start somewhere. I do believe that I have enough
experience with crypto to be qualified here. I've got a physics degree and did
a lot of maths. And I read Schneier and Wenbo Mao's book cover to cover. Also
note that I'm not using any proprietary algorithms. This is all OpenSSL
wrapped algo's that I'm using from Python.

But in the end, what should give this the right credibility is that the source
code is up on Github, together with my intention to grow a community that can
review the crypto. If there is something not right, which can always happen of
course, then it will get out sooner or later.

> What else do you work on? Your blog does not show me too much, and I cannot
> find much mention of you to warrant 60,000 USD for such a project. I am
> correct in seeing you a Marketing/Product Manager? Sorry to be harsh, but
> honestly I think most of HN would be worried about these points.

This is not related to my day job. I would say have a look at the code, and
decide for yourself if you like the code. I don't think being a product
marketing manager in the day is mutually exclusive with being able to write
good code.

The calculation of the funds is rather straightforward: $10k for each of the
platforms that need work: iOS, Android, Chrome, FF, Mac and Windows.

~~~
drbawb
>As long as the devices occasionally share a (W)LAN, it will work.

How about a VPN? I have a work laptop that is rarely (if ever) connected to my
home network directly. -- However it is connected to my home network through a
VPN daily.

~~~
geertj
It depends on how the VPN is setup... Multicast DNS will work if you are in
the same L2 domain. Otherwise, a different solution is needed. For example, if
you have a smartphone that you bring with you to the office, and that is
connected to your office Wifi network and your home Wifi network, then
synchronization would still work through your smartphone. Otherwise, a cloud-
based "reflector" is needed. See the other comment about that.

~~~
616c
And to apologize: re the reflector, I assumed you were doing this, like
BitSync, and that is why I question ed you in my first comment. I am glad you
do not over-promise with tyour project. Good work.

------
tigerweeds
this is exactly what I've been looking for. I was thinking of using a small
truecrypt container with btsync but it wouldn't work well due to container
size being always the same, sync being possible only after unmounting the TC
container and so on.

~~~
antirez
I'm currently using a truecrypt tiny volume inside Dropbox, works but it is
not really ideal. Conflicts resolution and a very long password to remember
for the volume, that's the only way I can protect the data when it is synched
on the Dropbox servers.

~~~
geertj
Exactly. By default Bluepass uses a long password as well to protect the local
database. However, you can opt to choose a shorter password, or no password at
all. In this case you are still protected by:

* The physical security of your device. Unless someone gets access to your device, you are safe.

* The fact that the sync traffic goes over your local network only.

* Even if someone managed to sniff your local traffic, all synchronization requests are encrypted by each node's unique 2048-bit RSA key. No dictionary attack is possible - you'd have to break RSA.

------
jpalomaki
One interesting option would be to bring this kind of P2P syncing to KeePass.
This would benefit from all the features that are already build into KeePass.

~~~
reedlaw
IMHO KeePass is in need of a reboot. First, it's very confusing which version
to use. KeePass 1.x (Classic), KeePass 2.x (Professional), or KeePassX
(originally KeePass/L for Linux?). When I first tried them out, I settled on
KeePass2 because it supported filling out browser forms in Linux. But it's a
mono app with an ugly interface. With no built-in syncing support and no good
syncing plugins either.

I hope this project can become a suitable replacement.

------
Rygu
I use 1Password with Dropbox. Can someone tell me whether I'm at risk, and
should donate to this project?

~~~
geertj
You are at risk of a dictionary attack on your password / passphrase. You need
protect it with a long, computer generated passphrase to be secure. I would
say at least 128 bits of entropy. By being stored on Dropbox, you have to
assume that the the "agencies" have access to your database. At some point,
computing will advance enough to either brute force the encryption or find a
weakness in it.

The safest option is to prevent 3rd parties from having access to your
encrypted data in the first place. This is the approach Bluepass is taking.

~~~
jpalomaki
The entropy problem you can go around with by encrypting the data with a
combination of pass phrase and a token file. For example KeePass supports
these kind of combinations.

Obviously the token file would be something you don't put into cloud but
instead store on each physical device.

------
leke
> It combines broad platform support, peer-to-peer synchronization over local
> networks (never using the cloud)...

My god, the NSA has managed to turn "The Cloud" into a dirty word.

~~~
reedlaw
Then I owe the NSA gratitude because I've been long wishing that there was
more focus in the hacker community on building distributed systems as
alternatives to data silos like Facebook and Google.

