Support For Domain Hashes

[jmzagorski]

General information

I am brand new to this library and had an idea/question.

I started hashing my pass directories in the event my system gets compromised and the person gets the urls for my acccounts, even though my usernames and passwords are still encrypted (just adding one more step to slow someone down).

Would it be possible for this app to search the pass store using a hash/salt (or just hash) based on the domain?

Thanks for a great library!

[maximbaz]

Hey, that's a curious question. First of all, I think hashing without a salt has almost no value, just consider that most domains consist only of 5-6 English letters + one of a very few common suffixes (like .com), and in the bitcoin era 10M/sec is a very generous bruteforce underestimation rate regardless of the hashing algorithm that you use - most consumer-rate GPUs will give you much faster bruteforce. And even with 10M/sec, 26^6/10M = 30 seconds to generate all hashes of all possible domain combinations in the given range.

Second of all, it won't be easy to implement this feature. Supporting a salt would mean adding a configuration option to the extension (which is easy) and communicating it to the native extension (which we don't support, and seems like can only be achieved if #20 ever gets implemented). Then there is a choice of a hashing algorithm, where we must support some kind of a selector, and again, adding it to the options and communicating the value to the native host.

Personally, I think this is a feature request that is hard to implement and won't be useful to a majority of pass users (especially if they use CLI and/or a phone app in addition to browserpass, which don't know anything about hashing of the names), so I'd tend to close this proposal as won't fix - if there is demand, we can always reopen.

Let me know your thoughts on the above.

P.S. I'm just thinking out loud, but if you really want to keep the hashed file names, you can create symlinks that you don't publish anywhere - maybe you can write yourself a small script to generate such symlinks given the password store and a salt. What I mean is the following, suppose your password store folder looks like this (MD5 with no salt is used in the example):

.password-store-files/
    a5ed434a3f5089b489576cceab824f25.gpg
    8afa6b470053a63a5ee45cfe9a52b055.gpg

Make a script that using the folder above generates a second folder with only symlinks:

.password-store/
    google.com.gpg -> ../.password-store-files/a5ed434a3f5089b489576cceab824f25.gpg
    github.com.gpg -> ../.password-store-files/8afa6b470053a63a5ee45cfe9a52b055.gpg

Browserpass will understand symlinks!

P.P.S. You might be interested in a somewhat similar feature request, where it was proposed to put url: github.com in the file itself and respect that in addition to the file name. This cannot be implemented because the extension would then require to decrypt every single file in your password store in order to determine if this entry matches the url.

[ghost]

Would it be possible to have another configuration file to store the url, like custom_urls.toml:

[domain1.com]
custom.auth.com

[domain2.com]
*.auth.com

That is probably the easiest way to solve, aside from caching the entire database and updating on file system changes.

[maximbaz]

This is simpler to implement, that's for sure - no need to communicate some hashing algorithms and salt between browser extension and the native app.

My concern would be that this is a custom solution that is not common, not supported by CLI pass or phone apps, and manual way "(1) decrypt cutsom_urls.toml, (2) remember the <custom_file_name>, (3) run pass show <custom_file_name>" is too painful to do every time - so as much as I would like to anonymize file names, I personally wouldn't use such solution.

One more idea that I'm personally evaluating is to store the .password-store directory in EncFS or on a LUKS-encrypted drive (which can encrypt file names too), and put it in Dropbox. That way locally you still see the normal names, pass and browserpass work as expected with no extra configuration, but on remote you cannot see the directory structure. I know Android phone can decrypt LUKS drive, not sure if I can integrate the decrypted drive into the Password Store app though.

[jmzagorski]

@maximbaz, thank you for the reply. I agree, if there is no demand then there is no reason to waste time on the proposed feature. Plus, using your symlink example or keeping it all on a LUKS-encrypted drive will add more security to pass, which was the main purpose of my question. I've looked into the url feature you wrote about for my own personal use, but decrypting every file is not worth it. I've also tried other hashing algorithms that include more than the domain name (with a salt), but I will always have integration problems with other libraries unless I wrote my own. Since my pass drive is encrypted anyway, I plan to keep your file name convention since I really like the integration in the browser.

I will be interested to see how it goes with Dropbox. I have only started looking into a self hosted encrypted git machine just to keep my devices in sync.

[maximbaz]

A couple of relevant threads that I've just found:

• one - general discussion of this same topic, people also suggest EncFS, LUKS or git-remote-gcrypt.
• two - introduces a tool called pass-tomb, which is a wrapper over LUKS as far as I can tell.

I need my password store to be accessible via the android app, and right now neither EncFS, nor LUKS, nor git-remote-gcrypt are supported, so unfortunately for the time being I'm staying with regular folder that is leaking file names - I'm not putting it it in a public place anyway 🙂

But I really think that instead of inventing our own custom way of solving the issue, let's use the tools above that community recommends, and demand other apps (such as android app) to support them. Browserpass will obviously work with EncFS, LUKS and git-remote-gcrypt out of the box.

[jmzagorski]

:-) Thank you for those links. I have not been actively looking for third party apps until recently with browserpass and the Password Store android app, so I will check those out.

[maximbaz]

I shared the findings in the android app's issue, hopefully this brings some focus to the issue. I encourage you to upvote that ticket too 😛

As for this ticket, I'll close it as we agreed to not implement any custom solution and stick to the community's suggestions - EncFS, LUKS or git-remote-gcrypt.

[maximbaz]

Just a heads up, the next major version of browserpass will remember which passwords you used on which domains and show them next time in the popup.

So if you have a password entry called KDE Bugs.gpg and you navigate to bugs.kde.org, at first just like today browserpass will not show KDE Bugs among the list of passwords (to protect you from phishing attacks), however if you specifically search for KDE Bugs and use it to login, next time you open bugs.kde.org the entry KDE Bugs will be present in the popup.

So you will theoretically be able to use random names for your password entries 😄

[ghost]

Thank you and very much looking forward to the next version of browserpass. Where will it be saving the information and can it be easily backed up? Will there be a way to determine this information without using the browser, or a CLI wrapper to use it as well?

[erayd]

@braderhart It's stored (hashed) in the browser local storage as a JSON object. There is no specific method to back this up, but it can easily be copied out using the browser's developer console.

There is no way to easily obtain this without using the browser, and we do not provide a CLI wrapper for it.

[ghost]

@erayd Thanks for the info.