tox1c90

Really seems to be a general problem! I have it for a few days now. Enpass is almost once a day asking for a new activation in order to restore the license. 
Strange thing is that I was using iOS 17 since the public beta came out, and was never encountering this issue. It started after general availability / final release of iOS 17, so I think it’s maybe just an issue caused by one of the last Enpass updates?

I think the issue started with the passkey update. 

As I already pointed out in the Beta forum, the issue might be related to the Infineon TPM. 

https://discussion.enpass.io/index.php?/topic/21265-say-hello-to-full-time-windows-hello-with-enpass-beta-ver-650/&do=findComment&comment=38797

I was not able to get it to work with Infineon. Only after I swapped it for a Nuvoton TPM, it started to work immediately. 

In my case, Windows was throwing a certificate error for the Infineon TPM on each reboot. Look at your Windows event log if you see something like that once per reboot. That error was not related to Enpass at all, but to something which appears to be actually a problem of the TPM firmware itself. Even after clearing the TPM, the issue remained. The error said, that "public and private key are not cryptographically bound", which as far as I understood is one of the main things for which Enpass is looking. It was also showing an Infineon URI in the details tab and said that something is wrong with that. 

Because this error was gone with Nuvoton TPM, and Enpass was also with that, I assume this is an issue of Infineons implementation. 

I also did a bit of research on this error and what it basically means is, that the TPM cannot provide attestation anymore that the private key was really generated by the TPM and never left it. Which appears to be crucial for Enpass Hello support. I saw that everyone posting screenshots is having Infineon TPM, which is why I think that might be the issue. 

I wasn't able to get it to work using the Infineon TPM 2.0 module on my Asrock board, despite using the latest firmware.

Also tried clearing the TPM and setting everything up from scratch (Windows Hello, Bitlocker TPM and so on...). I also noticed that the event log throws a Certificate Error on each boot regarding the TPM attestation, saying that the public and private key are not cryptographically bound. Most likely this is also the problem that leads to the failed check which Enpass is calling.

However, I was able to fix the problem - by removing the Infineon TPM module and putting the Nuvoton TPM module back in (my board vendor Asrock is actually selling two versions of the TPM 2.0 module - one made by Infineon, the other made bei Nuvoton). This fixed both the event log errors as well as the ability of Enpass to use full-time hello.

For people thinking about how to achieve a compatible combination of Enpass, Hello and TPM, I attached a screenshot showing my TPM properties and firmware version.

I am talking about the store version, of course.

I got it working now on another computer, which is a Surface Go tablet from Microsoft. Only difference in configuration which I am aware of is that it's using a different TPM.

The Surface Go is using it's Intel fTPM (firmware/platform TPM 2.0), while my desktop computer has a discrete Infineon TPM module (also TPM 2.0, latest firmware). Both claim to fully support "Key attestation".

I remember last time I was using the old Enpass UWP version (which already had full-time Windows Hello), I was using a different discrete TPM module on the same mainboard. It was a Nuvoton TPM 2.0, which I got replaced by the Infineon because it was painfully slow in comparison. However, full-time Hello was working with the former TPM module.

Maybe, this could be something for the developers to check? Could it be that Enpass was tested against the built-in Intel/AMD platform TPMs only? For me, using a discrete TPM module was always preferable, because it survives an UEFI or Intel management engine update / reset to defaults without clearing or wiping the TPM.

If I find some time, I will also try to check a few things on my side, like e.g. swapping the different TPMs (Intel vs. Nuvoton vs. Infineon) to see if I can finally get it working again.

Hi @Kashish,

I just updated to 6.5.0 and had to re-enable Windows Hello (maybe it got disabled due to the changes made for full-time Windows Hello support). However, it seems like it is not working as intended for me, because it says "Master password is required every time you restart Enpass". So I restarted Enpass and indeed I had to enter the master password.

Are there any additional requirements for the full time Windows Hello support? I know that it worked on my PC using the old Enpass UWP for Windows 10. There I had the full Windows Hello support because I fulfilled all the requirements, i.e. TPM 2.0 enabled, UEFI boot without CSM, SecureBoot enabled. So Enpass UWP was able to use the TPM to safely store the credentials.

