From owner-freebsd-security@FreeBSD.ORG Wed Feb 11 17:22:02 2009 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1B085106566B for ; Wed, 11 Feb 2009 17:22:02 +0000 (UTC) (envelope-from mail@maxlor.com) Received: from mxout005.mail.hostpoint.ch (mxout005.mail.hostpoint.ch [217.26.49.184]) by mx1.freebsd.org (Postfix) with ESMTP id C0C8A8FC1C for ; Wed, 11 Feb 2009 17:22:01 +0000 (UTC) (envelope-from mail@maxlor.com) Received: from [10.0.2.10] (helo=asmtp001.mail.hostpoint.ch) by mxout005.mail.hostpoint.ch with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LXIme-000Ogh-BK for freebsd-security@freebsd.org; Wed, 11 Feb 2009 18:22:00 +0100 Received: from [82.136.101.181] (helo=maxlor.mine.nu) by asmtp001.mail.hostpoint.ch with esmtpa (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LXIma-0005Hh-9E for freebsd-security@freebsd.org; Wed, 11 Feb 2009 18:21:59 +0100 Received: from localhost (unknown [127.0.0.1]) by maxlor.mine.nu (Postfix) with ESMTP id 157EB2E559 for ; Wed, 11 Feb 2009 18:21:56 +0100 (CET) X-Authenticated-Sender-Id: mail@maxlor.com X-Virus-Scanned: amavisd-new at atlantis.intranet Received: from maxlor.mine.nu ([127.0.0.1]) by localhost (atlantis.intranet [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oor-BQp9xwYv for ; Wed, 11 Feb 2009 18:21:55 +0100 (CET) Received: from [192.168.10.159] (pub212004072186.fx-hfc.datazug.ch [212.4.72.186]) by maxlor.mine.nu (Postfix) with ESMTPSA id 582462E565 for ; Wed, 11 Feb 2009 18:21:55 +0100 (CET) From: Benjamin Lutz To: freebsd-security@freebsd.org Date: Wed, 11 Feb 2009 18:21:53 +0100 User-Agent: KMail/1.9.9 References: <200902090957.27318.mail@maxlor.com> In-Reply-To: <200902090957.27318.mail@maxlor.com> X-Face: $Ov27?7*N,h60fIEfNJdb!m,@#4T/d; 1hw|W0zvsHM(a$Yn6BYQ0^SEEXvi8>D`|V*F"=?utf-8?q?=5F+=0A=09R2?=@Aq>+mNb4`,'[[%z9v0Fa~]AD1}xQO3|>b.z&}l#R-_(P`?@Mz"kS; XC>Eti,i3>%@=?utf-8?q?g=3F=0A=094f?=,\c7|Ghwb&ky$b2PJ^\0b83NkLsFKv|smL/cI4UD%Tu8alAD MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200902111821.53437.mail@maxlor.com> Subject: Re: OPIE considered insecure X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2009 17:22:02 -0000 Hello, I've been thinking about what to do about OPIE, and I see the following possibilities. (Note: this is mainly just a braindump to collect my thoughts; many details that seem obvious to me are omitted. I'm making it public because others might be interested in it too.) - Enhance OPIE to use larger internal hashes. Because of the way OPIE works, the user needs to input at least as many bits as OPIE uses internally, therefore increasing the hash length increases the inconvenience. If 5-letter words were added, this would give us 18, maybe 24 additional bits for a total of 82-88 bits; if two numeric digits (2-9, because 0 and 1 might be confused with O and l) are added to every word (JOHN43 BOAT59), this would give us 36 additional bits for a total of 100 bits. - Implement another algorithm: PPP. (https://www.grc.com/ppp.htm, no source available but algorithm is documented.) This system appears to have one weakness compared to OPIE: the secure 256-bit key needs to be stored on the host and is accessed frequently. There are several advantages though: the algorithm won't be brute-forced any time soon, and since the passwords have no dependencies to each other, they can each be very short (GRC suggests 4 characters). Also, the number of one time passwords that can be generated is unlimited (*). PPP Variant 1: The problem of the secure key being compromised could be solved by extending the algorithm as follows: the list of one time passwords is precalculated on the host, each password is hashed and only the hash is stored. This would remove the advantage (*) and also prevent recreation of a password list (but that's good, right?) PPP Variant 2: derive the secure 256-bit key from some user passphrase. This would allow password calculators. - Implement another algorithm: OTPW (http://www.cl.cam.ac.uk/~mgk25/otpw.html, implementation is GPL, algorithm is documented.) This system precalculates random independent passwords and stores their hashes. This then works the same as the PPP variant 1 described above. Password calculators are not possible. - Use pam_sotp (http://www.cavecanen.org/cs/projects/pam_sotp/, GPL, algorithm not documented). Seems be quite similar to OTPW. Some general thoughts: - The one time passwords should definitively be independent from each other; this allows very short passwords, which is much more convenient than OPIE is now. - I wonder if it makes sense to worry about races? (Attacker logs your key presses, then automatically logs in after you've entered the last character but before you've pressed enter.) Probably not, when there is the danger of the ssh binary being compromised? - OPIE prevents concurrent logins. Is it possible to allow them securely, without making DOS-by-password-exhaustion possible? Cheers Benjamin