[pass] Pass leaks password lengths through file sizes

Daniel Schoepe daniel at schoepe.org
Sat May 10 15:21:44 CEST 2014

Most of my entries consist only of the password itself; the main
exceptions are websites that use a separate username that I might not
remember, instead of just the email address, but that's not so common


On Sat, 10.05.2014 15:10 +0200, Philip Chase wrote:
> Do people commonly store only a password in their password store DBs?
> I don't think a single one of my password store entries is a simple
> password. Generally they include a username or email address.  Often they
> include the security questions and answers used in password recovery
> methods.  This adds a lot of "salt" to the length.  I doubt anyone would
> get any advantage from a length-based attack against my database.
> Do you think my use case of extra content in each password store file is
> normal?
> Philip
> On Sat, May 10, 2014 at 8:47 AM, Mikhail Gusarov <dottedmag at dottedmag.net>wrote:
>> Adding a trailing line with a random number of space characters also can
>> help.
>> Best regards,
>> Mikhail Gusarov.
>> On Sat, May 10, 2014 at 2:44 PM, Daniel Schoepe <daniel at schoepe.org>wrote:
>>> Hi,
>>> one reason for using a password manager that encrypts its password
>>> store is to avoid to keep the passwords safe even if the password store
>>> itself gets into the wrong hands (e.g. if a laptop is stolen and the
>>> user didn't use hard drive encryption).
>>> However, at the moment pass seems to leak the length of the passwords
>>> through the file size of the stored passwords. As far as I can tell
>>> the file sizes vary based on the length of the GPG key that is used,
>>> but are only dependent on the password length otherwise.
>>> For example, a one-character password encrypted with a 2048 RSA key
>>> results in a file size of 324 bytes, a five-character password generates
>>> a file that is 328 bytes long, etc.. I tested this with two different
>>> 2048 bit keys.
>>> Similarly, for 4096 bit RSA keys, password file sizes start at 580 bytes
>>> and increase by one byte per password character as well.
>>> If an attacker gets his hands on a password store, this could be
>>> problematic since it decreases the search space for passwords
>>> considerably; especially if they have some offline method of
>>> bruteforcing passwords (e.g. if they obtained the hash of a user's
>>> password from some database).
>>> I think this is an issue and should be fixed, even though all the fixes
>>> I can see would detract from the simplicity of the current implementation.
>>> One way to remedy this is the following: When adding a new password one
>>> could generate a random number of bytes and append that, along with
>>> information on how many junk bytes were added, to the entry and discard
>>> them when reading the password. This has the disadvantage of the files
>>> no longer being easily readable/usable without pass.
>>> I'd like to know if others also think that this is a security issue and
>>> if there are better ways of fixing it.
>>> Cheers,
>>> Daniel
>>> _______________________________________________
>>> Password-Store mailing list
>>> Password-Store at lists.zx2c4.com
>>> http://lists.zx2c4.com/mailman/listinfo/password-store
>> _______________________________________________
>> Password-Store mailing list
>> Password-Store at lists.zx2c4.com
>> http://lists.zx2c4.com/mailman/listinfo/password-store
> -- 
> Philip Chase * 352-575-0705 * Gainesville, FL
> _______________________________________________
> Password-Store mailing list
> Password-Store at lists.zx2c4.com
> http://lists.zx2c4.com/mailman/listinfo/password-store

More information about the Password-Store mailing list