[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120814014652.GC27715@brightrain.aerifal.cx>
Date: Mon, 13 Aug 2012 21:46:53 -0400
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: Todo for release?
On Tue, Aug 14, 2012 at 02:20:58AM +0400, Solar Designer wrote:
> On Mon, Aug 13, 2012 at 11:31:54PM +0200, Szabolcs Nagy wrote:
> > the sha2 based crypt seems to be designed recently
> > and the spec has a public domain implementation
> > http://www.akkadia.org/drepper/SHA-crypt.txt
>
> Unfortunately, the reference implementation uses alloca() on both salt
> and key strings.
Why? Does it need working space proportional to the input length?
> glibc has recently fixed that by using malloc() and
> returning NULL on its failure, but that's not great.
Hmm, and as you've pointed out several times, that means the daemon
will almost surely crash, since few of them check for failure...
> Also, if potentially unreasonably long running time is a concern, it
> should be noted that for md5crypt and sha*crypt it is roughly
> proportional to password length (modulo block size of the underlying
> primitive). So e.g. a 1 million char password (which may realistically
> be passed to libc's crypt() e.g. via a scripting language) may take
> thousands of times longer to be hashed than the sysadmin had intended by
> tuning the iteration count.
>
> I'm not sure whether and how a libc should deal with that. In a sense,
> it is similar to the issue of high iteration counts, but it's worse in
> that the input that may trigger the issue very often comes from a remote
> system.
In light of both the alloca issue and the way runtime scales with key
length, I think we should just put an arbitrary limit on the key
length and return failure for longer keys. This should not affect any
real-world authentication systems, since the daemon you're attempting
to login to will also be placing a (probably much lower) limit on the
input buffer size for passwords (if it's not, you can trivially DoS
the server by sending gigabyte-long passwords for random users).
Something like 128-256 bytes would probably be a very generous limit.
> For the extended DES-based crypt() hashes that we now support, this
> issue mostly does not arise since the password (even if very long, which
> is supported) is passed through just one instance of DES block-by-block,
> which is quick. The multiple iterations loop is then applied to the
> "compressed" version of the password.
>
> For bcrypt hashes, the issue does not arise because they truncate
> passwords at 72 characters (not great, but that's how they're defined,
> and it's good enough for practical purposes so far).
Thanks for explaining the issues well.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
