Re: [vwrap] adding transport and capability auth types, removing MD5

[Meadhbh Hamrick <[e-mail]>]

okay... a little background on hashed authenticators...

the original hashed authenticator was going to be used to replicate SL's
functionality of sending the non-salted, non-iterated, hash of a long-term
password.

but we wanted to have something better, so someone came up with the
challenge response scheme for use with the summer 2008 interop trial
(thought honestly, i don't think it was deployed.)

then i came up with the idea of using the PKCS#5 password based key
derivation function (PBKDF.)

and then the world went on until john hurliman and i were both trying to
figure out how to leverage OpenID and OAuth in VWRAP. that's where the CALM
message stuff came from. originally we were going to have the CALM message
include a "one time use" shared secret that the web-auth system would tell
the client and tell the VWRAP auth service about. then john came up with the
idea of putting the agent_login resource behind a web capability, so he
could just use proof of possession of the capability as authorization to log
in.

so now we're writing standards docs and we're talking about layering VWRAP
application layer object access across at least three different transports:
HTTP(S), XMPP and RTP. granted, it's probably unlikely that people are going
to attempt to send login credentials over RTP, but i used to work with game
programmers, so i've seen some pretty crazy things.

so the reason we say SHOULD instead of MUST is that we don't know if the
deployer will secure their network with IPSec, a Link Encryptor or TLS.
HTTPS requires the use of HTTP as a transport, and we're not entirely
certain that everyone wants to do that.

so in the proud tradition of internet standards everywhere, we will allow
implementers to shoot themselves in the foot if they really feel they need
to.

On Wed, Jul 7, 2010 at 5:59 PM, Robert G. Jakabosky
<[e-mail]>wrote;wrote:

> On Wednesday 07, Meadhbh Hamrick wrote:
>
> <snip>
> >
> > 2.3.2.  Hashed Password Authenticator
> >
> >   *When a hashed password is used as an authenticator, the string '$1$'
> >   is prepended to the UTF-8 encoding of the password and processed with
> >   the SHA256 cryptographic hash function [sha256].  This revision of
> >   the Virtual World Region Agent Protocol specification requires the
> >   use of SHA256 with the hashed password authenticator.  It also
> >   requires the presence of the algorithm key, and that the value of
> >   this key be the string 'sha256'.  Note that future versions of this
> >   specification may ALLOW or REQUIRE the use of other cryptographic
> >   hash functions.*
> >
>
> <snip>
>
> >
> >   The use of the hashed password authenticator could result in a replay
> >   attack if not used in conjunction with an appropriate confidentiality
> >   preserving transport.  Implementations using the hashed password
> >   authenticator SHOULD utilize appropriate encryption schemes such as
> >   TLS [RFC5246] or S/MIME [RFC3851].
> >
>
> What use is the "Hashed Password Authenticator", if the transport needs to
> be
> encrypted?  That SHOULD needs to be a REQUIRED.  If an attacker picks up
> the
> hashed password even once they will be able to login to the account any
> time
> they want, even if the service later only allows the use of
> the "Challenge-Response Authenticator".  Since the same hashed password can
> be combined with the challenge salt.
>
> I think the "Hashed Password Authenticator" needs to be replaced with
> a "Password Authenticator" that REQUIRES the use of an encrypted transport
> and sends the password instead of a hashed password.  Websites that have
> login forms use HTTPS to protect the user's password.  The browser doesn't
> send a hashed password to the server.  The use of password hashing on
> websites is to protect the password stored in a database encase some
> someone
> hacks the site and gets a copy of the password table.  That hashing is done
> on the server-side not the client-side.
>
> A "Password Authenticator" would also allow companies like LindenLab to
> continue to work with the md5 hashed passwords stored in their database.
>  It
> would also allow companies in the future to migrate (i.e. rehash) the
> passwords stored in their database when it comes time to replace a broken
> hash algorithm.
>
> --
> Robert G. Jakabosky
> _______________________________________________
> vwrap mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/vwrap
>