Jump to content
Enpass Discussion Forum

Vinod Kumar

Enpass team member
  • Posts

    502
  • Joined

  • Days Won

    36

Posts posted by Vinod Kumar

  1. Hi @ButisitArt57

    On macOS, Enpass copies data to clipboard with a flag (org.nspasteboard.TransientType) that the data should not be recorded in pasteboard history due to sensitive nature of data. Only the clipboard managers that are not supporting this flag or configured to ignore this will save data to its history.

    Quote
    • org.nspasteboard.TransientType: This marker’s presence indicates content will be on the pasteboard only momentarily. The pasteboard will either be restored to previous content, or the current content will be replaced within seconds. Data marked transient should not be recorded or displayed in a pasteboard history.

    Maybe you should look for some settings in your clipboard manager to control the behaviour for this flag. However, we advice against it as your clipboard history might get stored on disk un-encrypted and defeat the purpose of having a password manager.

    Thanks.

  2. Hi @DesignT

    The json export format is made for a software tool to import, such as password manager by different vendor. If you want export your attachments as normal files, please follow these instructions:

    1. Select "Attachments" under "Others" section in Sidebar. This will show all items with attachments in the list.
    2. Select the items, right-click and choose "Export attachments"

    Cheers:)

  3. Hi @Ivarson,

    Thanks for bringing this into our notice. You are right we should have provided a better warning message.

    Icons are not treated as sensitive data and are for UI enhancement only. Obfuscating cache filename can avoid causal guessing but will not resolve the problem completely. Also, different devices resolutions, scrolling performance issues & complex updating mechanisms are few situation where we decided to avoid storing them in the main database. This was a trade-off decision we made than. Maybe it’s the time we look for alternate strategy that satisfy all the requirements.

    Thanks.

    • Like 1
  4. Hi @UdhayanithiG,

    Thanks for raising the question. The short answer is NO.

    The article mostly discussed about autofill extension of online password managers which injects their UI/chrome into web page and interact with their server. This additional chrome can be exploited by clickjacking or exposed server endpoints can be accessed by additional scripts because they live in the same shared space i.e. the webpage. Here are few points how Enpass is immune to such attacks:

    1. Enpass does inject only limited script to detect presence of forms that user may want to autofill. It does not inject any chrome/UI that can be clickjacked. The autofill UI is a separate process than the browser and immune to such attacks.

    2. The connection between local application and browser extension is authenticated by user via manual pairing mechanism by user and communication is encrypted with a shared key which malicious scripts can't access.

    3. Enpass, by default, requires user intervention before supplying any credential to webpage.

    In future, if Enpass introduce a feature that require additional UI injection in the webpage to increase user convenience that would certainly be inside the attack surface mentioned in the article. But be assured such a feature will be optional and you can keep Enpass extension in a configuration as it is today.

    Cheers:)

    • Like 3
  5. Hi @buyrsr,

    I understand your concern about availability of data. You can always export data from Enpass to json format, that contains complete details of your data that can be used by a software tool. Also, Enpass uses open-source SQLCipher for database file. Enpass derives a key from the master password with PBKDF2-HMAC-SHA512 100K iterations (outside of SQLCipher) and uses it as the raw key for SQLCipher. You can find few opensource implementations to read Enpass database file on github.

    Thanks.

     

     

  6. Hi @electrolund,

    I can understand the worry of our users after this incident. I would like to provide some explanation about delivery channels and tools we use:

    We have our own system to notify updates and distribution  apart from standard app stores. All Enpass builds are automated and scanned against virustotal service to eliminate human error.

    App stores:
    Most of the Enpass installations happens through Various App stores (Apple store for macOS and iOS, Windows store and Google Play store), that does not require any third party installer. Updates are also handled by corresponding App stores.


    Distributed via our website:
    All the download happens through our own servers only and over https. In-built updater in Enpass for macOS and Windows, check for integrity after downloading an update.
    1. macOS installer is built using standard pkg tools provided by apple.
    2. Windows installer is built using latest version of widely known Open source wix tools.
    3. Linux packages are distributed from our own signed apt and yum repositories.

    Let me know if you have other queries.

    Cheers:)

  7. Hi @Fab8

    Unlocking via PIN is more of a convenience feature rather than security. In case of PIN, Enpass restricts access to data through User Interface without locking down the database. After three failed attempts, the database will be closed and a master password will be required next time.

    20 hours ago, Fab8 said:

    In case someone gets acess to an unlocked Mac with enpass locked with PIN (instead master passwors):

    May it be possible that this person (that is is pretty much into IT / has former computer skills) could gain access to data saved in enpass?

    Your master password does not remain in memory any time after initial unlock of database. However, running sophisticated attacks with administrative privileges are still possible. We recommend against using PIN in such environments.

    :)

    • Like 1
  8. Hi @chrismin13,

    Thanks for your efforts to bundle Enpass for snap store. We are a short on team to handle all kind of packaging. We will give you explicit permission to redistribute our software for snap store. Please share your email id in PM.  

    As about other bugs, issue 1 can be resolved from our side by checking a Environment variable set by snap. Browser extension connection requires permissions to require system commands like readlink/netstat/lsof and a port open on localhost. Team is investigating the issues and possible fixes.

    Thanks,
    Vinod

    • Like 2
  9. Hi @Trendsetter,

    Password strength in Enpass is calculated using zxcvbn algorithm. Calculation by this method not solely rely based on length but depends upon different kind of patterns too. An additional character introduction may not necessarily result in increased strength if it introduces a pattern match according to algorithm. Please visit following link for more info.

    https://www.enpass.io/docs/security-whitepaper-enpass/miscellaneous.html#password-strength-estimation

    https://github.com/dropbox/zxcvbn

    Thanks.

     

  10. Hi @mschuppx1,

    You have mistakenly stored signing verification key file in apt sources directory. Remove invalid files with these commands on terminal and run apt update thereafter:

    sudo rm /etc/apt/sources.list.d/enpass-linux.key
    sudo rm /etc/apt/sources.list.d/wget-log

    Cheers:)

    • Thanks 1
  11. Hi all,

    Thanks for your inputs. Let us first have a look how biometric unlock in Enpass works, straight from our docs:

    Quote

    As soon as you enable Biometric from Enpass settings on your device, we create a Biometric authenticated, Enpass specific random encryption/decryption key in Android Keystore (accessible to Enpass only) and encrypt your master password using this key and store in private area in the device storage. This solution is highly secure because your master password is accessible only after it gets decrypted using the same key stored in the Android Keystore. And that key (in a usable format) can only be retrieved when you authenticate Enpass with your Biometric. This is so secure that even if someone gets access to your Android device passcode and legally adds his fingerprints in the phone, Android immediately invalidates all the encryption/decryption keys and makes them unusable. Even when in use, Enpass will detect this and will automatically disable Biometric in Enpass settings and removes your master password.

    The invalidation of keys is done by OS itself and there little Enpass can do. Certain custom ROMs and variants of Android OS invalidate TEE keys on reboot. On some devices you will not be able to turn on Biometeric setting in Enpass.

    Some ROMs also let you Enable biometrics without setting a Device PIN/Passcode first and that makes the TEE unprotected. If this the case with your device, please enable Device PIN/Passcode from device settings and share results.

    @Pete Have you been able to use Enpass on this device without this problem before 6.5 update?

  12. Hi @Jakob,

    1 hour ago, Jakob said:

    You should probably look into why it is prompting people for the permissions again.

    Whenever we add a permission to extension , Chrome shows the permission dialog with all permissions regardless of they are granted previously.

    There seems to be lot of confusion with our users on various support channels. So, we have taken back this fix (Chrome default autofill/autosave popup suppression) and released a new version without the fix. If this fix was important for you, please disable chrome built-in password manager manually.

    Thanks.

  13. Hi @MisterD and @RomanZ,

    Quote

    Read and change all your data on the websites you visit.

    This is the old permission you already provided to Enpass extension and is a must requirement.

    Quote

    Change your privacy related settings.

    Enpass extension will now suppress the annoying chrome save password popup if you are using Enpass extension for autofilling and saving your passwords. Hence, this permission is required.

    Cheers:)

  14. Hi all,

    Very important discussion going on here. We had this feature once in Enpass as a mandatory setting and we remove it after backlash from users (convenience wins over security:(). Meanwhile, I have prioritize this feature request and it will be available as an advance option just like 1password.

    Cheers:)

    • Like 2
    • Thanks 1
  15. 13 hours ago, Fabian1 said:

    3. Enter password yourself = currently best security. Or is there any evidence, that the current hack could read/log all keystrokes on the iPhone?

    Evidence is not required in this case. Keylogging, memory reading, screenshots and video recording are very much possible for a process with root privileges.

    13 hours ago, Fabian1 said:

    Do you store the clear text masterpassword in process memory of the kernel? 

    Enpass throws master password after using it but how does UI TextField handles memory internally, is outside of Enpass scope. This is an area we are dependent upon iOS security architecture. In future, we plan to use custom UI elements for text entry of master password as well just like we do it in Desktop versions.

  16. Hi @Fabian1,

    13 hours ago, Ivarson said:

    Enpass wouldnt sustain a root-level threat like that if being targeted. The security of an individual app cant hold up if security of underlying operating system is broken. 

    As stated by @Ivarson, Absolute security of an app is dependent on the OS itself. If integrity of operating system is broken and a adversary is able to run arbitrary code with root privileges, there is little Enpass can do to protect itself. However I would like to summarize, how Enpass stores its data and what happens if your use PIN or bio-metrics to unlock Enpass.

    All of your data is stored in a database encrypted using your master password. None of your sensitive data is decrypted and stored in any of temporary file, except when you need to export an attachment to external app. Access/oauth tokens to cloud services are also stored inside this encrypted database. So, a stolen Enpass database file is as secure as its master password.

    If you are using PIN to unlock Enpass or using bio-metrics on devices without secure enclave, master password is stored in the keychain in obfuscated (non-encrypted) form. In this case your master password can be obtained from keychain dump and adversary will be able to unlock your vault easily.

    If you are using bio-metrics to unlock Enpass on devices with (A7 and above chip), your master password is stored as encrypted data in keychain with a key stored in Secure Enclave of device. Modern iOS devices (iPhone 5s above) have Secure Enclave and encryption keys are stored in separate execution unit with its own processor and ram. As per Apple 

    Quote

    The Secure Enclave provides all cryptographic operations for Data Protection, key management and maintains the integrity of Data Protection even if the kernel has been compromised.

    It requires a very sophisticated attack to break into Secure Enclave. I have found no reference if the attack in question can lead to compromising of Secure Enclave too. So, your master password and hence all Enpass data is secure if Secure Enclave is resistant to the attack.

    Cheers:)

     

×
×
  • Create New...