Bachsau

Yeah, especially the part where he attacked my personality based on my profile picture was very helpful. 🙄 I'm using Enpass on all three platforms via store / package manager and really wasn't aware there is also a website download. However, when talking about "minimisation of IT applications", I don't see how having a standalone updater for everything is minimalistic. I'd rather call it overhead if the platform has a built-in general install and update service.

Passkeys have nothing to do with biometrics. They are just private/public key pairs. Wether or not they can be unlocked by biometrics depends on your Enpass settings, which apply to passwords and passkeys alike. Also, permanently declining won't solve your problem as most browsers will just go on trying to create the passkey in their own or the OS keychain next. Instead you would need an extension that makes the browser report it's missing passkey support entirely, but I don't know it that is even possible, especialy with Manifest V3. Browser and OS vendors really, really want to have your passkeys in their clouds.

Enpass is updated by the store you got it from, like Google Play, Apple App Store or the Microsoft Store. On Linux it is done through your package manager. So all such an option can do is link you to the updates page of whatever store you're using, and automatic updates are controlled by the settings of that store.

Sharing is not mandatory, and if it were, you couldn't say that you share with nobody. If you did share the Enpass folder with another real user (which I wouldn't recommend), then of course that user would be able to access your vault's data, but would still need the master password to see the contents. However, what we're talking about here is not a real share, but the side-effect of a security feature. Like almost every other app accessing an account at any service, Enpass uses a so called OAuth token to do so. This way it doesn't have to store your username and password and also can do only the things on the account that it was authorized for. It seems that Microsoft uses some type of ghost user to provide that token, and this ghost user erroneously shows up in the sharing screen of the OneDrive app. This might be confusing but is nothing to worry about. It's a mere oversight of some OneDrive app developer in the process of fetching and displaying the folder's access rights, which also explains why the app isn't able to tamper with it and why you shouldn't try to do so.

There already is a setting to disable handling of passkeys by Enpass, but it's in the browser extension options, not the Enpass app. chrome-extension://kmcfomidfpdkfieipokbalgegidffkal/pages/settings/option.html

Just don't. This is another reason why people get "hacked". You can't trust other people's devices. There is no excuse to ever log into any of your accounts on another one's device. If you feel like you need to, change your workflow. Use sharing features or emails.

Microsoft uses tokens for everything, so if you change your account passwort or email address, apps and services won't loose the connection.

Enpass' passkey support is still very basic and lacks certain features that make it very inconvenient to use. I would like to see the following improvements: I don't want to re-type my master passwort if Enpass is already unlocked (desktop version). For a password I can just fill it out by selecting it from the list or dropdown. It should be that easy with a Passkey, too. Put a confirmation button there and only ask for authentication when Enpass is locked. 2fa codes are automatically copied to the clipboard after choosing a password entry. Not so after logging in with a passkey. Make it work. System integration. Enpass on desktops works via browser extensions, but that's confined to the browser. macOS features a system-wide auto-fill since the release of Ventura, yet Enpass still doesn't integrate with it. This makes it impossible to use passkeys in apps and built-in web views where the browser extension is not available.

What's it with this "seems you haven't used Enpass for a while" anyway? Even if this would be true – there's no reason to ever repeat this verification process ever. Once connected, it's done!

Please don't follow these bad suggestions. They are very ill-considered and a good example why following customer feedback isn't always right. Unnecessary because you can always create a custom template if you wanted less or other fields. At least such buttons wouldn't be harmful, unlike your other suggestions. Definitely not. Many sites don't serve appropriate icons and Enpass only caches those icons but doesn't save them as part of the items. I use a lot of custom imported icons and am always happy if there is a pre-made one. Field names may vary and I don't want to be forced to name my fields after some specific schema. I have username fields named "Customer Number", for example, because that is what I login with on that site. Also english isn't the only language in the world. The freedom Enpass gives me with the fields was another reason for me to switch from 1Password. Instead, some field types should have a more strict typing, because currently you can enter any sort of information in a "Numeric" or "Date" field.

Apple's systems are not secure, especialy not with a simple PIN. I order to securely encrypt data, you need a secure algorithm and a long and complex key. Apple circumvents this by using hardware security devices, which of course can AND will be broken some day. If someone finds a way to get inside Apple's systems, no matter if a criminal, law enforcement or an intelligence agency, your PIN and 2FA won't save you. Don't be one of those guys using "password" for a password and don't fall for the misapprehension that complex passwords can't be remembered. Generate yourself a totally random password, write it on a piece of paper and type it in several times a day, and I promise you will remember it in no time, at which point you can discard the piece of paper.

Let me say that most of us are quite happy with a working solution that's being maintained. The notion that good things need constant changes is idiotic. What's important are bug fixes and adaption to OS and browser changes. No one needs re-designs which tend to make everything worse and forces the user to change his way of using the app. 1Password might be getting more upgrades but requires a subscription. I'd rather pay just once and use the features I get until I might decide to pay for some upgrade, instead of constant feature creep where most of those features are useless. If this is what suits you better, just do it, instead of coming here to demand Enpass becomming more like it. I switched three years ago and did not regret it. Sadly the thing about bugs and support is true. If something is broken, expect it to stay broken for a loooong time. I experienced this with iCloud sync and WebDAV if the URL contains whitespace, so I'm currently using Google Drive to sync. On the other hand I didn't have to pay another cent in three years, which is totally worth it. But I've also seen bugs being fixed, like the problem where changed passwords could be overwritten with old ones when the item was used on another device before the sync finished. Sure I wish that more bugs were fixed and would be more than happy to pay for an upgrade if it included things like PassKey support, but I don't need constant updates just so see something change. There is no reason to asume anything like that. It has been audited at least once, and if you don't do fundamental changes to the way synchronization and encryption works, that won't change. Fixing bugs and adding features to the GUI won't affect that.

Thanks, it works with a second item, even though I had to disable password checks to keep Enpass from complaining about doubled passwords – least you take that option away from us, too. Just know that no one likes to patronized and it just makes your software worse because the HTTP address was also part of the item, thus your decission goes against usability. Also, plain HTTP will always be there, especially on local networks, where you can't get a publicly trusted TLS certificate for a device. PS: Maybe a meaningful error message would also be helpful if you don't want to change the behaviour. Otherwise all the user sees is that something is not working when he double-clicks an affected item.

Enpass is on version 6.9.0, macOS 12.6.8 and Arch Linux. Add-On version is 6.8.3 on Firefox 116.0.2. The URL is "http://fritz.box/" on the local network. The FRITZ!Box by AVM is a very popular residential gateway in germany which uses this URL to host the devices's web-based control interface.

The item holds two URLs. One is a HTTPS-secured dynamic domain for external access, the other is a local one for access from inside my home network. But if I order it by double clicking the item, it should work. I am the user and the red banner in the Enpass popup is enough of a warning! Sorry, but I do not understand what you mean. The local URL is not available via HTTPS, which is no security threat since the data never leaves the local network.