[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180403110640.GA20948@openwall.com>
Date: Tue, 3 Apr 2018 13:06:40 +0200
From: Solar Designer <solar@...nwall.com>
To: passwords@...ts.openwall.com
Subject: Re: keyed hash vs. encryption
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.
On Tue, Mar 27, 2018 at 06:42:15PM -0400, Arnold Reinhold wrote:
> We don't have nearly enough people with crypto-fu to work out these tradeoffs at every bank, retailer, electric utility, government benefit office, etc., etc. We need very clear guidelines
Right.
> 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.
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.
> 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.
> 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.)
> 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?)
Alexander
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.
