[Cryptography] Removal of spaces in NIST Draft SP-800-63B

[Kevin W. Wall]

On Mon, Apr 3, 2017 at 11:10 AM, Arnold Reinhold <agr at me.com> wrote:
>
>> On Apr 2, 2017, at 3:17 PM, Kevin W. Wall <kevin.w.wall at gmail.com> wrote:
>>
>> ...
>>
>> Speaking of which, NIST's suggested wording that you
>> commented on might actually be reasonable if applied to
>> answers of password security questions (which I
>> generally recommend being hashed in the same manner
>> that passwords are).
>>
>> However, unlike passwords, most development shops do
>> not require that answers to security questions be
>> confirmed by re-typing the answer in a second time.
>> But if you hash then, then there is a potential
>> problems with typos that even a help desk can't assist
>> you with. E.g., if the security question that is posed
>> is something like:
>>
>> <snip>
>>
>> For passwords, what I'm describing is seldom a problem
>> because conventional wisdom is that you confirm the
>> candidate password by requiring it to be typed in a 2nd
>> time to prevent this sort of typos. (And there are ways
>> using JavaScript in web forms, to prevent it from being
>> pasted in in the password confirmation field.)
>>
>> I've not bothered to read the NIST document that
>> Arnold commented on though to know if it deals with
>> password resets via security questions / answers or
>> not.
>
> I took a look at NIST 800-63 A and B and did not find
> anything suggesting password resets via security
> questions was OK. They mention “knowledge based
> verification” (KBV) but that seems to mean using info
> that the proper user might know, e.g. what was your
> last credit card transaction, and NIST seems to
> discourage its use. The NIST specs deal with three
> levels of verification and re-establishment of lost
> authenticators at the upper two levels is spelled out
> and requires re-verification of the means of identity
> verification used in initial establishment to some
> degree.

Which is likely to be a problem for many sites. Not
every site has an option to use something like KBV
because they don't do transactions per se with their
users. There's a lot of sites that just want your email
address so that they can send you spam or send your
email to other companies who want to send you spam.
(Of course, you probably agreed to all that in the ToS
that you accepted from them when you signed up for
their service.) There are lots of sights like this
(e.g., most of the online news papers, etc.). There are
more still sites that are used for social networking that
I think it would be hard to use KBV that only the
legitimate user would know about. E.g., what would you
ask--other than special security questions/answers--
that would NOT already be public on a social networking
site?

> Password resets via security questions are a huge
> security hole since many answers can be guessed,
> found by researching a user's online presence or
> phishing techniques ("free dating service, just fill
> out this questionnaire”).

No argument there. That's why OWASP has cheat sheets to
help developers out in these areas. E.g.,
  <https://www.owasp.org/index.php/Choosing_and_Using_Security_Questions_Cheat_Sheet>
  <https://www.owasp.org/index.php/Forgot_Password_Cheat_Sheet>
(Full disclosure: I am a major contributor to both of these.)

It's not perfect, but I for most run of the mill, non-transactional
sites, I don't see much of a better solution. But if you're say,
Amazon, it would be a lot better instead to use KBV and ask
something like "What was your last purchase at Amazon?"
or "What was the last movie you watched from Amazon?".
You're still probably going to have to provide a multiple choice
answer or require they answer M out of N questions correctly
if it's been a long time since they've interacted with your
site, but it's still more likely to be secure than using security
question / answers.

Also, security Q/A are not going to go away until passwords
go away, and I'm not holding my breath on that one. It used to
be estimated that 70+% of calls to customer help desks involved
assistance with password resets and this security question/answer
(supposedly) has considerably dropped that figure, so it's not going to go
away for the simple reason that every believes that it saves companies
significant amounts of $$. (Of course, this could very well be an
urban myth. I'm not aware of any research on it.)

> I’m not sure hashing answers helps much. If
> an attacker gets a hold of the hash value,
> the universe of possible answers to test
> could be quite small by cryptographic standards. (All
> movie, book and song titles, for example, all city
> names, all valid address in the U.S., all names in a
> phone book -- testing these against a known hash
> output would be quite easy.) Chained encryption with
> random initial padding might make more sense, since
> the data would be accessed infrequently. The account
> creation software could encrypt answers with a public
> key and the decryption could take place in a special
> server used only for answer verification. Having the
> decrypted plaintext answers available would let a
> human intervene if needed.

True in general, but where I think it helps is in terms
of customized (i.e., user created) questions.  I always
tell people that if you have the opportunity to create
a custom question, use that option instead and then
pick a topic that only you know about. I personally
recommend something that an individual might find quite
embarrassing, because those are details that they have
generally NOT widely shared. An example might be (note,
I am making this completely up):
  Q: What did your father do to you when he found you
     with his Playboy magazine?
  A: He made me run up and down our driveway, naked.

When a company allows user-created questions, then I
recommend that they encrypt the questions and hash the
answers. The reason is that way, it makes it harder for
insiders to read the questions and much, much more
difficult for them to discover the answers. (Also, requiring
user created questions shifts some of the liability back to
the user. They can no longer complain that you only had
lame questions to choose from that only had a small set
of possible answers.)

But for the ordinary lame q's: "What's your favorite sports
team?" or "What's your favorite flavor of ice cream?",
etc., you are spot-on. Hashing does no good. (Of
course, that's the type of questions that the OWASP
"Choosing and Using Security Questions Cheat Sheet" is
meant to prevent in the first place.)

> But I agree that canonicalization of the security
> answers could be acceptable. It might include
> removing multiple spaces, converting other whitespace
> characters to space, even removing punctuation and
> converting to single case. These steps would aid in
> automatic verification. But I don’t see a
> justification for removing single space characters
> even then.

I think the justification is balancing security versus
overwhelming your customer help desk. If the users fail
to answer security questions because they orignally
made a typo and answered with 2 spaces rather than just
one, the only way you can help them is if you encrypt
the answers (rather than hashing them) and then get the
help desk to "coach them" to the right answer or just
have the help desk personnel ignore the white space
when they have the users verbally state the answers
to them. But the main idea is to avoid having the user
go to the help desk entirely. Security questions /
answers are admittedly less secure than passwords
themselves, and passwords in general are a very weak
means of authentication. The question is, is the
additional drop in security by stripping consecutive
white space going to be that much worse or are by
doing that are you going to see a benefit to a reduced
number of calls to the help desks? My gut tells me
it's the latter.

-kevin
-- 
Blog: http://off-the-wall-security.blogspot.com/    | Twitter: @KevinWWall
NSA: All your crypto bit are belong to us.