Bachsau

Enpass is the only app with this problem. It is also the only app which creates its own session through a web browser. Why doesn't it use the operating system's APIs to access iCloud like every other app? This problem only exists because Enpass uses iCloud in a way it isn't meant to be used. Normally, if the Mac is properly connected with an Apple ID, applications don't need any additional authentication at all to access iCloud.

Hardware keys can never beat a good passphrase. They will either be cracked some day or be destroyed, resulting in data loss.

I just answered your followup questions via email. However, I really would like to know why my previous tickets were just deleted.

No, you don't. Just post your whole life publicly on the internet and be done with it. Until this happens. If you don't care about your privacy and security, noone can help you.

Why don't you display real, meaningful error messages instead of those cryptic numbers?

I'm crossposting this here because it's possible. Don't know why threads are allowed at this level when there is a sub-forum for everything.

It is a new and very annoying feature of macOS Monterey that Documents inside containers are displayed inside the real Documents folder. It doesn't really exist there, neither as a directory nor as a link. Finder just lies to you and displays it there, much like it still displays all the Applications in the "/Applications" folder, while many of them only exist in "/System/Applications". To answer your question: You can hide it by setting the "hidden" flag on the Documents directory of the container. Open a terminal and enter this command: chflags hidden ~/Library/Containers//in.sinew.Enpass-Desktop/Data/Documents This is not possible in the Mac App Store version. For no good reason, of course, and "~/Library/Containers//in.sinew.Enpass-Desktop/Data/Library/Application Support/Enpass/Documents" would have been a better choice for the default location. The same applies to all operating systems. On Linux the default location is "~/Documents/Enpass", which is also a terrible choice, because this is clearly application data. I moved it to "~/.local/share/Enpass/Documents". Edit: Why do I have to put two slashes between "Containers" and "in.sinew.enpass" to keep this crappy board system from replacing it with an "e"?

Since a few months I experience massiv problems with WebDAV and the support is actively ignoring my requests. I wrote about the following problem in two support tickets (ECS-30210 & ECS-30252). Both times I received acknowledgments from the Jira ticket system, and both tickets were actively deleted a few hours later without further notice! When I click the "View request" link and login to the support system, I'm told that the issue can not be found and doesn't exist. Maybe they are going to delete this topic as well, but I have to try. Now, the problem: Almost every other week sync stops working and I'm told that my password is wrong and I need to enter the new one. However, sometimes it just displays a numeric error code without further explaination. My password didn't change, and so far the only way to get it working again, was to restore the ~/Library/Containerse.sinew.Enpass-Desktop folder from a Time Machine backup. That always worked but is nothing I wanted to do forever, so I decided to disconnect all devices, remove the WebDAV contents and start again. But now, when I try to set up the connection again, I'm instantly told by Enpass that it could not connect to the specified WebDAV folder and that I should check my username and passwort, which are definitely correct! This only happens on MacOS. I also had iOS, Linux and Windows devices connected to the same WebDAV server and never encountered the problem on any of them. I tentatively identified that it has something to do with the WebDAV path containing a space, but this wasn't a problem when I initially set it up in March of this year. However, if I shorten the path up to the directory above the problematic part, it does connect, then instantly fails with error 906403, because that directory is read-only. I can do nothing about this suboptimal situation, because this is just how OpenXchange URLs look like. The full scheme is ""https://server.example/servlet/webdav.infostore/Userstore/Firstname Lastname/". I also tried encoding the space by typing %20 or +, but that didn't work either. In case of %20 the error code is 906409. This needs to be fixed and soon! PS: While the errors only happened on MacOS, re-setup seems impossible on any device now. At least the Linux version is able to write some kind of log file, but all I got was this: Info: [HTTP] Enabling VERIFY SSL PEER/HOST Info: [HTTP] Using AUTO Proxy detection Error: [configTeamVaultsSync] 120 ERROR in enabling sync for primary : local : true Info: [HTTP] Enabling VERIFY SSL PEER/HOST Info: [HTTP] Using AUTO Proxy detection Info: [HTTP] Enabling VERIFY SSL PEER/HOST Info: [HTTP] Using AUTO Proxy detection Info: [HTTP] Enabling VERIFY SSL PEER/HOST Info: [HTTP] Using AUTO Proxy detection Info: [HTTP] Enabling VERIFY SSL PEER/HOST Info: [HTTP] Using AUTO Proxy detection Info: [HTTP] Enabling VERIFY SSL PEER/HOST Info: [HTTP] Using AUTO Proxy detection Info: [HTTP] Enabling VERIFY SSL PEER/HOST Info: [HTTP] Using AUTO Proxy detection Not very informative... Definitely not what a good debug log should look like. No information about the HTTP requests that were sent and what they resulted in.

I can't believe this came from a team member. "%20" is the URL encoded representation of a space, not some weird escape sequence. The correct encondig of the URL above would be "davs://foo.bar/servlet/webdav.infostore/Userstore/Us%C3%89%C3%89%C3%89er%20Na%C3%89%C3%89%C3%89me" However, I found out that Enpass does neither require nor support pre-encoded URLs, not even "%20", which means you have to put "davs://foo.bar/servlet/webdav.infostore/Userstore/UsÉÉÉer NaÉÉÉme" to make it work. Edit: This worked for a while but is broken the latest releases. Currently there does not seem to be a way to get spaces or non-ascii characters to work at all. Support says they are working on it, but is has been three months already.

Guys, what are you talking about? I purchased the lifetime license one year ago on my iPhone and I never got asked to pay again or saw any banners, so all these threads seem very weird to me. If you get warnings about a hacked password, maybe you should change the password in question.

2FA is not snakeoil. Its purpose is to protect people in case of infected client computers. If keyloggers, viruses or packet sniffers steal your password, they can't just use it to log into your account.