5 ms·

I want a tool like this, but I don't think I can ever be ok with leaking meta data.

kame3d 6y ago
There's the pass-code extension for that: https://github.com/alpernebbi/pass-code https://github.com/alpernebbi/pass-code > A pass extension that obscures the filenames and folder hierarchy within your password store. > pass-code generates random filenames for each file in the password store and keeps the mapping in an encrypted file. This way, no valuable information is accessible even if your password store is leaked to the public (unless your GPG private keys were also leaked). Nevertheless, you should always ensure proper protection of your password store.
- nyolfen 6y ago
  pass-tomb as well: https://github.com/roddhjav/pass-tomb https://github.com/roddhjav/pass-tomb
progval 6y ago
It only leaks metadata to people/systems with read access to your password folder, which is very limited. Unless you share it with someone else or publicly (eg. Dropbox or Github), but then you're leaking a lot more metadata anyway.
Evidlo 6y ago
I wrote a pass equivalent for KeePass for this very reason [0]. It doesn't leak any metadata because everything is contained in a single file and it's compatible with the rest of the KeePass ecosystem. [0]: https://github.com/Evidlo/passhole/ https://github.com/Evidlo/passhole/
- dopidopHN 6y ago
  Hi, I keep reading that argument in that thread about the metadata being leaked and I feel left out of the party. How is it leaking? Why do we have to care and could some mapping of the file name to a encrypted key on map-table solve that ?
  - merlincorey 6y ago
    A common way to use `pass` is to store things like `organization/domain/username` so for example it might be `goldmansachs/github.com/alphacoder` which is telling us that you do some work for Goldman Sachs who store stuff on Github and your username is alphacoder.
cipherboy 6y ago
I'm thinking about adding encrypted file support to my pass wrapper, p, but I've not really found a good argument to support breaking mobile apps (such as https://github.com/android-password-store/Android-Password-Store https://github.com/android-password-store/Android-Password-S...). You'd have to manually look up the entries in a lookup table to resolve obfuscated names back to readable names... Or upstream support for whatever format is devised. I dunno.
- herewulf 6y ago
  I haven't used this app, but if the issue is a binary file where the app is expecting plain text, you could base64 encode your file. Maybe with some dummy password data. Then your arbitrary encrypted file is just another line in the plain text file.
dopidopHN 6y ago
I don’t really see the implication. Also, it’s would be trivial ( or not too hard ) to wrap the whole thing in another layer of encryption. Like a Vera crypt. But wait, actually I don’t really see what’s leaking. The name of the file that store the encrypted password ? How so?

There's the pass-code extension for that: https://github.com/alpernebbi/pass-code https://github.com/alpernebbi/pass-code > A pass extension that obscures the filenames and folder hierarchy within your password store. > pass-code generates random filenames for each file in the password store and keeps the mapping in an encrypted file. This way, no valuable information is accessible even if your password store is leaked to the public (unless your GPG private keys were also leaked). Nevertheless, you should always ensure proper protection of your password store.

nyolfen 6y ago
pass-tomb as well: https://github.com/roddhjav/pass-tomb https://github.com/roddhjav/pass-tomb

progval 6y ago

It only leaks metadata to people/systems with read access to your password folder, which is very limited. Unless you share it with someone else or publicly (eg. Dropbox or Github), but then you're leaking a lot more metadata anyway.

Evidlo 6y ago

I wrote a pass equivalent for KeePass for this very reason [0]. It doesn't leak any metadata because everything is contained in a single file and it's compatible with the rest of the KeePass ecosystem. [0]: https://github.com/Evidlo/passhole/ https://github.com/Evidlo/passhole/

dopidopHN 6y ago
Hi, I keep reading that argument in that thread about the metadata being leaked and I feel left out of the party. How is it leaking? Why do we have to care and could some mapping of the file name to a encrypted key on map-table solve that ?
- merlincorey 6y ago
  A common way to use `pass` is to store things like `organization/domain/username` so for example it might be `goldmansachs/github.com/alphacoder` which is telling us that you do some work for Goldman Sachs who store stuff on Github and your username is alphacoder.

cipherboy 6y ago

I'm thinking about adding encrypted file support to my pass wrapper, p, but I've not really found a good argument to support breaking mobile apps (such as https://github.com/android-password-store/Android-Password-Store https://github.com/android-password-store/Android-Password-S...). You'd have to manually look up the entries in a lookup table to resolve obfuscated names back to readable names... Or upstream support for whatever format is devised. I dunno.

herewulf 6y ago
I haven't used this app, but if the issue is a binary file where the app is expecting plain text, you could base64 encode your file. Maybe with some dummy password data. Then your arbitrary encrypted file is just another line in the plain text file.

dopidopHN 6y ago

I don’t really see the implication. Also, it’s would be trivial ( or not too hard ) to wrap the whole thing in another layer of encryption. Like a Vera crypt. But wait, actually I don’t really see what’s leaking. The name of the file that store the encrypted password ? How so?