Enpass not filling info when accessing HTTP (not HTTPS) websites

[randomusername]

I have a couple local services (Portainer and NGINX Proxy Manager) that require username and password. Their hostname is in the form of http://hostname.lan:someport

When i try to use Enpass with those websites it simply won't fill the form and i have to manually copy paste my credentials. When i expose those same services with https everything works.

As you can see the credentials are saved and recognized, but when i click on those the form is not filled.

This problem appears in every browser/desktop OS combination, but everything works fine on mobile (safari + ios)

[Abhishek Dewan]

Hi @randomusername

Welcome to the Enpass Forums.

We have received your query on support@enpass.io and have responded to the same. To avoid duplication of efforts and confusion, we request you to please revert to the same. We appreciate your understanding in this case.

[Bachsau]

I'm having the same problem. It's extremely inconvenient for local devices and still not fixed in Enpass after serveral months. I'm not using the on-page dropdown in favor of clicking the addon icon. It works however, when going to the login page by clicking the URL in Enpass.

Edited August 22, 2023 by Bachsau

[Abhishek Dewan]

Hi @Bachsau

I would like to share that if you create an Enpass Item for the HTTPS website, then Enpass cannot autofill the login details of the same Item in the HTTP URL of the same website due to security reasons. However, if you wish to autofill them explicitly then as a workaround, you can try the below steps:

1. Create a new Item with HTTPS url then use the autofill feature.

2. Update the existing HTTP Item and add the HTTPS URL to it.

#SI-3348

[Bachsau]

9 hours ago, Abhishek Dewan said:

if you create an Enpass Item for the HTTPS website, then Enpass cannot autofill the login details of the same Item in the HTTP URL of the same website

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.

10 hours ago, Abhishek Dewan said:

due to security reasons

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!

10 hours ago, Abhishek Dewan said:

• Create a new Item with HTTPS url then use the autofill feature.

• Update the existing HTTP Item and add the HTTPS URL to it.

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.

[Abhishek Dewan]

Hi @Bachsau

I will gladly get this checked with our dedicated team. Please share the version of the Enpass app, OS, Enpass Extension, and browser you are using along with the URL's in which you facing facing this issue. If you'd rather share these details privately, please feel free to DM me.

[Bachsau]

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.

Edited August 22, 2023 by Bachsau

[Abhishek Dewan]

Hi @Bachsau

We appreciate your willingness to provide the information.

I have forwarded all the details to our testing team, enabling them to conduct a comprehensive analysis of this matter.

[Abhishek Dewan]

Hi @Bachsau

Upon a thorough investigation, we would like to share that at the moment, for security considerations we do not allow items from HTTPS domains to be utilized on HTTP domains. Nevertheless, users can continue to autofill on HTTP websites by establishing distinct items for the specific HTTP domain.

[Bachsau]

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.

Edited August 22, 2023 by Bachsau

[Abhishek Dewan]

Hi @Bachsau

I completely grasp your perspective and have taken careful note of your feedback for potential future deliberation. We appreciate your ongoing support in the interim.