gaetawoo

Same thing has been happening to me on Windows 10 in the last month. Windows 10 19045.3448 Enpass 6.9.1 (1515) The mini widget and web widgets still work without issue, but opening the main app window, it shows that SESSION EXPIRED message and sends a code to my email. It won't let me use the window until I authenticate. Once I do, then it says it's disconnected from my cloud sync. So I have to reauthenticate that too. This has happened twice this month and it's very irritating. FIX IT please.

No idea what to do with this.

@Anshu kumar On windows Desktop program, the Box.com sync option doesn't actually work. It never logs in. When I select it, it opens an authentication window in my browser, I log in, grant access, and it says it wants to open the next link in the Enpass desktop app, I say ok. and then in the enpass app, the loading animation just keeps... loading/spinning. It never works.

This is great news! But how would it work with the Brave Browser on android? which is based on chrome but seems to obfuscate the current domain from Enpass currently. I have to search for my credentials each time and when I select one, it asked "Do you want to add brave.com to your URL for this login" or something like that. Seems like that issue is likely with Brave and not Enpass but it's irritating all the same, especially since I don't want to use a Google branded browser.

Sometimes I've come across a website that will reject the autofill for the password field. The login screen appears, the autofill notifications appears, I click it and select the matching credential that shows up, and it proceeds to autofill but the website automatically clears the password field after autofilling. What would be great for situations like this and other situations, is that instead of granting ZERO access to any details of each credential during the autofill process (other than selecting which one to use for autofill) allow a button on the right of each entry to be able to open that credential to see and copy each detail of it... just like it does when you view them in the normal app. That way you can easily copy and then manually past the password or whatever other information without relying on the autofill system. Otherwise, one has to leave the browser or app, open the Enpass proper, then find the credential, open it to the details view and copy it there, then go back to the previous app. Instead, this could all be allowed to be done from within the autofill notification process. Just let us access the details, instead of not. Simple.

Sometimes I've come across a website that will reject the autofill for the password field. The login screen appears, the autofill notifications appears, I click it and select the matching credential that shows up, and it proceeds to autofill but the website automatically clears the password field after autofilling. What would be great for situations like this and other situations, is that instead of granting ZERO access to any details of each credential during the autofill process (other than selecting which one to use for autofill) allow a button on the right of each entry to be able to open that credential to see and copy each detail of it... just like it does when you view them in the normal app. That way you can easily copy and then manually past the password or whatever other information without relying on the autofill system. Otherwise, one has to leave the browser or app, open the Enpass proper, then find the credential, open it to the details view and copy it there, then go back to the previous app. Instead, this could all be allowed to be done from within the autofill notification process. Just let us access the details, instead of not. Simple.

@Vinod Kumar just become someone can unlock ones device with the fingerprint doesn't mean that you can't make a more secure implementation than android itself does for the ENTIRE database of credentials stored for an Enpass user. No one is arguing about the security of the fingerprint key itself. The whole issue is that you can use the fingerprint to initialize Enpass which is WRONG WRONG WRONG. You should require the master password for the FIRST unlocking of Enpass after having been killed or the device restarted. Just like it is with a PIN. Even Android itself does NOT allow you to unlock your phone with your fingerprint after a reboot or starting the device. It requires a PIN or Password. And I could easily argue that access to the phone itself is not NEARLY as bad as access to the ENTIRE database of secured passwords and other information held in the Enpass database. So please reconsider, because your reasoning is very poor indeed. It sounds more like laziness to me than care for the security of your customers and product. Remember, we are paying customers, some at $10 or $20 dollars. We are not free-loaders. Dismiss your paying users' concerns at your own peril.

Hi @Vinod Kumar as others here have said, these are pretty major issues for a security app company. Please prioritize these fixes and get an update out as soon as possible.

Yes, this is a very dumb way to handle password changes. One short cut around this if you are aware of it is to change the local app's master password before trying to sync, then you just do it the once, but really, it should change it everywhere when you update the sync password. It just leads to confusion for the user. Makes no sense. It's so frustrating. Enpass has so much potential, and already does such a great job with things, that if they only put a little more thought into it, it could be truly excellent.

