Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

3 Neutral

About bdl

  • Rank
  1. In the last couple of days enpass occasionally opens to an empty item list, as when the app is first installed and devoid of all my data. After a short panic attack, I've found that restarting enpass restores everything. enpass 5.6.3 (139) on macOS 10.13.4 (17E199) Seems to occur when enpass locks after the idle timeout.
  2. https://www.enpass.io/docs/ returns a "hello world" page. It'd be a better look, and more helpful, if it pointed to say https://www.enpass.io/support/
  3. @Bill Rossum: the challenge-response mechanism isn't U2F (that's targeted to web authentication). From what I can tell the Ledger device does support a challenge-response mode (used in the Windows Hello authentication feature), so I guess enpass could support that - or someone could write a Ledger app to emulate the Yubikey-style challenge-response protocol: https://github.com/Yubico/python-yubico/blob/master/yubico/yubikey_usb_hid.py#L491. The latter would be better as it'd give you support for all the other services that use Yubikey challenge-response (e.g. the PAM module, LUKS disk encryption, etc).
  4. Some hardware auth tokens such as Yubikey support a challenge-response mode. i.e. you initialise the token with a secret which is henceforth only available to the token (backup of the key excluded). You take the user's password and send it as the challenge to the token, which calculates a HMAC using the key and returns the response, which is used as the database password. e.g. https://sourceforge.net/p/passwordsafe/discussion/134800/thread/7463e2a3/#7e4e It'd be neat if enpass supported this.
  5. G'Day Akash, I'm not referring to the usual "please support U2F / TOTP", rather I'm suggesting a change to the key management mechanism / KDF to support multiple key slots (e.g. Linux's LUKS supports 8 independent keys), and further for one of those slots to be an OTP. Having said that, of course there's nowhere enpass could store the OTP seed/counter/etc so I'll belatedly admit that that's a silly request. Another approach would be secret splitting: again, where the database supports multiple slots, one of those could be split (e.g. http://point-at-infinity.org/ssss/) and distributed to trusted people. Some number of these people would need to collaborate to recover the full key and access the database. As to storing the key offline: sure, but that has a bunch of issues incl. making key rotation a pain in the backside. Though if there multiple key slots that'd be easier to manage. So I suppose in an initial form, this feature request is really "please support multiple keys for accessing the database" with a bonus of "support secret splitting". I'm not entirely certain on how enpass uses sqlcipher - perhaps these feature requests should be for sqlcipher?
  6. Emergency access / disaster recovery - one-time-pad? One very handy feature of modern password managers (and cloud services such as Google's Inactive Account Manager) is that of "emergency access" for disaster recovery. You provide some sort of gated access to your data to trusted contacts such as your family, or business partners in the case of business passwords, and in the event of your untimely demise or incapacitation they can gain access to your data. The gated access part is usually a period of waiting where you are notified of the impending release of the data and have an opportunity to deny it. In Enpass' case, it'd be really neat to have a set of one-time-pad passwords that I could print out and stash somewhere safe that my trusted persons know about, and can use to access the enpass database. I can check whether anyone's stolen a one-time code by checking the next unused code (if it doesn't work, someone's used it!).