Re: [TLS] one time passwords from private keys

Story Henry <henry.story@bblfish.net> Sun, 28 February 2010 18:49 UTC

Return-Path: <hjs@bblfish.net>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 118CE3A8AEA for <tls@core3.amsl.com>; Sun, 28 Feb 2010 10:49:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.407
X-Spam-Level:
X-Spam-Status: No, score=-2.407 tagged_above=-999 required=5 tests=[AWL=0.192, BAYES_00=-2.599]
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 tdKmjFMFaZTV for <tls@core3.amsl.com>; Sun, 28 Feb 2010 10:49:23 -0800 (PST)
Received: from bblfish.net (rust.entic.net [199.89.53.222]) by core3.amsl.com (Postfix) with ESMTP id E93003A8AE6 for <tls@ietf.org>; Sun, 28 Feb 2010 10:49:23 -0800 (PST)
Received: from alagny-551-1-59-244.w86-218.abo.wanadoo.fr ([86.218.2.244] helo=bblfish.home) by bblfish.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from <hjs@bblfish.net>) id 1NloCe-0001zF-Ri; Sun, 28 Feb 2010 10:49:21 -0800
Mime-Version: 1.0 (Apple Message framework v1077)
Content-Type: text/plain; charset="us-ascii"
From: Story Henry <henry.story@bblfish.net>
In-Reply-To: <396556a21002280936v4446c183jfba101eee97bb89a@mail.gmail.com>
Date: Sun, 28 Feb 2010 19:49:12 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <F26E5D8F-6CC8-44C5-A3B8-C6743589A353@bblfish.net>
References: <F0763843-BDC8-4E32-A3AE-2AE19BFC012F@bblfish.net> <1b587cab1002280709v68fafk1d34faf9029e3eb9@mail.gmail.com> <1b587cab1002280801g1eefd37aq19c58457834aa567@mail.gmail.com> <05EB46EE-D6DF-4532-AE0E-36EC4445EEA9@bblfish.net> <396556a21002280936v4446c183jfba101eee97bb89a@mail.gmail.com>
To: Adam Langley <agl@imperialviolet.org>
X-Mailer: Apple Mail (2.1077)
Sender: hjs@bblfish.net
Cc: tls@ietf.org
Subject: Re: [TLS] one time passwords from private keys
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
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/listinfo/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: Sun, 28 Feb 2010 18:49:25 -0000

On 28 Feb 2010, at 18:36, Adam Langley wrote:

> On Sun, Feb 28, 2010 at 11:58 AM, Story Henry <henry.story@bblfish.net> wrote:
>> Yes, but I think that would make for a string that would be too long for a human being to type into a password field. Such a string should not be more than 5 to 6 characters long.
> 
> If we assume that the public key is widely known, then an attacker
> knows all the information that the legitimate authenticator knows.
> Thus the attacker can brute force the password offline, in real time.

> A six character password is, roughly, 30-bits.
> Assuming a 1024-bit
> modulus a desktop computer can probably do 2**18 public
> operations/sec. A hardware implementation might 100x faster. So it
> doesn't take much to brute force that in seconds - faster than you can
> expire the nonce because user's only type so quickly.

That is frighteningly fast. 
How many chars does one need then?
And how do 1 time passwords work then at all?

So I suppose the above would not be possible if the client can connect to
the server using https. Most browsers, even when they have broken client
side certificates, do allow https connections - I am guessing this is even true on cell phones. And the server could just tie the response to the TLS session. Does that not remove the above problem?

> 
>>  But to help people who are stuck in bad browser land, we are trying to work on this solution, which won't be any worse than username/passwords - in fact it should be more secure, whilst hopefully giving one one username/passowrd function for all sites.
> 
> We're aware that Google Chrome is certainly lacking in these respects
> on some platforms. It's on the todo list and not too far down.

Great. Also it would be fantastic if one could get the Android platform to support <keygen> and have a good key chain.

A year ago, I had an amazing demo on the iPhone. I could log into to a few of our demo sites without having to type either a username or a password. Pictures of this here:

   http://blogs.sun.com/bblfish/entry/one_click_global_sign_on

But somehow in v3 of the iPhone OS they broke their client certificate stack, and it no longer worked. 

   Henry


> 
> 
> AGL
> 
> -- 
> Adam Langley agl@imperialviolet.org http://www.imperialviolet.org