From owner-freebsd-security@FreeBSD.ORG Thu Jan 28 22:37:06 2010 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 998B4106566B for ; Thu, 28 Jan 2010 22:37:06 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 5DDB38FC19 for ; Thu, 28 Jan 2010 22:37:06 +0000 (UTC) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id EA4777EA40; Thu, 28 Jan 2010 22:37:04 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.3/8.14.3) with ESMTP id o0SLw5jk003465; Thu, 28 Jan 2010 21:58:06 GMT (envelope-from phk@critter.freebsd.dk) To: Chris Palmer From: "Poul-Henning Kamp" In-Reply-To: Your message of "Thu, 28 Jan 2010 10:24:13 PST." <20100128182413.GI892@noncombatant.org> Date: Thu, 28 Jan 2010 21:58:05 +0000 Message-ID: <3464.1264715885@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: freebsd-security@freebsd.org Subject: Re: PHK's MD5 might not be slow enough anymore 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: Thu, 28 Jan 2010 22:37:06 -0000 In message <20100128182413.GI892@noncombatant.org>, Chris Palmer writes: > /* > * and now, just to make sure things don't run too fast > * On a 60 Mhz Pentium this takes 34 msec, so you would > * need 30 seconds to build a 1000 entry dictionary... > */ A number of points: 1. I'm not sure slowing it down buys very much security, as far as I know, brute-forcing $1$ is still out of the question, mostly because of the wide salt. 2. Most "brute force" attacks are dictionary attacks, and slowing the algorithm down for those is pointless: The bad guys have grids of Nx100k machines to grind. Even making it take half a second will not inconvenience them much. 3. Compatibility: as far as I know, we have a configurable mechanism for choosing preferred crypt algo for new passwords, and autodetection on old passwords. 4. Encoding #rounds: one of the OpenBSD derivatives for $1$ does that, consider adoption, rather than NIH. Increased strength against rainbow and dictionaries can be had by making the low bits in #rounds a salt. 5. Cross system compat: A valid concern in some environments (See #3) and not in others. Certainly not a valid reason to never change algorithm again (see #6). 6. The major point behind $1$ was lost: You can change algorithm with a frequency of twice your password expiry time. My intent back in the middle of the nineties was not to write the "endlösung" for password encryption, but rather to point out that password hashing is "kleenex-crypto" which can, and should, be swapped at regular intervals. Every 15 years may be sufficiently regular. 7. Consider preempting the bike-shed, by asking some card-carrying cryptographers for the correct way to employ a crypto-hash algorithm in a way that does soak up some CPU time. 8. A number of interesting ideas was battered about back when $1$ was introduced, check mail archives and read the OpenBSD paper, even though it is mostly plagarism. Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.