Subject: [http-auth] Fwd: [saag] [websec] re-call for IETF http-auth BoF

From: "KIHARA, Boku" <[email-masked]>
Date: Wed, 15 Jun 2011 22:42:06 +0900

Missing Ccs? Forwarding:

---------- Forwarded message ----------
From: David S. Misell MBCS CISSP <[email-masked]>
Date: 2011/6/15
Subject: RE: [saag] [websec] [http-auth] re-call for IETF http-auth BoF
To: "KIHARA, Boku" <[email-masked]>

One time passwords should still be OK for poor auth methods, There is
a series of SecurID based RFCs
Kind Regards
dave

-original message-
Subject: Re: [saag] [websec] [http-auth] re-call for IETF http-auth BoF
From: "KIHARA, Boku" <[email-masked]>
Date: 15/06/2011 10:45 am

2011/6/14 Peter Gutmann <[email-masked]>:
> Phillip Hallam-Baker <[email-masked]> writes:
>
>>what would we want HTTP authentication to look like?
>
> I have a suggestion for what it shouldn't look like: Any method that hands
> over the password (or a password-equivalent like a password in hashed form) as
> current browsers do should be banned outright, and anyone who implements
> hand-over-the-password should killed and eaten to prevent them from passing on
> the genes.

+1.

To make the goal clear, let's list what kind of authentication methods
should be avoided. One item is methods that hand over passwords,
mentioned by Peter. Let me add methods whose UI can be imitated and
the result can be forged by malicious sites. Like a padlock icon that
insists the session is secured by TLS inside content area, Is a _secure_
authentication method inside content area truly reliable?

* a method that hands over a password (or a password-equivalent)
* a method whose UI can be imitated by malicious sites.

Of course there might be more items, please append.

# Peter, sorry for missing Ccs.

--
KIHARA, Boku

2011/6/14 Peter Gutmann <[email-masked]>:
> Phillip Hallam-Baker <[email-masked]> writes:
>
>>what would we want HTTP authentication to look like?
>
> I have a suggestion for what it shouldn't look like: Any method that hands
> over the password (or a password-equivalent like a password in hashed form) as
> current browsers do should be banned outright, and anyone who implements
> hand-over-the-password should killed and eaten to prevent them from passing on
> the genes.
>
> The only permitted auth.form should be a dynamic, cryptographic mutual auth.
> that authenticates both the client and the server.  There are endless designs
> for this sort of thing around so the precise form isn't too important, as long
> as it's not hand-over-the-password.
>
> Peter.
> _______________________________________________
> saag mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/saag
>
_______________________________________________
saag mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/saag

---

From: Thomas Roessler <[email-masked]>
Date: Wed, 15 Jun 2011 15:44:21 +0200

Make that [email-masked], not [email-masked]. ;)
--
Thomas Roessler, W3C  <[email-masked]>  (@roessler)

On 2011-06-15, at 15:42 , KIHARA, Boku wrote:

> websec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/websec
>

---

From: Marc Williams <[email-masked]>
Date: Tue, 21 Jun 2011 15:39:54 -0400

>> Of course there might be more items, please append.

A method which pemits zero length password authentication

Marc Williams

---

From: "SHIMIZU, Kazuki" <[email-masked]>
Date: Thu, 23 Jun 2011 00:23:23 +0900

I agree.

In addition, I think we should avoid not only "zero length password"
but also weak passwords (e.g. 12345, qwerty, etc...).

This problem may be operation policy issue,
however, might be considering.

--
SHIMIZU, Kazuki

---

From: "GOGWIM, JOEL GODWIN" <[email-masked]>
Date: Wed, 22 Jun 2011 18:21:39 +0100 (WAT)

Supported.
Weak and predictable passwords should be avoided.

---

From: Nico Williams <[email-masked]>
Date: Wed, 22 Jun 2011 12:08:02 -0500

> Weak and predictable passwords should be avoided.

If you have ZKPPs then weak passwords are OK.

Also, all passwords that users must remember should be considered weak.

Nico
--

---

From: "Henry B. Hotz" <[email-masked]>
Date: Wed, 22 Jun 2011 11:01:14 -0700

I can agree in principle, but in practice the definition of "weak" is too fuzzy.

>>> A method which pemits zero length password authentication

------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
[email-masked], or [email-masked]

---

From: Yutaka OIWA <[email-masked]>
Date: Thu, 23 Jun 2011 11:36:09 +0900

> Weak and predictable passwords should be avoided.

I ideally agree, but in reality I hesitate to agree with it
with technical means and backgrounds. In short, here is a security trade-off.

Of course, the statement "weak and predictable passwords should be avoided",
as literally, can be read as our requirements to users and agreed with
no questions.
However, the original thread was prepended with "Any protocols that allow".
For this purpose, the more the technology gets strong to protect "good
(unpredictable)"
passwords and passphrases against possible attacks, the more such a protocol
cannot reveal "weakness" of passwords to servers too.

To detect by the server side to detect predictable passwords using
bulky (e.g. 100k or 1M+) list, currently we need either a plain-text password
authentication protocol or a plain-text password registration procedure.
On the contrary, if we forgive users' "mistake" to use such a weak passwords
as user's own, we can introduce much stronger password
protocols which do not reveal (at least immediately) the user's password
both in registration and authentication time.
When we face with this trade-off, I don't want to trash out the
latter's possibility.

In this background, "forbidding protocols which allow users to (covertly) use
weak predictable passwords" means that "servers *always* know the user's
plain-text password", which is obviously not happy.
We don't want to completely sacrifice well-done user's security in trade with
the careless user's security.

