[feature request] Open database from URL

[swimlappy]

Hello,

The current version of KeePass 2.36 allows you to open a database from a URL, provided you give a username and password to authenticate. This would be a great feature to add to KeePassXC, as it allows you to centralize the database on a web server of your choice that you have total control over.

Thanks for the great piece of software!

[droidmonkey]

This seems ripe for attacks...

[swimlappy]

That's a possibility yes. Not any less risky than hosting it on Dropbox or Drive. However, again they do provide for passing in credentials. They also allow opening a database from an FTP or WEBDAV server as well. Might even be nice to support SFTP for that too.

[droidmonkey]

Oh i see you mean from the file open dialog (or lack thereof).

[phoerious]

The thing with opening from an external URL is that it is rather easy to get people to open links pointing to malicious databases (not as easy with Dropbox etc.). While we hope we have no exploitable vulnerabilities in our code, this might be an additional attack vector we should at least take into consideration.

[ccoenen]

In case of HTTP: I don't get why KeePass has to do the download? If you set your system up to open kdbx files, then opening a link in a browser (and having the browser set to directly "open" files for this file type) will be indistinguishable for this use case.

Going through the browser has the added benefit of a well proven platform that already known a great number of specialties for HTTP. I doubt KeePassXC could or should implement it on a similar level of detail. Sure, HTTP GET is simple, but how about Cache, Redirects, Cookies, Etags, Simple Authentication, TLS Client Certificates, HSTS, HPKP... You get all of that for free in a browser.

In case of WebDAV: any operating system I know knows how to mount WebDAV. No Need to have this duplicated inside KeePassXC.

In case of SFTP or FTP: mostly the same as WebDAV, this may require additional software, but Again I don't see why KeePassXC should bother implementing that.

[vancwo]

I was going to leave a comment about how this feature (or lack of) was the only reason I continue to use KeePass on Windows instead of KeePassXC. However, @ccoenen 's comment about how most OS's can mount WebDAV led me to mounting my web server's keepass folder instead and using that.

I agree that it's generally best practice to use pre-provided solutions rather than inventing your own. However, sometimes even to technical people it's not always obvious, and you want that functionality built in. I think that this suggestion has merit, and should be considered for the future. If you don't want to go as far as implementing it in the code, supplying users information on possible ways to mount remote Keepass databases would still help a lot.

[droidmonkey]

This should be fixed with documentation. @ccoenen hit the nail on the head.

[jafarre-bi]

Hello,

Maybe I am not aware of all that can be done with SFTP, but I do not see how to do with KeePassXC what I did with KeePass2 (and also the reason why I still keep it installed).

My use case is:

• I have a shared database in an SSH server. This database is shared between several people.
• I have a local copy in my computer.
• I work on my local copy and synchronize changes with the remote DB using SFTP with the synchronization functionality of KeePass2 (changes go both to and from the remote database).

Anyway, synchronization does not seem to be fully implemented in KeePassXC (only merge from, but not bidirectional)...

Any suggestions on how to implement my use case with KeePassXC?

Thank you!

[droidmonkey]

This is not possible from within KeePassXC at this time. You may be able to mount the SFTP session and then sync will occur naturally. We already have an open issue to "sync to a separate file" planned for a future release.

[dead10ck]

@ccoenen @droidmonkey firstly, I appreciate your work on Keepass DX. As a developer that has little free time to contribute to open source projects, I truly appreciate the work that goes into it.

However, I respectfully disagree with the decision to avoid integrating synchronization. I disagree with the idea that opening links with a web browser is "free." It may be free from a development perspective, but certainly not from a user perspective. By abstaining from synchronization, the onus just passes to the user. Sure, you can download your database from a web browser, but what about when you make changes? With this workflow, keeping your passwords synced across all your devices is totally manual.

You can suggest users keep their database synchronized with a tool like Dropbox or Syncthing, but if you don't already use these tools for other files, then setting it up and then running an always-on service on your laptop and your phone just to sync a single file is a huge hammer for a tiny nail.

If we want people to choose KeePass over services like LastPass, it needs to be relatively convenient to use.

[droidmonkey]

