Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-pwd

From: Joseph Birr-Pixton <[email-masked]>
Date: Fri, 6 Dec 2013 23:25:44 +0000

On 6 December 2013 20:00,  <[email-masked]> wrote:
> From: "Dan Harkins" <[email-masked]>
> To: "CodesInChaos" <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>
> Date: Fri, 6 Dec 2013 10:29:22 -0800 (PST)
> Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-pwd
>
> On Fri, December 6, 2013 3:14 am, CodesInChaos wrote:
>> Database compromises happen all the time, and forcing the server to
>> store a weakly hashed password
>> isn't acceptable IMO.
>
>   You're absolutely right, that would not be acceptable.
>
>   TLS-pwd uses HMAC-SHA256 with a 32 byte random key (salt) to
> hash passwords that the server stores.

How does this not constitute an immensely fast password oracle?

If the server stores (username, base, salt) per user with base :=
HMAC-SHA256(salt, username || password) you'd only need to compute
about 3 SHA256 blocks to check each candidate password.

Cheers,
Joe

---

From: "Dan Harkins" <[email-masked]>
Date: Fri, 6 Dec 2013 15:38:55 -0800 (PST)

> about 3 SHA256 blocks to check each candidate password.

  It's a balanced PAKE protocol. Like all such schemes (e.g EKE, J-PAKE)
the database of passwords is presumed to not be available to the
attacker.

  Dan.

---

From: Manuel Pégourié-Gonnard <[email-masked]>
Date: Sat, 07 Dec 2013 14:20:00 +0100

> the database of passwords is presumed to not be available to the
It's not supposed to be available to the attacker, but as CodesInChaos pointed
out, in real life it has an annoying tentency to become available to attackers
much more often than one would like. Anyway, why do you hash & salt the paswords
in the first place, if not to offer some protection in case the database becomes
available to an attacker?

HMAC-SHA256 is a very poor protection, and weak protections are kind of worse
than no protection at all: they give an illusion of security.

Manuel.

---

From: "Dan Harkins" <[email-masked]>
Date: Sat, 7 Dec 2013 15:21:00 -0800 (PST)

> available to an attacker?

  Originally the passwords were not salted but I received a comment
recommending that it be done.

> than no protection at all: they give an illusion of security.

  I'm assuming you don't know of an efficient pre-image attack.
So I will assume you're referring to the ability of someone to do
a dictionary attack given the database of salted passwords. And in
that case, yes, this is not that big protection. Modular exponentiation
(used by augmented PAKE schemes) is not much better either. And
given the coWPAtty (and family) attacks against WPA-PSK that uses
PBKDF2 with 4096 iterations of HMAC-SHA1 I would say that's not
too good either.

  So when an attacker has a database of protected passwords you
should assume the worst regardless of how you protect the
passwords.

  Let me point out yet again that this draft is not proposing a general
purpose cipher suite that is appropriate for all situations. If it is not
appropriate for your TLS deployment then by all means don't use it.
But just because it is not appropriate for your particular deployment
does not mean it is not appropriate for anyone.

  regards,

  Dan.