Did the requirements change with Enpass 6.5.0 in comparison to the Enpass UWP regarding Windows Hello support?

Hi @Anshu kumar,

did you get any feedback on this issue? I ask because it's still happening on latest Enpass (Windows Store). But it's happening under slightly different conditions compared to the original issue. Right now, it is only happening when Enpass vault becomes locked and minimized to system tray, but unfortunately every time.

New steps to reproduce quite easily:

1. Launch Enpass and unlock vault in main window

2. Lock vault by pressing the "lock" icon in main window

3. Press "X" to close main window so that Enpass is minimized to system tray icon

4. Open elevated Powershell, run: "powercfg /energy /duration 3", open energy-report.html and notice the platform timer warning due to Enpass

If Enpass vault stays unlocked all the time, there is no issue. Issue happens only when locked + minimized to systray.

Hi @Anshu kumar,

for some reason the problem appears to be back. I'm pretty sure everything was fine until 6.12 (including), so I think it came back with 6.20 or one of the latest updates. Could you please check on your side?

Hi!

I recently started using Android 9 and 10 (got the update a few days ago on my Google Pixel 3a) and tried out the new Autofill API in my browser (Microsoft Edge for Android). Unfortunately, this turned out to be a really bad experience. While autofill via accessibility service was working really great on almost every website (independent from language), it goes horribly wrong when doing it via the Android autofill API.

I noticed that on all German sites Enpass will just fill the mail address / user name into both login fields (mail/username + password). So it does not fill the password at all, it does this:

Username: "user"
Password: "user"

When I browse an English site, it looks like it's behaving normally. I tried a few and there it seems to work. Until now, I have not found a single German site where the Autofill via API works.

So from my point of view, there are these possibilities:

1. Enpass itself is confused by German password fields called "Passwort" - but this would be strange because autofill via accessibility service is doing fine
2. Enpass is just confused in this particular autofill mode in conjunction with Edge for Android browser
3. Android or Edge browser are doing some crap on German sites which makes it impossible for Enpass to determine what kind of stuff it has to autofill

I give you a list of sites where it definitely does not work right now, you should be able to reproduce easily on these sites:

www.winfuture.de
www.gamestar.de
www.computerbase.de

I haven't tried another browser (e.g. Chrome) so far, because I want to use Edge in any case to sync my favorites and stuff with my Windows devices. It would be great if you could try to reproduce this issue and fix ist!

Hi @Anshu kumar,

after running and testing the latest Enpass update 6.1.1 for several days now, I can confirm that it is not longer raising platform timer resolution! Thank you for fixing it

Unfortunately I have to report that this is still an issue. But I narrowed it down to a single case:

The power bug appears, when vault is locked and main window closed so it runs completely in the background and does only appear as systray icon.

So exact steps to reproduce:

1. Launch Enpass, but do not unlock vault.

2. Close Enpass main window using "x" on top right corner of the window. Thus Enpass is still running in background but only shows as system tray icon.

3. Open elevated Powershell, run: "powercfg /energy /duration 10"

4. Open energy-report.html, scroll down and notice that there is a yellow warning because Enpass is requesting raised Windows Platform Timer resolution

5. Now click on Enpass tray icon and unlock the vault

6. Run "powercfg /energy /duration 10" again and check energy-report.

7. You will see that now, Enpass does NOT request timer resolution raise anymore and the warning is gone.

8. Wait for 1 minute system idle (or whatever that leads to Enpass locking the vault automatically)

9. Recheck "powercfg /energy /duration 10", you will see that now Enpass started again this timer request and the warning reappeared.

So Enpass is doing something bad, while it's just running in background and vault is locked. It's basically requesting high-precision timer all the time while its idle. This is very bad style.

Could you please have a look on this again? Right now, Enpass is the only app on my PC that is behaving badly regarding Platform Timer. So right now I have to close it completely and prevent it from running in background instead of just locking the vault to prevent higher-than-normal battery usage.

@Hemant Kumar

@Anshu kumar

More background information for why this is important: https://randomascii.wordpress.com/2013/07/08/windows-timer-resolution-megawatts-wasted/

Looks like it is only happening when Enpass is launched automatically and minimized together with Windows. I was not able to reproduce it after closing Enpass and starting it manually.