Of course, even if we introduce such "secure" password registration protocol,
I foresee that some people will continue to stick on plain-text password
registration for various reasons.  For example, if a law had required
some servers
(e.g. financial entities) to check and reject such predictable passwords,
we would have no way to secure it.  For such purposes servers will
continue to receive raw passwords and computes password-hashes
(or whatever equivalent) on the server-side.
But I think that providing a possibility to securely registering passwords
to servers are one of required things to do for us.

But, again at last, I repeat to agree that "users" should avoid weak and
predictable passwords with no questions.

---

From: Yutaka OIWA <[email-masked]>
Date: Thu, 23 Jun 2011 11:52:40 +0900

> Also, all passwords that users must remember should be considered weak.

This is a terminology issue, and I present here *my* use of
such terminologies in general.

= strong secret and weak secret =

"strong" secrets are the secret data which has an entropy
comparable to other security parameters (e.g. encryption key length etc.)
They typically include public-key-cryptography secret keys,
DH-key-exchanged shared keys,
randomly-generated nonce-like bearer tokens and others.

"weak" secrets are the secret data which has not enough
entropy compared to encryption etc.
PINs, Passwords and passphrases are typical examples.
They should not be used for encryptions without some
security-amplifications (e.g. password-authenticated key exchanges.)

In this meaning, all memorable passwords are weak.

= strong passwords/passphrases and weak passwords =

I use the term "weak passwords" almost equivalent to
predictable passwords or brute-force searchable passwords.
The required strength may depend on the context,
e.g. whether the passwords search can be off-line, or
whether a pre-computed dictionary of hashed passwords can be
useful, etc. but many people will agree that "1" and "1234" are
weak, and "cA6mqUPgBpe6pQf7" is strong as a password.

I prefer using "predictable" and "unpredictable" for this meanings.

---

From: Yaron Sheffer <[email-masked]>
Date: Thu, 23 Jun 2011 23:53:17 +0300

No, even if you have ZKPP you should avoid ridiculously weak
passwords like "qwerty". The reason is, you are still vulnerable to
active password guessing, and even if you rate-limit aggressively
(e.g. one guess per hour), the attacker might get lucky too early.

So I would distinguish between the 2**20 space of user-memorable
passwords, vs. the 2**7 space of too-horrible-to-contemplate
passwords.

Thanks,

Yaron

On 06/22/2011 08:08 PM, Nico Williams wrote:

Supported.

Nico

---

From: Marsh Ray <[email-masked]>
Date: Thu, 23 Jun 2011 16:05:31 -0500

On 06/22/2011 09:36 PM, Yutaka OIWA wrote:
> 2011/6/23 GOGWIM, JOEL GODWIN<[email-masked]>:
>> Supported.
> with technical means and backgrounds.

How is the IETF or w3 going to define "weak password" anyway?

Even if there were a way, it's common to see users getting hacked these 
days because the use the same (possibly strong) password at multiple sites.

It's best to pick a completely unique, strong password (12 or more 
characters) for each and every site. But unless you're some kind of 
savant, this requires writing these passwords down somewhere.

But instead, users are taught not to write their passwords down (mostly 
by employers who don't want it to end up on a sticky note in an obvious 
place). So users either pick simple passwords and/or they use the same 
one at every site.

> some servers (e.g. financial entities) to check and reject such predictable passwords,
> we would have no way to secure it.

That would be a bad law.

I don't think a protocol design can or should defend against bad laws.

At least in the US, financial institutions don't have such laws. They 
instead have a patchwork of audit requirements, industry standards, best 
practices, compliance, etc.. Which is probably better than passing laws 
about password complexity requirements, all things considered.

> For such purposes servers will

This is far more important than working out ways to accommodate sites 
that want or need to transfer the password in clear text. Those sites 
are already able to do that just fine.

Ideally the technology would somehow prevent a site from accepting (or 
doing anything useful with) the user's plaintext password within the 
page. This would allow the browser to remove any ambiguity for users 
which would be exploitable by phishing.

The simplest message and the one that will "sink in" with the most users 
is: "You should never type this password into any web page or program 
except this unmistakable piece of browser chrome. Not to verify your 
account info, not to reset your password, not to receive tech support 
from someone you trust, and not even to see free pictures of kittens."

It would be amazing if we could get there, but browser vendors and sites 
conspire against us to defeat it.

- Marsh

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 23 Jun 2011 22:20:46 +0100

[Can't we reduce the cross-posting on this? I'm getting
3-5 copies of everything to do with this topic.]

I think we need to try do a number of things to improve
http authentication, one of which may well be to
investigate zkpp's, but (AD hat off) I really think
we'll be better off if we can reduce the number of
(new) passwords as well, hence my proposal to try
figure a way to do TLS mutual auth.

But spending a lot of time discussing weak passwords
in the IETF context is probably somewhat pointless
since that's not a protocol issue that I can see.

S.

---

From: Nico Williams <[email-masked]>
Date: Thu, 23 Jun 2011 19:43:33 -0500

On Thu, Jun 23, 2011 at 3:53 PM, Yaron Sheffer <[email-masked]> wrote:
> No, even if you have ZKPP you should avoid ridiculously weak passwords like
> "qwerty". The reason is, you are still vulnerable to active password
> guessing, and even if you rate-limit aggressively (e.g. one guess per hour),
> the attacker might get lucky too early.

Clearly.

> So I would distinguish between the 2**20 space of user-memorable passwords,
> vs. the 2**7 space of too-horrible-to-contemplate passwords.

This is why password quality policies matter even when using ZKPPs.

2^20 search space? -> use ZKPPs.
2^7 search space? -> you're very much out of luck!

Nico
--