Midnight project: Password manager without a password manager • Hacker News Board

Re: Midnight project: Password manager without a password manager

#41

Post by pwg » Mon, Aug 13, 2012, 10:36 PM UTC

lloeki wrote: post #38

pwg wrote: post #26

Earlier quoted context omitted.

> Do we know if all password managers are written in such a way that they generate independent salts per password? Because password managers must store __the password__ itself (in order to be able to submit it into login forms and the like) the use of a salt for each stored password would work against the aim of storing __the passwords__ themselves. Instead, password managers store everything in encrypted form using…

How hard is it to get the master password when one knows 1. the encryption method 2. the encrypted password 3. the decrypted password ? (I don't have the foggiest idea about it, really)

> How hard is it to get the master password when one knows 1. the encryption method 2. the encrypted password 3. the decrypted password ? (I don't have the foggiest idea about it, really)

If your password manager encrypts each password separately, and stores that output separately, then that simplifies the task, because you can mount a known-plaintext attack and potentially reduce the complexity.

However, if your password manager stores things correctly, all the passwords are stored as a single "blob", with no known-plaintext anywhere in the blob, and the entire blob is fed through the encryption algorithm as a single block encryption using a single key.

For example, the password safe format ( http://passwordsafe.svn.sourceforge.net/viewvc/passwordsafe/... ) the master password is both salted and passed through a work-configurable key stretch function. The result of that operation is used to encrypt a 256bit random key using the Twofish algorithm. That 256bit random key is the actual encrypt key for all the password records, again using Twofish as the encryption algorithm.

So deriving the master password is made difficult by use of the key-stretch function, and deriving the actual 256bit random key is as difficult as otherwise breaking the Twofish algorithm.

Re: Midnight project: Password manager without a password manager

#42

Post by pwg » Mon, Aug 13, 2012, 10:44 PM UTC

EGreg wrote: post #40

pwg wrote: post #28

Earlier quoted context omitted.

> In our formulation, the salt was simply (a function of) your username. For password hashing, the input salt needs to be a cryptographically secure random number. This is because it needs to be unique, and unrelated, to each password. In your "formulation", what you have is simply a unique identifier for a user derived from the three, but it is in no way a "salt" as that term is used in regards to "salted passwords"…

on websites, usernames are unique, and they are usually unrelated to passwords on a related note, we encourage each of our users to select a passphrase, and even scour yahoo news from the past year, and other sources for three consecutive words, that the user can easily remember, such as "that truck driver" or "what he did". This in practice causes users to have a much better space of possible passwords to begin with…

>encourage each of our users to select a passphrase, and even scour yahoo news from the past year, and other sources for three consecutive words, that the user can easily remember, such as "that truck driver" or "what he did". This in practice causes users to have a much better space of possible passwords to begin with

And with a wordlist of the 10,000 most common words, if you are not also using a key-stretch function (bcrypt, pbkdf2, etc.) all of those examples become quite trivial to a john-the-ripper ( http://www.openwall.com/john/ ) type attack. I.e., a three word phrase consisting of one each of the 10,000 most common words has at most 10000^3 combinations (1e+12). A 10 digit random password selected from letters, numbers, punctuation (94 digits) has 94^10 combinations (5e+19). 5e+19 is significantly larger than 1e+12)

Re: Midnight project: Password manager without a password manager

#43

Post by EGreg » Tue, Aug 14, 2012, 1:23 AM UTC

pwg wrote: post #42

EGreg wrote: post #40

Earlier quoted context omitted.

on websites, usernames are unique, and they are usually unrelated to passwords on a related note, we encourage each of our users to select a passphrase, and even scour yahoo news from the past year, and other sources for three consecutive words, that the user can easily remember, such as "that truck driver" or "what he did". This in practice causes users to have a much better space of possible passwords to begin with…

>encourage each of our users to select a passphrase, and even scour yahoo news from the past year, and other sources for three consecutive words, that the user can easily remember, such as "that truck driver" or "what he did". This in practice causes users to have a much better space of possible passwords to begin with And with a wordlist of the 10,000 most common words, if you are not also using a key-stretch functi…

In theory, you are correct, of course. In practice, users do not select nearly close to 5e+19 unique passwords when asked to come up with a "random" password on their own. And if one is given to them, then it's inconvenient for them to remember 29c!8z79c. I would rather remember 5 words than 10 random letters, and 5 words would also equalize the space in your example.

Here is what I am pretty sure is true:

1) The salt just has to be unique enough to make rainbow table attacks on any significant portion of the userbase infeasible Any given rainbow table will only work for one salt. From this perspective, usernames are just fine as a salt.

2) The real danger is password re-use (http://xkcd.com/792/) and more generally, just lousy password selection (know anyone whose password is "password"?) Pass phrases are better (http://blogs.technet.com/b/robert_hensing/archive/2004/07/28...) and if we can deliver to the users a space of 10^14 possible phrases that actually sound like they make some sense, as an inspiration for them to choose a phrase of their own, then I think that's a good thing to do.

3) And of course, we use key strengthening, running the hash function a lot of times (a prime number of times, just in case ;)