ttk

Ah, seems like i have missed the two-year anniversary of this issue. In the meantime, i ditched Keycloak and Authentik for Authelia. Also, i set up a self-hosted Bitwarden server and uninstalled Enpass. Maybe thats a solution for you other guys, since i am still not willing to redeploy my Authentik for the devs to test on.

After the newest update of the Firefox extension i noticed a very annoying behavior, similar to On some login forms, especially on Keycloak but also on other forms, when i right click the form, use Enpass and select the proper password entry, the extension does not fill in the password directly, but opens a new tab with the target location of the selected password entry. This breaks every redirect parameters which were given in the original URL in the original window. The only workaround is to manually copy out my credentials from the main Enpass window, rendering the extension completely useless. This happens on extension 6.9.41 and Firefox 126.0 on macOS sonoma. This is such a huge productivity blocker that i am currently seriously considering switching to Bitwarden. Please have a look and give feedback.

@Amandeep Kumar Are you serious? I have switched from Authentik to Keycloak because of the lack of updates in this thread for several weeks. I wasn't aware that you completeley stopped working on this issue, because the availability of my Authentik instance is crucial for your development work - but good to know that you planned with testing against my instance without ever notifying me. I would have assumed that a serious development company would be able to quickly deploy their own Authentik instance to be not depending on other instances they have no control over. Besides that, you would have landed in my fail2ban filters nevertheless, since it is rather unusual for requests with IPs originating from india to access the landing page but not try any login attempts, or try them and fail because you would not have any valid passwords. But yeah, i switched my SSO provider because of this issue, maybe i should look into switching my password manager as well, since this is not the trustworthy behaviour i would expect.

I have a fresh installation of Firefox on mac OS and want to set up the enpass extension. I have installed the extension and want to fill in the first password. Now my problem occurs: The extension briefly displays the pairing code. In the exact same second, Enpass crashes (or at least the window closes). This causes the Extension to close the tab with the pairing code. After restarting Enpass and unlocking, the pairing code entry window is still displayed (so i assume it did not really crash). However, if i had luck with memorizing the code during its short display time, it is not accepted by Enpass anymore. So currently i am unable to pair the extension to the main Enpass app. I also do not get a crash log, since apparently Enpass hasnt crashed completely, however, the window is disappearing, and there is no dock icon anymore. Any help is greatly appreciated.

@Abhishek Dewan it has been several weeks now...how hard can it be?

@Abhishek Dewan Do you already have some updates? This issue is quite annoying and keeps me from fully rolling out Authentik in my environment. Should i keep an eye on Enpass releases or on Extension releases?

I could not reproduce it reliably. It seems that this occurs when Enpass stays locked for longer periods of time. I have captured one occurence, but apparently the screenrecorder wasnt able to capture the extension overlay as well, so now i'm trying to get a new recording with OBS Studio.

Hey, the software versions are the same as here: Regarding URLs: This happens regardless of which URL i am visiting. This has more to do with how long Enpass has been locked. Since this happens total randomly and not on every login attempt, i have a hard time recording it. I will try to keep an eye on my screen recorder and let it run just in case whenever i execute a login action.

I have the following problem: 1. Enpass is locked. 2. I right-click on a password form in the browser to let it fill the password 3. It shows the vault password prompt which i enter 4. The extension unlocks and briefly shows the entry for the current page, but after half a second "loses focus" and show all entries in the vault 5. Workaround: Hide the extension, and do the procedure again, so that it is opening unlocked, and only showing the entry for the page i want to have my password entered in. What can i do to prevent the behavior in step 4?

Hi, that are good news. I will have an eye on new enpass versions and try it out subsequentially.

Sure. It is on Windows 10 Pro, Patchlevel 19044.2486. However, i think this also happens on a Mac with OS X Ventura. Does not happen on iOS. Enpass is version 6.8.4. Chrome is version 109.0.5414.120 - but this issue occurs on Firefox as well. Enpass Extension is 6.8.0.

I have a setup where i am securing some applications with an Authentik SSO server. It does not work very well with Enpass. This is my problem: 1. I open the URL to the application. It is forwarded to the SSO login form. The form has the callback URL to the application as HTTP GET parameters in the address bar, e.g. "https://authentik.simonszu.de/if/flow/default-authentication-flow/?next=%2Fapplication%2Fo%2Fauthorize%2F%3Fclient_id%3DSCEmh1dhqxFlmPM30asa7dPqxs3dMBskX87Kx8DE%26redirect_uri%3Dhttps%3A%2F%2Fcomics.simonszu.de%2Foutpost.goauthentik.io%2Fcallback%3FX-authentik-auth-callback%3Dtrue%26response_type%3Dcode%26scope%3Demail%2Bprofile%2Bak_proxy%2Bopenid%26state%3D1qTRKfZVO07F-Hh7I44_8vaurt9GzaNTETUy1igmH08" 2. I select the Authentik Login item in Enpass via the Chrome extension. The item has "https://authentik.simonszu.de" as the saved URL, since that is the most common denominator between all SSO-secured applications as well as the admin interface of the SSO server. 3. As a result, the Enpass extension causes Chrome to open a new tab, with the address bar containing only "https://authentik.simonszu.de/if/flow/default-authentication-flow/?next=%2F", so, no reference to the callback URL to the actual application any more. 4. If i try to do step 2 again in the new tab, Enpass does not fill the credentials, but rather opens a third tab, containing the same address in the address bar as in step 3. 5. I can repeat step 3 and for for infinite time, causing Enpass and Chrome to open more and more tabs, and not logging in properly. Is there a flag where i can tell Enpass to simply fill in the credentials, and not trying to open the URL it has defined in the login item in a new tab? That would be nice.

If only the big red "YOU HAVE BEEN BREACHED, ACT IMMEDIATELY" alert could be hidden somehow. Since when you click on it, you need to pay. But it cannot be hidden, even if i do not want to use the premium features. Shitty UX is shitty.

I disagree. Github is for distributing source code, and eventually releases made from this source code. Just uploading binary artifacts without the code is not what git and Github was made for. If you need a backup of the installation, download the standalone client, and store it somewhere safe for yourself.

Hi, one of the reasons why i preferred Enpass over other password managers like Lastpass and 1password was that the developers just distribute the binary, and everything else like sync and so on was completely in my own hands. No connections to other servers, nothing. This was great, since i believe a password manager should do as little communication as possible. Until now i was very happy with Enpass. But now i have some serious questions about the new favicon feature. The announcement says that Enpass downloads it from the developer's server, and you need to enable the feature on each client separately, so i assume each client downloads the favicons separately. So, in concern of data security and privacy, i'd like to know why this decision was made. Each website provides its icon as https://url.tld/favicon.ico. Why isn't Enpass able to download this file directly, but instead phoning home with all URLs which are stored in my vault? Why is it dependant on some kind of managed service now? Why aren't the icons stored in the vault in the same way as attachment files are stored? If you guys have a reasonable explanation for this design decision, i'd like to hear it, since a password manager is a tool of high trust. Since Enpass downloads the icons when the vault is unlocked, and sends all the URLs to the developers, what guarantees me that it doen't do the same with all password data? I do not want to audit it's connection attempts with tcpdump every time an update was made. At least the other cloud based password managers do the sync with their servers with the encrypted vault file.