Arthur Rump

I've been playing around with the JSON export feature in Enpass, and I have to say that I'm quite impressed by the amount of information I can get out in a relatively easy to process format. Very well done! However, I'm missing two bits of information that I would like to see included: The creation date of an item. Currently only the last modified date is available, but since the created date is also shown in the UI, I think it would make sense to also include it for each item in the JSON. Information on whether or not an item was trashed or archived. The export wizard allows you to include these items in the export, but I don't see any indication in the JSON if an item was trashed of archived. This would be nice to include, so that a restore of a JSON file with archived items can put those items in the archive also after restoring. Would it be possible to include this information in the JSON export as well?

I was just replying to another thread where people reported the same issue, but then found this thread which seems to be more appropriate. I hope the following contains some useful pointers for troubleshooting. For reference, I'm running Enpass version 6.6.0 (770) on Windows 10 1909 (OS Build 18363.1379). I have the same issue as reported here. After the recent update, I need to restart Enpass after booting my machine in order for Windows Hello to work. Just like Volkx showed, Enpass would show the 'Unlock with Windows Hello' screen, but the Windows Hello system dialog (see below) doesn't show. I've noticed before that Enpass usually opens a small window with a loading indicator right before the system dialog pops up, but that window doesn't show either. I think there is a problem with Enpass trying to start the Windows Hello process right on starting (by which I mean the automatic open on system startup, not me opening the app manually): while the Windows Hello dialog doesn't show up, the infrared lights of my Windows Hello enabled camera do start lighting up as if trying to identify me. Only when restarting Enpass and successfully logging in using Windows Hello do these lights turn off again. My guess is that Enpass starts the Windows Hello process, but somehow prevents the system dialog from opening. Until Enpass is restarted the Hello authentication process is blocked by this previous attempt, so Enpass fails when trying to initiate the Hello process again. Because the dialog is not shown, there is no way to cancel Windows Hello except for restarting Enpass. What I mean with the Windows Hello system dialog:

Ah, it was not the primary vault and I tried to use the vault password instead of the master password. Makes sense that it didn't work. Thanks!

I have a related question: how can I change the Master Password of a vault that does have a keyfile? The "Change Master Password" dialog does not have an option to add a keyfile when you are asked for the old Master Password.

I would love Enpass to just show me the Windows Hello screen whenever it wants to be unlocked. So when I open the app, the assistant, use the extension button in the browser or hit the autofill key shortcut, I should immediately be asked for my Windows Hello authentication, without pressing any buttons. I think for most people that have Windows Hello login enabled, this would be the preferred way to go, but if you think people will be annoyed by it, making it a separate option is fine too. And it would indeed be awesome if Windows Hello would stay enabled after a reboot!

Hey @Vinod Kumar, how are things looking for Windows Hello?

I conducted some further research. To enable access to the CredentialManager API in a WPF application the following snippet should be added to the .csproj file (inside the <Project> node): <ItemGroup> <Reference Include="System.Runtime.WindowsRuntime, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089, processorArchitecture=MSIL"> <SpecificVersion>False</SpecificVersion> <HintPath>$(MSBuildProgramFiles32)\Reference Assemblies\Microsoft\Framework\.NETCore\v4.5\System.Runtime.WindowsRuntime.dll</HintPath> </Reference> <Reference Include="Windows"> <HintPath>$(MSBuildProgramFiles32)\Windows Kits\10\UnionMetadata\Facade\Windows.WinMD</HintPath> </Reference> <Reference Include="Windows.Foundation.FoundationContract"> <HintPath>$(MSBuildProgramFiles32)\Windows Kits\10\References\Windows.Foundation.FoundationContract\1.0.0.0\Windows.Foundation.FoundationContract.winmd</HintPath> </Reference> <Reference Include="Windows.Foundation.UniversalApiContract"> <HintPath>$(MSBuildProgramFiles32)\Windows Kits\10\References\Windows.Foundation.UniversalApiContract\1.0.0.0\Windows.Foundation.UniversalApiContract.winmd</HintPath> </Reference> </ItemGroup> With these references, I was able to add Windows Hello to a WPF application. Conversion to a Store-app via the Centennial bridge isn't required in this case. Hope this helps a bit!

A long, long time ago (I couldn't even find the topic anymore) I asked if you could support logging in into Enpass using Windows Hello on the Desktop application, so it could also be used in the browser extensions (that's how your system works, right?). You replied that the Windows Hello APIs aren't available on the Windows desktop. I recently came across an article on the Windows Dev Center: UWP APIs callable from a classic desktop app. This article mentions that every UWP API which lists the DualApiPartition attribute in the Attributes section is also available for classic desktop apps. The API that's used for Windows Hello (KeyCredentialManager) actually lists this attribute, so it can also be used in classic desktop apps. As you might have guessed, I would really love Enpass to support this! It would make Enpass exactly what I want my password manager to be.