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
- [vwrap] adding transport and capability auth type… Meadhbh Hamrick
- Re: [vwrap] adding transport and capability auth … Robert G. Jakabosky
- Re: [vwrap] adding transport and capability auth … Meadhbh Hamrick