From: Paul Rubin on 10 Jun 2010 05:59 Carsten Krueger <cakruege(a)gmail.com> writes: > Hidden salt never can work. > The machine that stores the salt has to give it away to allow password > check. > If you compromise the password checking machine you have access to the > hidden salt. Do the password check on the other machine (crypto coprocessor). This is a standard practice in high-security applications, using host security modules (HSM's). A low rent version could use a smart card or iButton: http://www.maxim-ic.com/quick_view2.cfm/qv_pk/3557 http://www.maxim-ic.com/quick_view2.cfm/qv_pk/2822
From: unruh on 10 Jun 2010 14:53 On 2010-06-10, Carsten Krueger <cakruege(a)gmail.com> wrote: > Am Wed, 09 Jun 2010 16:37:36 GMT schrieb unruh: > >> Security through obscurity is fine, > > Hidden salt never can work. Yet is does work. > The machine that stores the salt has to give it away to allow password > check. > If you compromise the password checking machine you have access to the > hidden salt. Notice your sentence is a conditional sentence. If. That gives the attacker another roadblock and as long as that roadblock holds ( and against many attackers it will hold forever) it provides extra security. When it falls, it does not. The problem is not that it does not provide security. The problem is that you have no idea if the security has failed. Thus security through obscurity IS a defence, but not one you should rely on. You should assume it is broken in evaluating the resistance of your system, and then put it in as an extra roadblock. > > greetings > Carsten
From: Paul Rubin on 10 Jun 2010 17:38 Carsten Krueger <cakruege(a)gmail.com> writes: > If you don't compromise the password checking machine, you don't need > hidden salt, since you don't even have the hash. The idea is you send the password and hash to the coprocessor, and the coprocessor tells you whether the password is valid.
From: Maaartin on 10 Jun 2010 20:10 On Jun 10, 11:00 pm, Carsten Krueger <cakru...(a)gmail.com> wrote: > It doesn't bring any effect to put the salt on a different machine because > you need free access for every password check. So there is nothing that an > attacker has to circumvent with time and effort. > > It's lying to yourself if you think hidden salt make attacks harder. Why do you assume there's only one kind of compromising a machine? The attacker can e.g., get a possibility to read any local file, but nothing else. In this case salt hidden on the other machine would help. For sure, it may go the other way round, so you can't depend on such a policy, and the probability it helps is hard to evaluate, but it's not useless.
From: Kristian Gj�steen on 11 Jun 2010 03:34
Carsten Krueger <cakruege(a)gmail.com> wrote: >Am Thu, 10 Jun 2010 02:59:02 -0700 schrieb Paul Rubin: > >> Do the password check on the other machine (crypto coprocessor). > >That doesn't help. The hidden salt isn't stored in the crypto coprocessor. > >And if it would be storable there, than you could store the complete hash >in it. You store an encrypted version of the salt, the coprocessor can decrypt. Of course, there are other possibilities, e.g. store a MAC of the key. -- Kristian Gj�steen |