gaetawoo Posted January 5, 2017 Report Posted January 5, 2017 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. 3
Vinod Kumar Posted January 10, 2017 Report Posted January 10, 2017 Hi @gaetawoo, Thanks for your time for writing a long list of suggestions and bugs. We have noted the same for improvements in future releases. However I would like to discuss first point separately: On 06/01/2017 at 4:46 AM, gaetawoo said: 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. Firstly let me assure you this is not a security bug. Unlocking by fingerprint is securely implemented in android OS and OS itself restricts a users after n number of bad tries. Nobody can enter inside Enpass without your fingerprint. In other words brute-forcing by Fingerprint is almost impossible. Even if someone knows your device code and tries to add a new fingerprint, Android will invalidate the Enpass fingerprint key immediately and master password will be asked next time. Please see more details here https://www.enpass.io/unlock-using-fingerprint-in-android-marshmallow-security/ On the other hand, if we delete the encrypted master password entirely on fingerprint authentication error (which sometimes happens with genuine users also for various reasons), it will lead to enable fingerprint support again from the Enpass settings and hence user inconvenience without any gain in security.
gaetawoo Posted January 10, 2017 Author Report Posted January 10, 2017 6 hours ago, Vinod Kumar said: Firstly let me assure you this is not a security bug. Unlocking by fingerprint is securely implemented in android OS and OS itself restricts a users after n number of bad tries. Nobody can enter inside Enpass without your fingerprint. In other words brute-forcing by Fingerprint is almost impossible. Even if someone knows your device code and tries to add a new fingerprint, Android will invalidate the Enpass fingerprint key immediately and master password will be asked next time. Please see more details here https://www.enpass.io/unlock-using-fingerprint-in-android-marshmallow-security/ On the other hand, if we delete the encrypted master password entirely on fingerprint authentication error (which sometimes happens with genuine users also for various reasons), it will lead to enable fingerprint support again from the Enpass settings and hence user inconvenience without any gain in security. @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.
mbrustad Posted February 8, 2017 Report Posted February 8, 2017 Hi, Item 2 in @gaetawoo post 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. Also exist when you choose to edit a password field of an existing record Samsung Galaxy S7 Edge, Android 7.0
rerx Posted February 25, 2017 Report Posted February 25, 2017 Hi, I am a new user of Enpass -- just trying the Linux and Android versions for the first time. I came to the forums because I noticed two issues on Android that gaetawoo already highlighted above. Quote 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. This definitely must be fixed ASAP! The fingerprint is a convenience feature, but it is much less secure than a secret like the master password. Fingerprints are quite easy to forge. If an attacker gets hold of my phone and if they are careful, they can already find a template for a fake fingerprint on the glassy surfaces of the phone. That's why Enpass should really reset to requiring the master password to be entered instead of a fingerprint after some time (like 30 minutes) has passed or after a reboot. As it stands now, one can only discourage all users from using Enpass with the fingerprint feature. Quote 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. I was really surprised by this behavior. The Swype keyboard just shows character after character in clear text in its suggestion bar, while entering the master password! This usually does not happen with password entry fields. It wasn't this bad with the stock Sony Xperia keyboard on my phone. Please fix these security problems! Apart from these issues Enpass really looks to be the nicest cross platform solution I have seen so far. 1
gaetawoo Posted February 27, 2017 Author Report Posted February 27, 2017 On 1/10/2017 at 2:59 AM, Vinod Kumar said: Hi @gaetawoo, security. 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. 1
Vinod Kumar Posted February 27, 2017 Report Posted February 27, 2017 Hi @rerx and @gaetawoo, Thanks for writing in. We do confirm the bug in the password field. It got introduced in a version which allowed to see passwords by tapping on eye button while editing. Our tests runs use standard Google Keyboard and so the issue was not spotted earlier. We have fixed this issue and will release an update soon. As I mentioned earlier, the current Fingerprint implementation in Android is a very secure. Though in iOS we switch to Master password after three wrong attempts from Touch ID but security wise no such requirement arises in Android. A person having possession of your fake fingerprint can unlock your phone and can do lot of nasty things (including get into Enpass in first attempt after unlocking device with that). If one is super sensitive about this, he should not turn on Fingerprint from Enpass (which is by default, off). We always consider you valuable suggestions, which is why Enpass reached so far. We will consider to implement your suggestion for Fingerprint disable as an optional setting in future. Cheers,
gaetawoo Posted February 27, 2017 Author Report Posted February 27, 2017 @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. 1
Recommended Posts