Re: [TLS] about the PWD Proposal

Yoav Nir <ynir@checkpoint.com> Sat, 19 November 2011 10:46 UTC

Return-Path: <ynir@checkpoint.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9774C21F8B48 for <tls@ietfa.amsl.com>; Sat, 19 Nov 2011 02:46:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.124
X-Spam-Level:
X-Spam-Status: No, score=-10.124 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a8AymdTxw9Ue for <tls@ietfa.amsl.com>; Sat, 19 Nov 2011 02:46:53 -0800 (PST)
Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 8CB8D21F8B47 for <tls@ietf.org>; Sat, 19 Nov 2011 02:46:52 -0800 (PST)
X-CheckPoint: {4EC788AC-1-1B221DC2-1FFFF}
Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id pAJAklIt004891; Sat, 19 Nov 2011 12:46:47 +0200
Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.3.213.0; Sat, 19 Nov 2011 12:46:47 +0200
Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Sat, 19 Nov 2011 12:46:47 +0200
From: Yoav Nir <ynir@checkpoint.com>
To: "<zhou.sujing@zte.com.cn> <zhou.sujing@zte.com.cn>" <zhou.sujing@zte.com.cn>
Date: Sat, 19 Nov 2011 12:46:45 +0200
Thread-Topic: [TLS] about the PWD Proposal
Thread-Index: AcymqIipJMum0hlQRj23WRuZA3NYMw==
Message-ID: <AC813066-7203-42EE-B5F6-01E33E3B99DD@checkpoint.com>
References: <OF48A3B9D8.19A08C28-ON4825794C.002F0B42-4825794C.003162E8@zte.com.cn>
In-Reply-To: <OF48A3B9D8.19A08C28-ON4825794C.002F0B42-4825794C.003162E8@zte.com.cn>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
x-kse-antivirus-interceptor-info: scan successful
x-kse-antivirus-info: Clean
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-KSE-AntiSpam-Interceptor-Info: protection disabled
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] about the PWD Proposal
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 19 Nov 2011 10:46:53 -0000

Hi

On Nov 18, 2011, at 9:59 AM, <zhou.sujing@zte.com.cn> <zhou.sujing@zte.com.cn> wrote:

> 
> Hi, 
>  I am interested in the PWD proposal at the meeting, and run through it(http://tools.ietf.org/html/draft-harkins-tls-pwd-01#section-3.4), 
>  and have the following concerns: 
> 
> 1. In the document, it  says both Client and Server should be able to compute PE, which is derived from username, password, salt,etc. 
>    That means Client or the user should also remember the salt value, in that case, salt is meaningless and can be replaced by a longer password. 
>    This is quite different from the widely known usage of salt, e.g. in UNIX operating system, salt is not required to remember by the user, but by server to fetch locally by reference to the username. 
>   And as far as I know, I am sure the authors also know that, other password based key exchanges protocols don't involve salt, but store a hash value of password among other things locally. 

I realize that this is very different from the usage in UNIX operating systems, but it is necessary, as the UNIX (or other) operating system running the web server has to store the password. Storing the password in the clear on as an unsalted hash is worse than storing a salted hash (or "base" in the draft's terminology), so that is what the TLS server does. The use of base instead of password is not to protect the password during handshake, but to protect it during storage on the server.

Having said that, I think it is now very practical to take a list of the 100,000 most popular passwords on the web, a database of 10,000 salted hashes (the file described in section 3.4), and find all the matches. That's 1,000,000,000 operations, which would take 15 minutes on a MacBook Air (1.4 GHz). I think the days of saying that a database of salted hashes makes theft of the password file irrelevant should be over. Yes, I know that with unsalted hash it would be practical to test the 100,000,000 most popular passwords. 

<snip/>
> 
> Sujing Zhou   
>   
> --------------------------------------------------------
> ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
> This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.

One more thing: I realize that the above line was probably inserted either by your MUA or MTA, but it is not true. Email messages to IETF mailing lists are considered contributions, and are subject to "Note Well" http://www.ietf.org/about/note-well.html

Yoav