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 (anymore).
Cheers, Daniel 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 > <[email protected]>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 <[email protected]>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 >>> [email protected] >>> http://lists.zx2c4.com/mailman/listinfo/password-store >>> >> >> >> _______________________________________________ >> Password-Store mailing list >> [email protected] >> http://lists.zx2c4.com/mailman/listinfo/password-store >> >> > > > -- > Philip Chase * 352-575-0705 * Gainesville, FL > _______________________________________________ > Password-Store mailing list > [email protected] > http://lists.zx2c4.com/mailman/listinfo/password-store _______________________________________________ Password-Store mailing list [email protected] http://lists.zx2c4.com/mailman/listinfo/password-store