@Vinod Kumar I am certainly not one of your programmers, but from a logic point of view, it's very clear to me what the solution is. ALWAYS ALWAYS ALWAYS require the typed Master Password for the initial load of the database (after the phone boots up, or after the app is opened from being force closed, whatever). Always. ONLY AFTER that has happened, should Fingerprint support be available. This is exactly what you do with the PIN method. If the PIN is wrong EVEN ONCE, it forces you to use the Master Password. If you force close the app or reboot the phone, you don't get a chance to enter your PIN first, you MUST enter your Master Password. There is no reason it should work EXACTLY the same way with the finger print. My concern is not a brute force attack or someone trying to add a new fingerprint. My concern is 1. an inconsistent methodology of security so users cannot expect the same level of security. 2. being forced to open the database with your fingerprint. Of course, having fingerprint access is a user's choice and if they make that choice they need to know the risks involved. But ENPASS is making those risks far worse than they need to be, and far worse than they are simply with the other PIN approach, it's crazy. If someone gets me and my phone, and forces the use of my fingerprint, they can unlock my phone, and now they can get into my Enpass database. They have unlimited tries, because ENPASS (as you are explaining to me) will NOT apply the same level of logic of security to the fingerprint (which is already less secure than the PIN) that they are already using for PIN quick unlock, namely, requiring Master Password on every initialization of the app and requiring Master Password after the failure of the fingerprint authentication (without some time our or reboot, or app close and restart to reset the ability to fingerprint authenticate). Surely you have to understand how ridiculous this is. Future more, it's a concern for law enforcement which is legally able to make you unlock with your fingerprint. My entire point is not to blame Enpass for the inherent security risk of Fingerprint authentication (it's better than nothing and very convenient) but it's to blame Enpass for employing a worse level of security for the fingerprint quick unlock compared to the PIN quick unlock, IN THE SAME SOFTWARE. All I am asking is 2 things. 1. Force EVERY initialization of the app to require the Master Password by keyboard (just like you already do with the PIN quick unlock) 2. After a failure of fingerprint authentication, force the input of the Master Password by keyboard, never allowing fingerprint authentication again UNTIL the Master Password has been correctly entered first. THAT'S ALL YOU HAVE TO DO to make Fingerprint quick-unlock a FAR FAR FAR FAR FAR more secure method than it is and put it on parity with PIN quick-unlock. I don't see why this can't be done programmatically in your app. with If/Then statements. If I fail fingerprint authentication now, it doesn't delete my encrypted password, and I can just type the master password in with the keyboard (or I can force close the app or reboot the phone to try the fingerprint again). Instead of all that, just have the app say when the fingerprint authentication is allowed. Again, literally just like you are doing it now with PIN quick unlock.

Sorry forgot to tag you @Ivarson

That's a fantastic answer, and frankly, I wish you would go on for longer, giving your best practices and tips and tricks. Here's my thing... I'm basically in charge of most of my family's important matters, so my wife doesn't know many of the details. And when she would know some temporarily, she'd forget over time. That's the main reason I've switched to Enpass, to co-locate. You bring up some great points, about remembering the PIN and stuff like that. But that's where I wonder what to do because my wife doesn't know all my pins, and if I get hit by a bus, that's that. My master password is one that howsecureismypassword.net says would take a computer 1 SESVIGINTILLION YEARS to brute force. So there's that. I do have 2FA with another app so they aren't in the same keystore at least (even if I can access both on the same device). Maybe a good idea would be to not generate passwords for accounts that have 2FA and just have memorable passwords for them and not store them, but that means my wife, should she need access, couldn't get access if I'm not around or i'm ded. It's this kind of stuff, navigating the compromise of security, convenience, and accessibility that is so hard, and frankly I'd consider myself new and green to the ideas and best practices of security. Having separate wallets is an interesting idea, maybe one for logins and one for life information (bank, cards, things to know or remember..) but again that adds complexity, for good and bad. So many complex decisions, especially when I'm the one that knows most things and I'm trying to make a way for someone else to have access to them if the need arises.