It is really strange that you guys are facing so many problems... 

I'm using Enpass 6 on both Windows 10 (with Edge browser extension) and Android since it was made available as Beta in Windows Store, and I haven't experienced any severe or functionality breaking issue so far. The communication with Edge extension even works much better with v6 compared to v5. Not for one second I thought about downgrading to the previous version.

Looks more like compatibility issues which needs to be fixed for you, and not as if Enpass 6 itself is broken. 

On 1/1/2019 at 11:08 AM, Hemant Kumar said:

Hi

Thanks for reporting. We have fixed the issue and will be available in the next update. It was the problem with the Animation of sync icon. Please wait for the next update. 

@Hemant Kumar

I have to re-open that case. With the update it seems to be partially fixed. In the state when Enpass application is fully opened (see upper screenshot "Enpass main window.jpg") the problem is fixed and Platform Timer Resolution is at default now, so Windows energy report does not show a warning anymore.

In the state when Enpass is running in extension mode (see lower screenshot "Enpass taskbar.jpg"), that means when left-clicking the Enpass icon just pop-outs a small Enpass window docked to the taskbar, the Platform Timer Resolution is still increased to 1ms by Enpass and Windows is showing the warning.

Hello!

If Enpass 6 is running minimized in the background / tray icon and the vault is locked, the Windows Platform Timer resolution is increased from the default 15.6ms to 1ms by Enpass process, which causes significantly lower CPU C state usage and thus less battery life.

Steps to reproduce:

1. Let Enpass 6 start automatically with Windows, or start it and minimized it to the system tray, but do not unlock the vault yet

2. Run "powercfg /energy" within Windows PowerShell and let Microsoft power diagnostics generate an energy report

3. The report will show a warning, that Enpass.exe is requesting a non-standard Windows Platform Timer resolution that causes lower battery life (see attached screenshot). You can also confirm with tools like "ThrottleStop" that there is significantly less CPU package C state usage / power saving when Enpass is waiting for the vault to be unlocked. This almost doubles idle power draw of my CPU.

4. Unlock the Enpass vault by typing your password into Enpass window

5. Run "powercfg /energy" again

6. You will notice that when vault is unlocked, there is no Windows Platform Timer warning anymore and C state usage increases immediately.

It should not be necessary for Enpass to increase Windows Platform Timer resolution when just running IDLE in the background with the vault still locked! The fact that the Platform Timer resolution goes back to its default value as soon as Enpass vault is unlocked, is a clear indication for that behavior to be a bug!

Hi!

I was using Enpass UWP for Windows 10 with full-time Windows Hello enabled, because my computer fulfills all necessary requirements (TPM 2.0, UEFI Secure Boot). So Enpass UWP successfully detected that the machine is secure enough to store the keys in hardware/TPM and use Windows Hello directly on the first launch even after a computer restart or when Enpass UWP was completely closed.

Now with Enpass 6, it is only using the fallback solution of asking for the master password the first time after restart, and using Windows Hello only for subsequent unlocks. I think Enpass 6 is great and a big improvement in many things, but in this particular aspect it feels like kind of a stepback.

So my question is: Will full-time Windows Hello be supported in Enpass 6 again like it was in Enpass UWP for computers which fulfill the necessary requirements for hardware/TPM-based security?

Quote

Unlock with Windows Hello: You can now unlock Enpass with the Windows Hello. Master password will be required at every fresh start of the app.

What is about full-time Windows Hello, when the computer fulfills all the requirements needed for it to work in the Enpass UWP app?

I have UEFI boot with Secure Boot, TPM 2.0 module, Windows Hello working with TPM, and was already successfully using full-time Windows Hello with Enpass UWP.

Will it also be supported by Enpass 6? Or is it already for people that fulfill said requirements?

Hello!

It looks like Autofill is not working when using the Samsung Internet browser which is the preinstalled and default internet browser on newer Galaxy smartphones (S7, S8,...). Because it has a lot of optimizations for Samsungs Galaxy phones it's the preferred browser on Samsung devices and much faster and less battery consuming than Chrome.

