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

"Robert G. Jakabosky" <bobby@sharedrealm.com> Thu, 08 July 2010 00:59 UTC

Return-Path: <bobby@sharedrealm.com>
X-Original-To: vwrap@core3.amsl.com
Delivered-To: vwrap@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 38BB03A6781 for <vwrap@core3.amsl.com>; Wed, 7 Jul 2010 17:59:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.74
X-Spam-Level:
X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oVOvD769m4Ku for <vwrap@core3.amsl.com>; Wed, 7 Jul 2010 17:59:30 -0700 (PDT)
Received: from mail.neoawareness.com (ns2.sharedrealm.com [IPv6:2001:470:1f05:4f4::13]) by core3.amsl.com (Postfix) with ESMTP id E59EC3A677C for <vwrap@ietf.org>; Wed, 7 Jul 2010 17:59:29 -0700 (PDT)
Received: from localhost ([127.0.0.1] helo=[10.200.0.30]) by mail.neoawareness.com with esmtpa (Exim 4.69) (envelope-from <bobby@sharedrealm.com>) id 1OWfSe-0006Tl-Ej for vwrap@ietf.org; Wed, 07 Jul 2010 17:59:32 -0700
From: "Robert G. Jakabosky" <bobby@sharedrealm.com>
To: vwrap@ietf.org
Date: Wed, 7 Jul 2010 17:59:22 -0700
User-Agent: KMail/1.9.9
References: <AANLkTinL2XwNzGB8Cz2bfrZ0LhbFdDkpQF1Qr8CRbFhf@mail.gmail.com>
In-Reply-To: <AANLkTinL2XwNzGB8Cz2bfrZ0LhbFdDkpQF1Qr8CRbFhf@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <201007071759.22660.bobby@sharedrealm.com>
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Mail-From: bobby@sharedrealm.com
X-SA-Exim-Scanned: No (on mail.neoawareness.com); SAEximRunCond expanded to false
Subject: Re: [vwrap] adding transport and capability auth types, removing MD5
X-BeenThere: vwrap@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Virtual World Region Agent Protocol - IETF working group <vwrap.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/vwrap>, <mailto:vwrap-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/vwrap>
List-Post: <mailto:vwrap@ietf.org>
List-Help: <mailto:vwrap-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/vwrap>, <mailto:vwrap-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Jul 2010 00:59:31 -0000

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