Re: [http-auth] Normalization forms in draft-ietf-httpauth-basicauth-enc

[Julian Reschke <[e-mail]>]

On 2013-07-01 07:45, "Martin J. Dürst" wrote:
>
>
> On 2013/07/01 6:35, Paul Hoffman wrote:
>> On Jun 30, 2013, at 2:14 PM, Yaron Sheffer<[e-mail]>  wrote:
>>
>>> Paul, your proposed text doesn't make sense to me, because with Basic
>>> auth, the server might keep a hash of the password instead of the raw
>>> password (to reduce the damage if the entire database gets stolen).
>>> In which case I would expect the server to normalize the password
>>> before it is being hashed without any check of the "expected value".
>>
>> The process that is checking for equivalence is not necessarily the
>> process that stored the (possibly normalized) password, and the two
>> processes might have different views of what normalization to use.
>
> That's definitely an important aspect of the problem, and should be
> called out. In particular, it's important to say that if you don't
> normalize when creating a password hash, then in the odd case that you
> get something half-baked (e.g. half in NFC and half in NFD,...), then
> it's going to be very hard to get back to the original form.
>
>> Normalizing takes time.
>
> Well, that's often brought up but not really very true or relevant.
>
> First, it's easily possible to make normalization fast. In particular,
> it is possible to make normalization very fast for the frequent cases.
> (It's also possible to make it slow, but that's true of any kind of
> processing.)
>
> Second, security-related calculations (hashes,...) are regularly
> designed so as to not be too fast. So normalization shouldn't be the
> bottleneck.
>
> Regards,   Martin.

So what if we mandated normalization to happen on the client?

Best regards, Julian