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

[Arnold Reinhold]

> On Apr 3, 2017, at 9:00 PM, Kevin W. Wall <kevin.w.wall at gmail.com> wrote:
> 
> On Mon, Apr 3, 2017 at 11:10 AM, Arnold Reinhold <agr at me.com> wrote:
>> …
> ... 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?

Getting a voice sample at account creation and using voice prints, asking for a high resolution version of a low resolution jpg file already posted, asking a long time friend on the site to verify, asking for a short selfie video of them responding to a random question; there are lots of possibilities. 

> 
> …. 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.)
> …

> 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.)

Let’s agree that security Q/A isn’t going away, whether I like it or not.

> 
>> 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.)

Hashing does no good for simple answers and it isn’t suitable for complex answers.

   Initial answer "He made me run up and down our driveway, naked.”

   Challenge answer: "He made me run naked up and down our driveway.”

Hashes would not match. Encryption would allow easy human intervention and I suspect current language understanding software could match up the two answers. Even a simple algorithm such as sorting the words alphabetically and calculating a correlation might work well enough in many cases. The goal would be to avoid human intervention in most reset requests. You can’t rely on humans remember the exact way they answered a complex question.  “I had to exercise in front of the house with no clothes on” might still take a human to verify.

In every case, it seems to me, hashing is NEVER right for security Q/A. Maybe you could update your cheat sheet?

> 
>> 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.
> 

I’m sorry if I wasn’t clear, but I agree with condensing multiple space to a single space, as well as other canonicalization measures (though if encryption is used to store the answers, there is no need to canonicalize until the answer is decrypted and ready to be tested). What I was trying to say is there is no justification in removing single space characters. ""Hemademerunupanddownourdriveway,naked.” helps neither human nor machine.

Arnold Reinhold