HQJaTu

On 10/4/2022 at 1:39 PM, Bobsyouruncle said:

Workaround: Uninstalled then reinstalled Enpass from Android

I have Enpass Android with WebDAV sync.

When changing sync server password, the ONLY fix to get sync back was to uninstall and reinstall. All other platforms (macOS, Windows, iOS) worked without problems. Apparently any change on sync cannot be compensated with vault settings.

On 11/20/2021 at 5:40 AM, Mattchewie said:

I have a few services that I no longer will be using an app with and would like to remove the autofill info. I see it in an export but don't see it in the app. Figured I would ask

Disabling ?Enpass6AutoFill on URL-click would be my preference. Autosubmit Login -checkbox won't make a difference.

The part where Enpass servers retrieve the icon is clear.

What you, nor any documentation, doesn't mention is exactly WHERE are the icons stored at. If on my vault, it's more then strange for the icons not to stay on at the point where I uncheck the "use website icons" checkbox. If at Enpass, that's a clear breach of my own rules for privacy and I won't use that feature no matter how much it would increase my usability.

I'm speculating here:
Website icons are stored in my vault, but you botched the implementation. There are actually two operations hidden into a single checkbox: 1) Use, as in display and 2) Fetch.

For this feature to be useful, I would love to use the icons, but not to automatically get all of them (I have hundreds of entries in my vaults). To balance usability vs. privacy, I'd love to manually specify which icons should be loaded. Does this make any sense?

Website icons is a two-edged one for me. Having the favicon in the list makes anybody's life with many passwords sooooo much easier. On the other hand, there's the privacy issue.
#1 reason for me to use Enpass is the ability to have my OWN back-end to store the encrypted vault.

Since the value of customized icons is huge, I'm willing to enable the setting once.
That's as in one time. Then disable it, to protect my privacy and not let Enpass know any more of my sites, until I choose otherwise.

Can anybody guess what happens to icons ALREADY DOWNLOADED?! What!! Why!!

Yeah! 6.3.3 has copy-button next to password while editing.

That solves the problem. Thank you!

No change in 6.3.

Lots of confusion for the new Enpass-account, but no real change to allow copying of passwords while in edit mode.

8 hours ago, Red0210 said:

Ok, as you ask, I'll stay.

Thank you.

8 hours ago, Red0210 said:

First, of course I do change passwords. And I am using long cryptic passwords generated by Enpass.

Naturally.

I think that's the reason we love Enpass, it enables me to ignore the actual password. All I need to know is how to access the password and know that it is long and complex. Personally, I tend to go for waaaaaaaay too long passwords, 60+ characters if possible.

8 hours ago, Red0210 said:

I think I am getting now what your point is. Actually I also cannot copy the password while in edit-mode! So far I agree now with you. But I never came across this issue.

Nice!

8 hours ago, Red0210 said:

My personal flow of action is as follows:

- when I put the cursor in the "repeat new PW" field, the website normally tells me already if there is something wrong with the new pw
- if new pw is not accepted, I go to Enpass and press the "Again" button (circular arrow) in the still open Enpass Generate dialog. I repeat this as long until a pw comes up that is without the faulty character. Then I copy to the website and the new pw is accepted.
- only if the change is done successfully on the website, I klick on "Fill" and "Save" in Enpass. Only now the old pw is overwritten.
- end of action.

What you're describing there is a sunny-day-scenario. Your rainy-day isn't very realistic for me, as my passwords tend to be very long. I cannot keep clicking regenerate and wish for a lottery win. To get the job done, I need to edit.

Typical failures in password change include:

• Length: Some sites announce the max. length of a password, some don't. Some of those who doen't announce the max. length secretly enforce it. The "best" sites enforce the lenght limit by not telling you until next login attempt.
• Complexity: Some or none of the special characters are not allowed.
• Prohibited paste: There are web developers who don't care about your security. They insist you on typing the same password for all sites.

How I approach the above problems:

• Length: Since I never left edit mode, I can backspace some characters out of the generated password and go again.
• Complexity: I can remove some characters from the generated password, or go to generate dialog and uncheck special characters.
• Prohibited paste: Go for something sort with not-too-many special characters.

For an Enpass UX-designer/developer I'd love to hear what they have to say about password change process. Now we have two users voicing their approach. I'd love to see/hear how Enpass will help us users in that.

11 minutes ago, Red0210 said:

Sorry I have to drop out here. I am using Enpass different than you.

Ok.

If you wouldn't have left this conversation, I'd be curious about the exact steps you take to change a password. Given the circumstances, I guess I just assume you never change passwords and never need to copy passwords in edit-mode.

1 hour ago, Red0210 said:

I am not sure if I understand you right...

Yes. I get that a lot.

Did you:

1. Edit a entry having a password
2. While editing, copied first three characters of a password

I'm 100% sure you did not. If you would have done that, you would understand what I mean.

And I have to disagree. A password will be "destroyed" by overwriting it. This would happen when you either are forced to or decide to change the password. During the process of changing, you WILL need both the old and the new password at the same time.

Old version made password change process easy and smooth. This 6.20 does not.

On 10/21/2019 at 9:09 AM, Red0210 said:

I am using 6.2.0 on Windows Desktop, iPhone, and iPad, and the option to copy and test the new password is still there! See screenshot. Its in the upper right in the "Generate" window.

