From owner-freebsd-security@FreeBSD.ORG Thu Jun 21 19:38:18 2012 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 61CB21065672 for ; Thu, 21 Jun 2012 19:38:18 +0000 (UTC) (envelope-from astounding@gmail.com) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id CFFA38FC15 for ; Thu, 21 Jun 2012 19:38:17 +0000 (UTC) Received: by lbon10 with SMTP id n10so3176684lbo.13 for ; Thu, 21 Jun 2012 12:38:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=KV5csiK8//XkD/cz7E5Kg5mMeJbSQfgOMVHXqrmEKpk=; b=O8udXd+Nk4Aw7bL6z2cQJH/U3PTqDrx9YoXKEV2PuMHHHy68BgWU4hSdj6drpFRXUf Tuvp3riwEtpRPHMuLFsNQMExMmcdiNVpdGaBtv3orIDB92gBOMQ8gjZuha1ogLTG5L0f CwyV7bDmt/G6mFpa3xnL/2xz8Tm8q0d0ZctmrclYPIsPcgWR9ggeIfEKHM+VxAgc9Ogj un55C+6DXLxUjQLOwJxHgT6U5wtWfYWjOggUaQa11qex/L+jBKNArTwSAVi9NX+EouDx /ZxBChSfWRW3y3pV50gk4QFWHPZB12sIudIzzdFyw6WQidGER5JwH+MRFi0UtVAWMDmK ggXA== MIME-Version: 1.0 Received: by 10.152.105.173 with SMTP id gn13mr27589502lab.20.1340307496518; Thu, 21 Jun 2012 12:38:16 -0700 (PDT) Received: by 10.112.26.2 with HTTP; Thu, 21 Jun 2012 12:38:16 -0700 (PDT) In-Reply-To: References: Date: Thu, 21 Jun 2012 13:38:16 -0600 Message-ID: From: "Aaron D. Gifford" To: freebsd-security@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: Default password encryption method. 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, 21 Jun 2012 19:38:18 -0000 On Tue, Jun 19, 2012 at 12:14 PM, Simon L. B. Nielsen wrote: ..snip... > The FreeBSD Security Team is also looking at (/poking people to look at) > solutions which will improve the the time it takes to brute force passwords > significantly more. > > -- > Simon I'd love to see PBKDF2 as a password hashing method. Yes, it's meant for deriving key material, but it can function similarly. It has the flexibility of allowing different hashes being used for the HMAC PRNG portion, and the ability to vary/specify the number of iterations. No, it's not memory complex like scrypt, but personally I prefer to not yet have memory usage involved. I could foresee PBKDF-HMAC-SHA512 or PBKDF-HMAC-SHA256. I would select the quantity of output to match the hash size selected (i.e. if I use HMAC-SHA512 for the PRNG portion of PBKDF2, I would have PBKDF2 generate 512 bits of output to store in my password database). PBKDF2(pseudo-random-function, password, salt, iterations, output-size) I'd offer HMAC-SHA256 and HMAC-SHA512 initially for the pseudo-random-function parameter. And I'd select output-size as mentioned above, 256 bits for HMAC-SHA256, etc. As for iterations, how hard would it be to allow for more variation in the base-64 encoded salt field in the master password database such that for a PBKDF2 scheme, the field used as salt would actually be three fields, an 4-bit pseudo-random-function selector and a 32-bit unsigned integer number of iterations (or 36 bits, which base-64 encoded would be 6 characters) followed by a variable length salt (i.e. any length permitted by the master password database structure up to the '$' character delimiter)? Or one could simply define separate algorithms for each PRF (pseudo-random-function) available. But, storing the number of iterations with the stored salt has the benefit of not requiring a new algorithm be defined when one wants to increase the default security level of hashed passwords. One merely need to change a system setting to default to use more iterations. And password databases from other systems with a higher or lower setting would still be readable and usable. Brainstorming session over... for now. Aaron out.