Since this issue was opened we have had a very nice PR submitted to support synchronization (#2109). Also the spirit of the discussion remains the same, it is not in our interest at this time to bloat the application with multiple protocols that are already very well supported at the OS level or with another open source tool. It is rather trivial to setup a OneDrive, Drive, Dropbox, Syncthing, or similar cloud storage service on all your devices. Rolling your own "cloud" using WebDAV and SFTP is totally inefficient and the end user is probably doing it wrong (ie, not very securely), they also do not natively support version controls like the big cloud players do. Its just not a good idea.

[dead10ck]

Well, you seem to be decided that WebDAV is the "wrong" way to do it, and not very open to discussion or new perspectives, so I see no reason to waste our time by continuing. Best of luck.

[droidmonkey]

Certainly not what I was trying to say. As was pointed out above, you can add a WebDAV folder to every modern operating system. What is the benefit for us to integrate that functionality into the application itself?

You are more than welcome to integrate this functionality yourself and submit a PR.

[dead10ck]

Mounting a WebDAV folder before being able to open my passwords just adds another step to the process. And if you want to keep a copy cached for offline use, you still need to do that yourself. The benefit is you can keep your passwords stored in the cloud without needing to run a service on all your devices to keep it synchronized. I would argue that running an always on service, such as Syncthing, to sync a single file is inefficient, especially for phone battery usage. From the user's perspective, if URIs were supported, and you have a service that provides WebDAV, you just give KeePass XC a link and your credentials and it does the rest. It makes it easy.

Also, if you actually are open to WebDAV integration, nothing in your language suggests that PRs are welcome. You said it would add bloat, was inefficient, insecure, and not a good idea. The issue is closed and labeled as "wontfix." There's hardly any ambiguity in the message. Everyone that comes looking to find out if you can open a URI the same way that you can in the vanilla KeePass app and finds this issue is going to get the same message. If you actually are open to it, you've sent a very misleading message.

[ccoenen]

I've done a little work in webdav in Node.JS. It's really not as simple as "add a library and be done with it". This was a pretty well-tested library, but it still failed with utf-8 filenames - because nobody had gotten around to testing them.

Long story short: let specialized things handle syncing. Don't bolt a half-finished sync thing on top of a specialized tool.

[ccoenen]

I also wonder how you would make the decision? Does KeePass XC add WebDav? or SCP? or SyncThing? or Git? or S3? or any of the other possibilities i've probably forgotten? Where do you draw the line? Why would we add WebDav but not Dropbox? Or OneDrive but not GDrive?

[bugfixx]

Thanks for the fast response. But I can't see any outcome of the discussion? In my opinion opening and editing a keepass file via https (WebDav) like the original Keepass allows isn't a security reason to me if the file is protected via VPN or something else. Teams should be able to access and edit a central hosted kdbx. Downloading, edition and uploading is no lucky option. So I hope to see this feature also in KeepassXC ;)

[droidmonkey]

It's not about security, its about the functionality of being able to mount and access a WebDAV folder already being present in all Operating Systems. Use the existing capabilities of the Operating System, there is no need to reimplement it in KeePassXC.

[bugfixx]

Mounting it is not very convienient, especially because I work for different clients in different locations. So it would be very cool if there where a simple dropdown to choose the actual url to open. And I've another question, why is it not allowed to store the password for the kdbx? That would also be very nice. I see collegues have their passwords written on post its or in textfiles on their desktop in a file, so this isn't very secure.

[droidmonkey]

What? Store the password for the kdbx where?

[ccoenen]

(I'd like to note upfront that it's a good idea to open a new topic for different questions/discussions/ideas)

This comes down to your threat model, and that is different for different people or circumstances. One person's threat model might be "state level actor trying to identify my sources, and perhaps imprison or kill them" another person's threat model might be "my spouse shouldn't look at my inbox so they don't see what I got them for Christmas".

Simply: Storing a password might not have any lasting consequences, but storing a password might get people killed. We can't know. We can prevent certain practices though.

If you store this password, it would have to be in clear text (or something that is essentially clear text). If it weren't, you'd have to provide some kind of password for your password, rendering the whole exercise moot. It is true that some people still choose to store a password on their computer (text file) or post it, but we should not make that any easier.

What you can do right now: there's various settings when the database will lock itself. Choose wisely and with regard to your personal threat model.

[ponchofiesta]

KeePassXC is a tool to help people do something. Every software should focus on usability. And there are some people that have this special use case. And if you want to provide a good user experience to those people you could add this functionality. Or you say no, this implementation is to heavy for us or KeePassXC should stay cleaner or something. I'd say WebDAV is good for your app saying "[...] to provide a feature-rich [...]".

For me not having this functionality causes me to use KeePass2, even if KeePass2 has bad look and feel on Linux.

[pattonwebz]

I was looking for a way to remotely host my database so I can access it in several locations. i am surprised that no such feature (or extension) exists to do it easily.

I discovered the workaround in this issue about storing it remotely and mounting it's location on my system. I have mounted a NFS drive where I store my database that allows me to retrieve it from a remote location. I actually think this may be the preferable solution rather than the software itself becoming responsible for remote store/retrieval.

[smseidl]

@droidmonkey I found this issue while trying to KeepassXC (portable) today instead of KeePass. In this thread you had the quote below:

It is rather trivial to setup a OneDrive, Drive, Dropbox, Syncthing, or similar cloud storage service on all your devices.

Its not always trivial to setup on of these storage services. I need to access a personal kdbx at time on my work PC, but don't have writes to install Google Drive. I have been using URL/Plugins to open my kdbx directly from Drive with KeePass. I won't be able to make the switch to XC without this ability. I did look a bit at the PR you mentioned, but didn't see how that would help in this case.

Also, if you do try to use the Drive URL in the Open dlg, KeepassXC freezes.

[droidmonkey]

Your point is well taken. The best you can do right now is download/upload your database manually in your circumstances.

[ech1]