So it would be really great if you could give us autofill support for the Samsung Browser. Are there any plans? They even have some built in extension capabilities that allow third-party plugins to access the web page content (meant for adblockers and stuff like that..). Maybe Enpass could even integrate with that?

Unfortunately even with latest version of Enpass, this is still the case

Doesn't seem to depend on the browser extension though (same problem with Chrome and FF), it also happens sometimes when I click on Enpass icon in system tray, but only when extension support is enabled. Small Enpass box only appears briefly and I have to click a second time on the icon.

It would already help a lot if it wouldn't be necessary to re-enable the extension every single time you restart Edge. That is what makes it totally unusable for me. I could live with having the loopback stuff enabled.

I'm also experiencing this kind of crash. But only sometimes, which makes it really hard to reproduce. When it happens, it happens when trying to open Enpass window. Thereby it doesn't matter if I'm already logged into my vault or not.

Last version of 5.3 was fine, problems started since 5.4. My cloud sync provider is Onedrive.

Event log entry (unfortunately only in German):

Name der fehlerhaften Anwendung: Enpass.exe, Version: 0.0.0.0, Zeitstempel: 0x0538bc38
Name des fehlerhaften Moduls: libstdc++-6.dll, Version: 0.0.0.0, Zeitstempel: 0x00000000
Ausnahmecode: 0x40000015
Fehleroffset: 0x0001f11d
ID des fehlerhaften Prozesses: 0x17c8
Startzeit der fehlerhaften Anwendung: 0x01d25d316fc38744
Pfad der fehlerhaften Anwendung: C:\Program Files (x86)\Enpass\Enpass.exe
Pfad des fehlerhaften Moduls: C:\Program Files (x86)\Enpass\libstdc++-6.dll
Berichtskennung: 43891490-3a23-43c3-82b1-c3e2a24502d1
Vollständiger Name des fehlerhaften Pakets: 
Anwendungs-ID, die relativ zum fehlerhaften Paket ist: 

I'm using Windows 10 x64 (Anniversary update 1607) and browser extension for Firefox.

Hello!

Since Firefox 50 (which got released today) the browsers multiprocess architecture "e10s" is supporting extensions, too. However, Enpass is being reported as "Not compatible with multiprocess" by the Addon Compatibility Reporter and is thus preventing e10s from being enabled. Do you have an update in the pipe for giving us multiprocess support?

That would be great, because right now Enpass is the only extension which I'm using that prevents me from using FF in multiprocess mode
 

Hello!

I have the following problem: Whenever I click the Enpass extension icon for the first time after starting Chrome (doesn't matter if Enpass is already unlocked or not), the small Enpass box is just flashing up for a few milliseconds. I have to click it for a second time to make it stay visible. After that everything is fine until I restart Chrome -> same thing again.

Any suggestions?

Hello!

I'm new to Enpass (switched from Lastpass  ) and so far everything was working really well, but now I have a problem with the Enpass extension for Google Chrome. Extension support is enabled in Enpass Desktop, connection to localhost / 127.0.0.1 is not blocked by any firewall application or AV software, but whenever I try to use the extension it shows me "Enpass connection error" and sometimes the following:

Quote

Application

• Name : Enpass Password Manager
• Version : 5.3.0

Browser

• Connecting Path : There where something wrong to find executable path
• Error : Unknown error
• LocalAddress : 127.0.0.1
• LocalPort : 10391
• Origin : chrome-extension://kmcfomidfpdkfieipokbalgegidffkal
• PeerAddress : 127.0.0.1
• PeerPort : 49469

Operating System

• Name : Windows 2007

Proxy

• Type : NoProxy

If I disable the "Verify browsers" setting in Enpass, it starts working, but I think that could be security risk...

The error "There where something wrong to find executable path" seems important to me, maybe that is connected to the problem? It's working on another PC of mine, so I looked for the differences between the computers.

The computer where it is NOT working has Windows 7 x64 Pro (instead of W10) and a multi-user configuration, so the installer of Google Chrome didn't use the user folder where it usually puts the Chrome binaries. Instead it was automatically installed to "C:\Program Files (x86)\Google\Chrome\Application" (despite it's the x64 version of Chrome. I don't know why they are installing it to (x86) folder...)

Could it be that Enpass doesn't expect the browser executable at this path?