Use public storage like google drive or dropbox to sync padlock about padloc HOT 10 CLOSED

Thats a very good question! Using third-party storage integrations for syncing is definitely something we've evaluated on multiple occasions and while it seems like the simpler approach at first glance, it comes with its own problems and challenges:

• If you support one major service, you kind of have to support them all. That means you have to write integrations for at least four different apis (Dropbox, Google Drive, iCloud, One Drive). In addition to that integrating some of these services might require native components, meaning you'll need to write at least some platform-specific code.
• All of these services use different flavours of oauth. Authenticating with any of them can be tedious and sometimes quite complicated and the lack of a backend layer doesn't make the task easier.
• Any of the apis can (and will) change under your feet at any time, meaning you'll be patching your integration layers constantly in order to keep it working
• Even if you add support for every of the major services, there is not guarantee that any given user has an account at with any of them or is comfortable using them to store sensitive data

And finally, the most important reason:

None of these are open source. Even though users tend to put more trust into big companies like Google or Apple, their services are ultimately a black boxes. A big part of the Padlocks philosophy is transparency and full transparency requires the entire stack to be open source.

I could go on, but then I wouldn't get any work done today ;) I hope this gives at least some insight into why we decided to take a different approach and write our own cloud storage layer. Let me know if you need any more clarification!

from padloc.

MaKleSoft - I think that you want people to use Padlock Cloud, because you want to make money while developing open-source software, which is perfectly understandable... but unfortunately, that means you have no interest in making it easy for your users to use third-party cloud service providers. And so, you're trying to rationalize following your self-interest by saying that it would simply be impractical to offer third-party services, even when that's clearly not true at all.

I currently use KeePass. KeePass is open-source, and it lets me sync my data between devices using Dropbox, or Google Cloud, or iCloud, or One Drive, or SyncThing, any other cloud service provider, or git, or sneakernet, or in fact any method I can imagine. It does not have "integrations for at least four different apis," it does not know anything about oauth, and it is perfectly resilient to any of these services changing their API. And my data is guaranteed to be perfectly safe, even when I'm syncing it through an untrusted, black-box, closed-source service.

How is this magic achieved? KeePass simply stores its database in a file on my computer, and lets me choose where to save it. Personally, I save it to my Dropbox folder, and it gets synced for me with zero effort.

Keep in mind, I don't trust Dropbox much. But I don't have to, because even if someone gets at my data there, they can't access my password database without my master password! To get my passwords, someone would have to compromise KeePass and Dropbox - two totally unrelated services - at once.

So, while it's great that Padlock Cloud is open-source, it's also the world's largest, most obvious target for hackers - it's specifically and deliberately a database of all the passwords for as many different people as possible! I'd much rather my passwords be in an anonymous file in an anonymous account on some random third-party file syncing service, whose security is totally orthogonal to the security of my password database.

That's why any password database that truly cares about user security should allow the user to choose a third-party syncing service.

Right now, I'm looking for a password database with these features, in order of importance:

1. Sync using any third-party file-syncing service, like Dropbox.
2. Strong cross-platform support.
3. Strong browser integration.

KeePass has #1, but fails on #2 and #3. Padlock (like basically everything else out there) fails on point #1, which is most important to me.

So please, re-open this issue! I, for one, would gladly pay generously for a modern open-source password manager that gave me control over the storage of my own data, and didn't require me to run my own server.

from padloc.

I currently tend to think of my password database as read-only on my mobile device.

How do you get the data on your phone though? In any case, I'm afraid most users won't settle for that. In fact, many users use Padlock exclusively on mobile devices so having full synchronisation support there is important.

It looks to me like the Padlock Cloud web interface doesn't allow access to my data, which does make it more secure than some competing services, where the encrypted data and the javascript code to decrypt it both come from the same server.

This would be a fundamental design flaw and any company doing this should not be trusted with any kind of sensitive data. Padlock Cloud only acts as a zero-knowledge web storage service and does not handle any crypto at all. All code handling your master password or plain-text data is deployed solely via standalone, code-signed packages.

from padloc.

Always someone could make a fork and implemented feature that allows to select where database file could be stored ;)

from padloc.

@praxiq - enpass satisfies your requirements, but unfortunately it's not an open source

