From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 4268B1381F3 for ; Mon, 14 Oct 2013 20:31:28 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id CFF91E0AFD; Mon, 14 Oct 2013 20:31:23 +0000 (UTC) Received: from mail-we0-f173.google.com (mail-we0-f173.google.com [74.125.82.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 9028BE0AA0 for ; Mon, 14 Oct 2013 20:31:22 +0000 (UTC) Received: by mail-we0-f173.google.com with SMTP id u57so7496778wes.4 for ; Mon, 14 Oct 2013 13:31:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=4yD3whi7DyQ3wQoGUFodVHh/SCDtaegbiy0IYd+THUk=; b=UkQX+Sns4bcVrX1wYTmeW6gJUE18BuUHSycv4LjkA7aWn44FkK0ew1tpf1x1AFfVQ1 E4sn0sFwqwDwirJIbzczzlqRWkt7QkQbubSBeD3dYVcqSVffx5EwsXSLci/e1dBAAof+ 20zA6ivj7SelXB44FvBnrMTWkJJJlvdyCPaOsDJZhJ/HjjZzOYYErhuyuYor/jbKNx8V 2yLwrYwYC9x7HY0JKR7JB6EPKz/X2J4+Xkfq1m3SP1S3jYcIhdJOVHQ5fzQuRqgYiwiU 3pmuHEnuMGePfmRVFtgZPkb2+MKPiy5nLA6Ided6r4oWYQtAKAMtSYq6+CWJh15wYU53 VWhQ== X-Received: by 10.180.189.132 with SMTP id gi4mr16371999wic.19.1381782681274; Mon, 14 Oct 2013 13:31:21 -0700 (PDT) Received: from [172.20.0.40] (196-210-102-9.dynamic.isadsl.co.za. [196.210.102.9]) by mx.google.com with ESMTPSA id pi6sm28096005wic.3.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 14 Oct 2013 13:31:20 -0700 (PDT) Message-ID: <525C5495.70804@gmail.com> Date: Mon, 14 Oct 2013 22:31:17 +0200 From: Alan McKinnon User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] Re: scripted iptables-restore References: <524DD388.9020507@fastmail.co.uk> <524F39F6.4040409@orlitzky.com> <525AAADE.7040700@orlitzky.com> <525ACC38.8060008@orlitzky.com> <525B1878.2010908@orlitzky.com> <525BFF1B.6070805@orlitzky.com> <525C434C.8040905@orlitzky.com> In-Reply-To: <525C434C.8040905@orlitzky.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Archives-Salt: 2c9259f3-9bbd-4587-b2c8-fa27c64e90c7 X-Archives-Hash: e899bf1464ec12f47e0911b1a228766e On 14/10/2013 21:17, Michael Orlitzky wrote: > On 10/14/2013 02:49 PM, Martin Vaeth wrote: >> >>> Hiding the salt would just be security through obscurity. >> >> And yet it is stupid if you do not do it and give away a >> huge constant factor for no advantage. >> > > (I'll just agree to disagree about the rest.) > > Keeping the salt secret makes your application more complex. Rather than > "SELECT hash, salt FROM users WHERE...", you now have to "SELECT hash > FROM users WHERE..." and then pull the salt from somewhere else. (Where? > The filesystem? Do you encrypt that? How?) > > What's stupid is going to all that effort for a 2x improvement when you > could twiddle a bit and get a 340282366920938463463374607431768211456x > improvement. > > Keep in mind the actual original purpose of a salted hash. If two users happen to use the same password[1], the hashes are the same and this is revealed to anyone who can read /etc/passwd[2] i.e everyone. Salt obscures this 1-to-1 mapping and does it in a way that it is not computationally worth while to try get around it for the general case[3]. It's not quite the same thing as security by obscurity - that is hiding something in a place you think no-one will think of looking but usually turns out to be viable to try and guess. Salt works because brute force now doesn't need just one expensive calculation, it needs many thousands of expensive calculations. If the actual problem is that salt is inadequate, the solution is not to try and hide it, but to use a more complex hashing algorithm with larger salt. It's a race between white and black hats - they build bigger and better rainbow tables, we implement bigger and better hashes. The constraint is how much cpu grunt is available for purchase at a realistic cost. [1] This is not uncommon. The domain size of all possible passwords for a implementation is very very large. Human psychology says that the actual domain size of passwords people will pick is a tiny fraction of the whole. Hence salt. [2] Nowadays we use shadow, but the development of salt pre-dates shadow -- Alan McKinnon alan.mckinnon@gmail.com