Right now, I have Enpass on two different Windows devices (and an Android device but let's leave that out for the moment). The keystore is backed up to Box automagically. Starting condition is that devices and keystore have the same Master Password. On device A, I change the Master Password, which changes it for the local A device and for the synced backup. On device B, I cannot sync unless I give the NEW sync Master Password (from A). However, once it is synced, the Master Password of the device B is still the old password from before. This is totally unintuitive and MUST be changed. If you went through the trouble of updating the Master Password on device B to sync the keystore, it should AUTOMATICALLY change the device's Master Password. But currently it does not. I have to go into settings and once again change the Master Password on device B (which again changes it for the synced backup (but this time the password is the same as it was before (new A password) so you don't have to go through this cycle one more time on device A)). It's all a terrible mess. And add a mobile device into this and it's again even worse because all that I just said applies. You have to put the new password in to sync, and then you have to manually change the local password to match the new sync password you already entered. Terrible terrible user experience and NOT intuitive at all.

I'm curious... how wise is it to store so much of one's information.. like bank account info, payment and identification information... On one hand, if you have all your logins stored in here... most of that stuff is available through that... so is it any worse to store it outright? I mean, if someone gets a hold of your database and cracks it, it's kinda over isn't it?

Here is the email I sent support. I'd love some community feedback and support feedback: I have a Nexus 6P running Android 7.1.1. The following are my bugs and requests: 1. SECURITY BUG: Rebooting the phone does not cause Enpass to require the Master Password to unlock the app. I can use a fingerprint. Even after fingerprint is locked out for 5 bad tries and the Master Password is then required, if I reboot the phone, I do NOT need to enter the Master password, i can use my fingerprint. That's a security risk. UPDATE: An EVEN WORSE SECURITY RISK is that if you get the fingerprint wrong 5 times, and it requires the Master Password, you can simply go to Android settings --> Apps --> Enpass and FORCE CLOSE the app, start it again and it will accept your fingerprint again. THAT'S HUGELY WRONG! This is EXACTLY why the first load of the app MUST ALWAYS require the Master Password which it DOES NOT do right now. 2. SECURITY BUG: When entering Master Password on Android for the first time after installing the app (in order to sync the database), the typed characters show up on the keyboard prediction bar, which means that text entry field is NOT coded as a password field (which would not show the characters in the keyboard prediction box). It's just an obfuscated normal text. Some keyboards automatically saved typed words or entries. Or someone may be peeking and see the entire password typed out in the keyboard box even if it's obscured in the field. 3. USABILITY BUG: I have notification form-filling turned on, and when I'm browsing in my chrome based Brave browser, Enpass NEVER recognizes the domain of the page i'm currently on. It always says brave.com. And after I search for my login info and select the right one, before it fills is asks if I want to add brave.com to my list of URLs for that account. So either Brave browser is not letting Enpass know what the domain is, or Enpass is not pulling that information correctly from Brave. I know it works with Chrome, but not Brave. 4. USABILITY BUG: There is no way to auto-add a new login account to the Enpass database, as there is with the desktop version and browser extension. This is really crappy and inconvenient. 5. FEATURE REQUEST: Make a view that shows only the TOTP codes for the accounts that have it, which is clear and easily accessible and visible, just like Google Authenticator or Authy. It just occurred to me that it is pointless to have TOTP on the same database as the passwords. Defeats the purpose of 2 Factor Authentication entirely. 6. FEATURE REQUEST: When entering Master Password, especially on Mobile where mistakes are easy, but also on desktop, make a peek button that allows the user to see what they've typed so if there is a typo, you don't have to start over again with very long passwords. It wouldn't have to stay visible, but a button that when you are actively pressing it, the characters are visible, and when you let go, they are obfuscated again, so a quick tap gives a quick and secure peek. This would be SUPER helpful. 7. FEATURE REQUEST: Allow for files, images, etc. to be included in entries. 8. FEATURE REQUEST: Allow for line breaks in the TEXT field (different from the NOTES field). 9. FEATURE REQUEST: Allow type SECURE NOTE and the NOTE field to be obfuscated (hidden). 10. FEATURE REQUEST: Allow for a toggle to not ask whether a certain domain should be added to the URL list for the account (which it ALWAYS does using the Brave browser on Android). 11. INTERFACE BUG: When I long press on an account, it shows the DELETE option but not the COPY USERNAME option. When I tap on the overflow button for the account (three dots to the right) it does not show the DELETE option and does show the COPY USERNAME option. But all the other options are the same. This is inconsistent and they should probably be identical. Thank you for the app, I've enjoyed using it so far and I see a lot of great potential. Well worth the purchase price. But PLEASE address the security flaws immediately.