[pass] Pass leaks password lengths through file sizes

Philip Chase philipbchase at gmail.com
Sat May 10 15:10:40 CEST 2014


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.zx2c4.com/pipermail/password-store/attachments/20140510/8d022af5/attachment.html>


More information about the Password-Store mailing list