Sure. It is there.

Now start editing your entry. While editing, go to password and copy first three characters of it.

You cannot. Not anymore. Any password copying must be done using the copy-option you showed in your screenshot. This will effectively destroy the previous password in your database. What if the newly generated password won't be accepted and you need to re-paste the old password to retry the password change. You cannot. You just destroyed the old password information.

New 6.20 dropped password copying while editing. I observed same change in macOS and Windows 10 store versions. Maybe this affects also iOS and Android versions.

A typical workflow for changing an existing password is:

1. Copy old password using Copy-button, old password is usually required during change
2. Edit the entry
3. Generate new password
4. Click Show to reveal the newly generated password
5. Copy the provisional new password from edit field
   • Sometimes generated password isn't valid and manual editing is required. Reasons for this could be too long password containing invalid characters, etc.
   • At this point old password is not yet lost. It is possible to cancel the change.
6. On successful password change, Save the updated entry

IMHO returning the previous functionality enabling editing and copying the password is absolutely necessary.

With 6.20 update the problem seems to be gone. I'm not getting a flood of sync errors anymore.

2 hours ago, davidc said:

I don't know about that, I bought it on all the platforms, but it is clear there is a bug that is affecting more than one person i.e. is not user error. 

Ok. Windows 10 and macOS are free-of-charge. I happily paid for my iOS Enpass.

2 hours ago, davidc said:

 Enpass do you have a plan to fix this? Is there any debugging/logging anywhere at all that we can use to assist you?

So far customer support is simply managing expectations while giving polite "we will fix this soon". Other than that, past two months have been rather unfruitful.

Like David, also I'm ready to help any way I can.

This ridiculous bug is getting very annoying. If the sync fails, Enpass keeps retrying in a forever-loop spewing the 904035 love. It's like playing whack-a-mole. You dismiss the sync-error and quite soon it will pop out again.

On 7/22/2019 at 10:35 PM, davidc said:

One thing that is troubling me is that Enpass is making no efforts to inform me of a sync problem.

Yeah. The price of the product is right (doesn't cost a thing), but getting support for it can take quite a long time. Probably most users are going for commercial clouds and fixing WebDAV isn't a priority to Enpass devs.

On 7/8/2019 at 3:22 AM, Anshu kumar said:

Our dev team is working into this issue and hopefully a fix will be available with the subsequent update.

Thanks for that. I'll be looking forward for any new software versions which might address this issue.

Meanwhile, I managed to replicate the problem on  a laptop waking from sleep. There is no proxy configured, but this specific sync error will occur towards my WebDAV server. When that happens, sync attempt will continue forever without timing out. Since there is no Cancel Sync -button available to manually abort the forever failing sync, my fix is to quit Enpass and restart. Then the problem will be fixed. However, this does not happen every time after sleep wake. It happens often enough so, that I can confirm the failure.

1 hour ago, davidc said:

I can confirm that no proxy is in place at either end. If I have my desktop and my laptop on the same home network (both Windows 10), my desktop can sync fine with the WebDAV server but my laptop cannot (error 904035). Both are running Enpass 6.1.0 (407). I could not find any Enpass logfile.

Ok. Then its not the same case I have.

Quote

The certificate is accepted automatically in both Internet Explorer and Edge. It is signed by Let's Encrypt Authority X3 which is signed by the trusted CA DST Root CA X3. I have also verified that the server is sending the chain certificate from the command line.

That's what I experience. All browsers trust the certificate chain ok, but Enpass doesn't. It seems to have a certificate vault of its own.

2 minutes ago, davidc said:

I also use Let's Encrypt certificates. I'm not going to bypass certificate verification for obvious reasons!

I have exchanged couple emails with support and clarified my case to them, but haven't heard from them since.

The current theory is, that any HTTP-proxy, transparent or regular will cause Enpass to interpret things incorrectly.

Can you confirm:

• Storage backend. In my case its my own Linux box with the LE-cert using WebDAV. If you're getting this on a cloud provider, then it might be a different case. I know, most likely you wouldn't use LE-cert on those, but still ... covering all the bases.
• The target URL works ok and has valid cert on your browser. In Windows 10 check also Edge as is it will use system settings just like Chrome. Firefox won't use system settings.
• Is there is a proxy in use. A transparent proxy might generate a HTTPS-cert on the fly causing the issue. Your browser might accept the certificate root ok, but Enpass doesn't use your Windows 10 certificate storage at all.

It would help this case if you can share the above details on your setup.

1 hour ago, Anshu kumar said:

It would be a great help if you can share the demo account of your WebDAV via PM so that we can investigate where the problem could be and try to fix asap.

Thanks for your response. I'll move this discussion to PM with details.

Initial vault setup from own server goes ok. Something changed in version 6.0.5 (or 6.0.6) and now my Let's Encrypt certificate spits error on every sync. This is not happening on my Mac nor iPhone. Only on Windows 10 store version does that.

Fix is to disconnect. At reconnect select "Bypass SSL certificate verification". After that, everything works ok.

This is not a blocker, more like a nuisance. Early 6.x versions worked ok, but latest 6.1.0 does not. The obvious weird thing is, that the certificate IS valid and other platforms work ok.