from padloc.

@realsimon yeah, I previously dismissed enpass due to closed source... although looking now, they claim their database file format is simply a sqlcipher-encrypted sqlite database, so at least it's an open format. I could extract my data using open-source, third-party tools if I needed to. Though closed-source, it actually seems to give me more freedom and control over my data than Padlock does.

Eh... I'll probably stick with the ugly-but-effective keepass for now, and continue to browse for new alternatives a couple of times a year :)

from padloc.

MaKleSoft - I think that you want people to use Padlock Cloud, because you want to make money while developing open-source software, which is perfectly understandable... but unfortunately, that means you have no interest in making it easy for your users to use third-party cloud service providers. And so, you're trying to rationalize following your self-interest by saying that it would simply be impractical to offer third-party services, even when that's clearly not true at all.

I understand how you could come to that conclusion, but while it is true that the official Padlock Cloud service is currently the only revenue stream supporting the development of Padlock, making money is certainly not the main motivation behind it. The idea behind Padlock Cloud was to provide a seamless, simple and unified user experience across all platforms. By focusing on a single method of synchronisation, we were hoping to provide the best possible user experience while minimising complexity and maintenance effort. It's not so much that integrating third-party services would be impractical - I'm just not convinced (yet) that it's worth the additional effort.

How is this magic achieved? KeePass simply stores its database in a file on my computer, and lets me choose where to save it. Personally, I save it to my Dropbox folder, and it gets synced for me with zero effort.

This works for desktop, but unfortunately on mobile it's not quite that simple. The good news is that you'll actually be able to do this very soon - adding the option to select the database file location on the desktop is in our backlog and will likely come in v2.5 or v2.6. You can follow the progress here: https://github.com/MaKleSoft/padlock/issues/106

Keep in mind, I don't trust Dropbox much. But I don't have to, because even if someone gets at my data there, they can't access my password database without my master password!

The same is true for Padlock Cloud, no?

So, while it's great that Padlock Cloud is open-source, it's also the world's largest, most obvious target for hackers - it's specifically and deliberately a database of all the passwords for as many different people as possible! I'd much rather my passwords be in an anonymous file in an anonymous account on some random third-party file syncing service, whose security is totally orthogonal to the security of my password database.

That's why any password database that truly cares about user security should allow the user to choose a third-party syncing service.

Have you looked into running your own Padlock Cloud instance? A lot of people are already doing this and we're looking into making it even easier to do this in the feature.

So please, re-open this issue! I, for one, would gladly pay generously for a modern open-source password manager that gave me control over the storage of my own data, and didn't require me to run my own server.

I'm definitely open to keep the discussion going, so sure, let's re-open this!

from padloc.

Very well, I stand corrected! I had assumed that your need to make money for all this work was leading you to build rationalizations for ultimately poor design choices - it's a pattern I've seen before, but I apologize for reading that into this decision.

This works for desktop, but unfortunately on mobile it's not quite that simple.

You can say that again. Accessing my KeePass data on mobile is definitely inconvenient, but it's an inconvenience I'd put up with in exchange for the other advantages I listed. I currently tend to think of my password database as read-only on my mobile device. (I don't currently have my own always-on server, so running my own instance of Padlock Cloud is unlikely.)

I don't trust Dropbox much. But I don't have to, because even if someone gets at my data there, they can't access my password database without my master password!

The same is true for Padlock Cloud, no?

It looks to me like the Padlock Cloud web interface doesn't allow access to my data, which does make it more secure than some competing services, where the encrypted data and the javascript code to decrypt it both come from the same server.

Still, the fact that they're both built and run largely by the same team (I assume) makes me worry that someone who compromises one is halfway to compromising the other, especially if it's an inside job. I'll readily acknowledge, though, that I'm being a little paranoid :)

from padloc.

@praxiq https://github.com/MaKleSoft/padlock/pull/159 Adds the ability to customise the database file location but I'm not convinced that simply dropping the file in a Dropbox folder will work without any hickups. If you want to try it, feel free to do so on your own risk ;) (This is not in any release yet, so you'll have to build it yourself)

from padloc.

@praxiq This is now also in the latest beta release (2.5.0-beta.1) in case you want to test it.

from padloc.