bdl

On 10/27/2022 at 10:10 PM, Abhishek Dewan said:

Hi @mrc247 @ithinkiam

I can certainly understand your disappointment in this matter.

We tried to reproduce the bug on our end but our testing team could not replicate it. Kindly try the below steps once and share your findings with me -

1. Take a backup of the Enpass Data
2. Erase Everything
3. Restore using the backup file
4. Sync the Vault with the Dropbox Account.

Your cooperation in this case is appreciated.

Am having the same issue, same version, etc. I have also tried Disconnecting and get the same result as others here ("nothing happens"). I've also tried deleting Dropbox's sync'd Application/Enpass folder (no change), and also tried enabling wifi sync with my phone ("error while enabling sync").

I then backed up my vaults, and reset Enpass via the "Erase Everything", restored the vaults and re-enabled Dropbox sync. Though it's annoying to have to do, fortunately that seems to have restored syncing.

I had to export a bunch of password records from Enpass to CSV (and then to another password manager app;  though I'm still using and prefer Enpass for my own stuff!).

Here's how I did it:

1. Move all the to-be-exported records to a new vault (yay, Enpass 6's support for multiple vaults); I ought to have done this when upgrading to Enpass 6 from 5
2. Use the Enpass app's File > Export feature to export the vault as a JSON file
3. Use the `jq` script below to convert the JSON to a CSV file

The conversion isn't entirely lossless - the new app / CSV import doesn't support attachments, and metadata such as timestamps, credential history and record types are lost (e.g. the destination app only supports three record types, nowhere near the flexibility of Enpass).

Enpass' flexible schema is great but when it comes to trying to shoehorn that into a simple CSV it's a bit of a squeeze. In this case, the  CSV file had to be of the form:

Folder,Title,Login,Password,Website,Notes,Subfolder,Custom Fields

Where "Folder" is a fixed string (e.g. "enpass import"), and title, login, password, website and notes map to the Enpass record's title and so on (there's an important nuance here that I'll get to in a moment). I'm ignoring the Subfolder (set it to a fixed "" in the CSV), and finally Custom Fields is a list of arbitrary key,value pairs that will get stored as such in the new app.

So, seems straightforward: extract the relevant fields from the Enpass JSON export, print them in the right order, and Bob's your Uncle.

Not so.

Problem #1 is that Enpass' is mightily flexible: you could have zero, one or a dozen "username"s associated with a record, ditto passwords/other secrets, and let alone other data such as phone numbers, TOTP codes, arbitrary text fields, etc. (Aside: as far as I can tell none of the schema is documented by Enpass...). Plus you could have attachments, and finally records that don't have any fields at all (e.g. a secure note). This makes processing the JSON a little complicated.

Problem #2, related to #1, in that you might have data in Enpass that just doesn't fit in the above CSV, for example security question and answer pairs. You don't want to lose these, so they should be included as Custom Fields in the CSV. Alas not everything is going to make it across - e.g. attachments, where the target CSV just doesn't support 'em in any meaningful way.

Fortunately there is an awesome tool available for slicing and dicing JSON data - jq. And here's a jq script that will finagle an Enpass vaullt exported in JSON format to the above-mentioned CSV format:

• for each Enpass record, it copies over the record title and notes fields; for the login/password/website triumvirate it looks for Enpass fields labelled "Username", "Password", and "URL" to map over to the CSV; if it can't find a field it leaves it blank
• any other fields that contain content get stuffed in to the Custom Fields list
  • that is, it should retain all field data, though a password field labelled "Secret" will turn up as a Custom Field, not in Password

% jq -r '[
.items[] | [ . as $item 
  | {"Username": "", "Password": "", "URL": "", "E-mail": "" } +
    ( [(.fields // [])[] | {(.label|tostring): .value}] | add )
  | . as $all_fields
  | delpaths([["Username"], ["Password"], ["URL"]])
  | . as $rem
  | "import", $item.title,
    $all_fields."Username", $all_fields."Password", $all_fields."URL",
    $item.note, "",
    ($rem | to_entries[] | select(.value | length > 0) | [.key, .value][]?)
] ][] | @csv' < enpass.json > other_app.csv

I'm not going to try an explain that in blow-by-blow detail here, but suffice to say it deals with the fact that not every Enpass record has all the required target CSV fields (lines 3-5) or even has a fields list at all (line 5). It also has to deal with dumping out exactly the first few fields ("Username", etc) in exactly that order - even when those fields are not present in the Enpass input - then "all the rest" of the fields. It does that by merging (adding) a "default" object with each `fields` objects (line 4), and stashing that merged object away in `$all_fields`. Next it deletes the keys associated with the fixed part of the CSV output to leave only the remaining objects (i.e. "all the rest", destined to become the Custom Fields) in `$rem`. That takes us to line 7 if I'm counting right.

From line 8 we get to start spitting data out, constructing an array of fields: first a fixed string "import", which is the folder in the new app where the imported data will end up. Also the item/record title here, lifted directly from the corresponding field in the Enpass JSON.

Next comes the username through URL from the $all_fields object we stashed earlier. Then the item note (direct translation), and an empty field (don't care about sub-folders).

The next little bit has to take the remains, the `$rem` object, and gather every non-empty field (every label:value pair where the length of the value string is > 0) and then turn that into a flat list of "Key", "Value" pairs.

Finally the whole array's closed out, expanded and fed to the CSV formatter. Note the use of the `-r` command argument to emit raw (non-escaped) output.

Easy, eh?

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.

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/

@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).

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.

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?

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!).