Rolling your own "cloud" using WebDAV and SFTP is totally inefficient and the end user is probably doing it wrong (ie, not very securely), they also do not natively support version controls like the big cloud players do. Its just not a good idea.

Rolling your own "cloud" using WebDAV (using nextcloud's BUILT IN WebDAV for example) is totally efficient IF the end user is actually able to do it correctly (ie, securely), and just to make it clear for you, it is actually achievable. If you use nextcloud it does natively support version controls like the big cloud players do. IT IS a good idea. Why are you pretending like the application users are technologically illiterate ? @droidmonkey As far as i'm concerned it's a bad idea to assume that users can't setup their self-hosted cloud infra, because it is actually easy to do.

[droidmonkey]

Being able to do it doesn't mean you are doing it correctly or securely. Don't conflate the two items. Using NextCloud's WebDAV access capability isn't rolling your own, you are using NextCloud's implementation.

[ech1]

If you care so much about people doing it securely, then add requirements when using the Open URL feature such as https only, with valid certificate, and basicauth. What else do you want to consider webdav as secure ?

[ech1]

It is rather trivial to setup a OneDrive, Drive, Dropbox, Syncthing, or similar cloud storage service on all your devices.

It may be, but not everyone trusts these public cloud providers. People prefering to setup their own cloud service at home for privacy concerns is definitely justified.

Your point is well taken. The best you can do right now is download/upload your database manually in your circumstances.

Nobody wants to manually get the database into the phone, nor manually upload it somewhere else. The main reason people stick to keepass on PC in the first place is to use the OpenURL feature so that you do not have to do this annoying manual procedure everytime you want to change something in your kdbx database. It's not as if the changes will ONLY happen through the phone application right ?

[ccoenen]

If you care so much about people doing it securely, then add requirements when using the Open URL feature such as https only, with valid certificate, and basicauth. What else do you want to consider webdav as secure ?

I can hear the ticket "please allow self-signed certificates", "please add custom root certificate", "how about client certificates" and "please allow override for outdated cert" being opened already. And all of the arguments for built-in sync apply there, too. "users should be trusted to make their decision" ... "YES sure, but I have my reason for that outdated cert" ... "this is why people stay with that other solution".

Still a big "no" from my point of view.

Sync is a seperate issue, best solved in a different part of your system. Any solution included in KeePassXC will be less versatile, less maintained, less up-to-date than a seperate specialised tool.

I am aware that most of my posts in this thread have a ton of :-1: attached to them. But while that is true, I also haven't seen many people engaging with my reasoning in a way where I would be like "huh, maybe I was wrong?". I really don't want to break anyone's workflow, here. (also: i am not a developer of KeePassXC, so there's that).

[ech1]

Looks like we're going nowhere with that kind of developers, what a shame.

For anyone looking for an external synchronisation Android KeePass application, lookup "Keepass2Android", it has what those developers are refusing to implement. See pic related:

[ccoenen]

(look at the last sentence I wrote, and note that I did not edit my previous post; editing would show up in the interface)

That picture also is exactly why I wrote https://github.com/keepassxreboot/keepassxc/issues/868#issuecomment-427642396 three years ago: sync is a can of worms. Somebody will see your screenshot and say "huh, why don't they support git as a backend? Why don't they have IPFS? Oh, no custom Minio buckets?"

Again, I'm not a developer of KeePassXC, but sync remains an incredibly deep topic. I would rather see KeePassXC itself being improved with that time that would be burned on the eight sync providers in the previous screenshot.

[ech1]

Ah, almost forgot, there's also the application AuthPass that also supports webdav links on Android.

[ccoenen]

At the time of writing, this is the first page of the keepass2android bugtracker:

I took the liberty of highlighting the ones being problems with a sync provider.

[ech1]

At the time of writing, this is the first page of the keepass2android bugtracker:

I took the liberty of highlighting the ones being problems with a sync provider.

What's your point ? Don't want to solve problems ?

[droidmonkey]

Please stop trolling our issue board. If you want to help you can implement the requested feature and post it as a PR.

[networxnet]

I use exactly this constellation (webdav) for years with KeePass and various client systems to access my database.

Just now I wanted to test the much praised KeepassXC and had to realize after 1 minute that databases cannot be opened from URLs. After another minute, that apparently no plugins are supported either. And now that for 5 years only about the implementation of this, if I read here, already often desired function is discussed. The argumentation against the implementation has honestly not convinced me.

The connection of WebDAV in the operating system is definitely not an alternative on enterprise computers and usually not a viable way. What is needed here is a portable solution that supports this functionality. In my opinion, this is an essential function to use a password manager really throughout.

Too bad! So unfortunately I will not be able to find out if there are also advantages of KeePassXC compared to the original.

Maybe the authors here will think outside the box of their own usage and reconsider their philosophy here in the future ...

[ccoenen]

KeePass is a great program that is actively being developed. There is no need to switch over. This is not a competition? I do not believe KeePassXC devs are in this to squash another KeePass-software?

If it works for you, all the power to you!