Subject: How US military base in Hawaii was compromised - Password sharing

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 8 Nov 2013 10:11:58 -0800

http://www.reuters.com/article/2013/11/08/net-us-usa-security-snowden-idUSBRE9A703020131108

I think that the lesson we should draw from this is that no organization is
capable of using password based security effectively. People like passwords
because they are convenient, one of the reasons that they are convenient is
that they can be shared.

-- 
Website: http://hallambaker.com/

---

From: Michael Richardson <[email-masked]>
Date: Fri, 08 Nov 2013 16:02:24 -0500

>>>>> "Phillip" == Phillip Hallam-Baker <[email-masked]> writes:
    Phillip> http://www.reuters.com/article/2013/11/08/net-us-usa-security-snowden-idUSBRE9A703020131108

    Phillip> I think that the lesson we should draw from this is that no
    Phillip> organization is capable of using password based security
    Phillip> effectively. People like passwords because they are
    Phillip> convenient, one of the reasons that they are convenient is
    Phillip> that they can be shared.

Exactly.  And that means that any non-password systems that does not permit
authority to be delegated will fail to be adopted in places where people
need to share.

Fortunately, we have some really good mechanisms on the books that
permit delegation including OAUTH*, KeyNote(2704), SASL (I think) and
even going back to SPKI (rfc2693).  I know that there are more.

--
Michael Richardson
-on the road-

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 8 Nov 2013 17:19:13 -0800

On Fri, Nov 8, 2013 at 1:02 PM, Michael Richardson <[email-masked]> wrote:

>     Phillip>

Supporting delegation is easy.

Supporting delegation in a way that ordinary people can understand is very
hard.

---

From: Yoav Nir <[email-masked]>
Date: Sat, 9 Nov 2013 02:42:22 +0000

On Nov 8, 2013, at 5:19 PM, Phillip Hallam-Baker <[email-masked]<mailto:[email-masked]>> wrote:

On Fri, Nov 8, 2013 at 1:02 PM, Michael Richardson <[email-masked]<mailto:[email-masked]>> wrote:

>>>>> "Phillip" == Phillip Hallam-Baker <[email-masked]<mailto:[email-masked]>> writes:

Supporting delegation in a way that ordinary people can understand is very hard.

In any organization where passwords are used, changing the authorization to allow you access (aka delegation) is much harder than using my credentials to let you access. With other kinds of credentials, the balance might change. But I don't think so. If you ask me to access whatever, it's easier to stick my finger on the necessary fingerprint reader, giving you my phone, my USB dongle or my OTP token is way easier than filling out the necessary forms to give you authorization. Can't fix that with technology.

---

From: [email-masked] (Martin Rex)
Date: Mon, 11 Nov 2013 19:24:56 +0100 (CET)

> Supporting delegation in a way that ordinary people can understand

Kerberos originally contains a concept for "delegation of authority".
The only scenario how it seems to be used is in forwarding full
control (forwarding a TGT, rather than a tailored service ticket).

About a decade ago, a different scheme of "delegation" was invented
and is used with Kerberos today, called "Constrained Delegation"
with "Protocol Transition", where the sysadmin configures which
tickets a service is allowed to forge out of thin air at will
(which obviates the sysadmin to ask users for their passwords...).

-Martin

---

From: Dave Cridland <[email-masked]>
Date: Tue, 12 Nov 2013 11:38:23 +0000

> even going back to SPKI (rfc2693).  I know that there are more.

Apologies for the delayed reaction to this, but:

Yes, SASL contains a theory of proxy-auth, and most mechanisms (though not
all) provide provision for requesting this during authentication.

However, there are parts missing from the complete breakfast here:

1) Users have no interoperable method for allowing a delegation (or proxy
auth, or whatever). I think Kerberos works by telnetting in and editing an
obscure file, but I can't remember the details.

2) Users also don't have any interoperable way of changing passwords. Some
mechanisms (and I'm looking at PLAIN here) require the plaintext password,
others (such as SCRAM-*) could allow a not-quite-plaintext-equivalent hash,
and things like SRP allow a fairly secure verifier. None of these things
are perfectly secure across the wire, of course, however it's probably
worth noting that the vast majority of vendors offer password changing
facilities, and it'd be quite nice to ensure these were interoperable, so
that users' password management could be made rather more easily available.

I'd note prior art exists at least for the second item - there's both the
Eudora password changing protocol, and also XMPP's XEP-0077 has some
password changing facilities too. Both, as I recall, require the password
to be sent in the clear. There has, to my knowledge, been at least one
exploit targetting XEP-0077 on some systems.

Dave.