[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-id: <F79E0320-2955-437A-B151-AEAA4DFAAA91@me.com>
Date: Tue, 10 Apr 2018 17:43:56 -0400
From: Arnold Reinhold <agr@...com>
To: passwords@...ts.openwall.com
Subject: Re: keyed hash vs. encryption
> On Apr 3, 2018, at 7:06 AM, Solar Designer <solar@...nwall.com> wrote:
>
> Arnold,
>
> I think we're mostly in agreement on this, except that I dislike the
> idea of ever suggesting completely giving up on even slightly costly
> hashing (where it probably doesn't translate into extra monetary cost
> due to use of pre-existing resources) due to use of HSMs. I'm all for
> HSMs where practical, but as an addition, not an alternative.
I basically agree. If and when hardware protected password storage become the norm, costly hashing may seem an unnecessary redundancy, but the future will sort that out.
> ...
>> I looked at the yescrypt page. There are a zillion options. Great if you know what you are doing. Not so great if you are an ordinary developer. If I see a website that just says "We proudly use yescrypt" what does that tell me useful about security, nothing I'm afraid without details on the parameter settings.
>
> Right. Ditto about "We proudly use PBKDF2" or scrypt or Argon2, for
> that matter. Only bcrypt is a bit of an exception, due to it imposing a
> minimum cost of 2^4. Even with bcrypt, you wouldn't know whether they
> properly generate salts, though.
There is some public awareness about repetition factors for PBKDF2. In January. an FBI expert called Apple “jerks” for increasing its iteration count from 10,000 to 10,000,000 (“password attempts speed went from 45 passwords a second to one every 18 seconds”). https://motherboard.vice.com/en_us/article/59wkkk/fbi-hacker-says-apple-are-jerks-and-evil-geniuses-for-encrypting-iphones But I certainly wasn’t trying to single out yescrypt. Two-dimensional hash cost parameters (time plus memory) are much harder to communicate. Nonetheless we need to try.
>
> Maybe we should impose some kind of minimum in yescrypt, like rejecting
> parameters that would make it use less than 1 MiB of RAM. Incidentally,
> on a modern machine this results in comparable performance to bcrypt's
> minimum cost 2^4. But then would third-party implementations keep this?
> For bcrypt, somehow most that I've seen do enforce the minimum.
I’d rather see benchmarks on common CPUs and some defined levels, bronze, silver gold, that sort of thing. And perhaps some minimum memory sized needed to remove the GPU advantage for some specific models. I think enterprises need a meaningful sound bite they can disclose. Each level might represent a factor of 8 in both count and speed, or some such.
>
>> One major problem is the lack of disclosure by systems as to what security measures they take. So users have to assume the worst - simple fast hashes. We can't even assume sites use salt.
>
> Right, except that "assume the worst" isn't always the most suitable
> strategy. The few users familiar with password hashing choose between:
>
> 1. Don't care, do whatever.
>
> 2. Assume the worst and decide on protecting the account against online
> attacks only (choose a password definitely easily crackable offline).
>
> 3. Assume the worst and use a very complex, likely generated password,
> likely storing it in a password manager (or generating it from a master
> password), in a text file, or on paper, etc.
>
> 4. Don't assume. Since the site might use proper password hashing, use
> a reasonable passphrase for that scenario. It'd withstand non-targeted
> offline attacks if so. And it'd certainly be enough against online
> attacks regardless.
There is also the approach of account triage, using strong passwords for major accounts: email, banks, maybe social media, and a weaker or common password for junk accounts, like subscriptions.
>
>> I do like system generated passwords. I think it is a tool that should be used more widely, especially in highly sensitive situations, e.g. for admins. However, what yescrypt parameters are good enough for 47-bit passwords today? In 5 years? I think that could be and should be spelled out.
>
> Yes, we should list suggested parameter sets for different use cases.
>
>> Slightly off topic: I have a table that generates a mnemonic English sentence for any random password of ten letters (47 bit entropy) diceware.blogspot.com /2013/12/making-random-letter-passwords-memorable.html. I've always thought that password generators should offer users a couple of different formats with equivalent strength. Feel free to use my table.
>
> It's interesting how you produce grammatically correct sentences, but
> the cost of that is your use of few words (in your case, just 26 words
> for each position in the resulting sentence), and also of relatively
> long words (although I guess that can be improved upon, if the number of
> different words is kept so low). The result is that your example 47-bit
> password corresponds to a 74 character sentence (not counting the dot),
> which isn't something I would want to suggest as an option to anyone.
> (Not even if this is just to be memorized, not typed in.)
My intent for the generated sentences is solely to serve a a mnemonic. On the conservative assumption that an adversary knows how you selected your password, the sentence has almost no security advantage over the ten-character random string it came from. It’s the later that I intended to be the password. I think:
"Bob’s merry umpires foolishly wrestle yellow monsters zooming neglected wisdom.”
makes “bmufwymznw” (a random string I just generated) significantly easier to remember. This approach is the inverse of the “think of a sentence, then use the initial letter as your password” advice, which has serious flaws. The words in the table were chosen for having vivid meanings rather than length. I haven’t pushed this approach because 47 bits is not strong enough in the absence of some certainty that strong hashing is being used.
Again, I think in a generated password situation, one should present a few different options. A third option might be a few pronounceable nonsense words, generated with the same amount of entropy.
>
>> Also note that depending on what size words you allow, 3 words with 2 separator characters may be too big for some services (e.g. Microsoft and Medicare).
>
> Right. With passwdqc's short words (3 to 6 characters each) that's at
> most 20 characters (and usually much less), yet I guess this won't fit
> some services (like if they store plaintext anyway?)
>
Microsoft services apparently limit password length to 16 characters. A Google search produces lots of complaints about this, but no indiction that Microsoft has any plans to increase this length, despite the revised NIST SP 800-63B revisions. Apple’s FileVault offers to generate and remember in the cloud apparently random passwords with ~71-bit entropy. These are 15 characters long (xxx-xxx-xxx-xxx, where each x is a letter, upper of lower case, or a digit). I assume Apple want their generated passwords to be short enough and simple enough to work in the vast majority of situations. So I think there is a need when generating passwords to at least have a Microsoft-safe option.
Arnold
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
