Best practice for password hashing
in [Cryptography]
|
From: Maaartin on 11 Jun 2010 08:47 On Jun 11, 12:27 pm, Carsten Krueger <cakru...(a)gmail.com> wrote: > It's unreasonable to think it's harder to get a file from LAN than from > local file because the password processing routine must have the right to > read both. It needn't be harder, just different. The attacker may exploit a badly written application allowing to read any file. There may be a firewall allowing access to the other machine for the password processing application only. The data from the first machine may leak via a backup or be brought out by an employer who has no access to the other machine. There may be a watcher on the second machine making alert when somebody tries to get all the salts at once. I don't claim, it's probable, and I'm not sure, it's worth the hassle.But it's not lying.
From: Paul Rubin on 11 Jun 2010 11:07 Carsten Krueger <cakruege(a)gmail.com> writes: > Than you coprocessor need to store secret key material. Well yes, that's the whole idea. Maybe this is just an issue of terminology.
From: Phil Carmody on 13 Jun 2010 02:37 "Datesfat Chicks" <datesfat.chicks(a)gmail.com> writes: > "Carsten Krueger" <cakruege(a)gmail.com> wrote in message > news:7eybrva607il$.dlg(a)cakruege.my-fqdn.de... > > Am Mon, 7 Jun 2010 23:41:17 -0700 (PDT) schrieb Paul Johnston: > > > >> Is there any guide on which is best to use? > > > > PBKDF2 is industrie standard (has it's own RFC). > > If I'm understanding this discussion, there are three different > approaches being discussed: > > a)Making the hash expensive to calculate. > > b)Using salt to make dictionary attacks infeasible. > > c)Using a hidden salt or hidden basis value (that won't be revealed if > the database is compromised because it exists outside the database) You then have two things you need to protect. Not just from compromise, but from DoS too. Note that it goes against at least one of Kerckhoff's principles. Phil -- I find the easiest thing to do is to k/f myself and just troll away -- David Melville on r.a.s.f1
From: Phil Carmody on 13 Jun 2010 02:39 Carsten Krueger <cakruege(a)gmail.com> writes: > Am Tue, 8 Jun 2010 13:42:49 -0400 schrieb Datesfat Chicks: > > > c)Using a hidden salt or hidden basis value (that won't be revealed if the > > database is compromised because it exists outside the database) > > That's bullshit (security through obscurity). Some might call it a 'secret key', and we generally like keeping secret keys obscured. However, having more key material than necessary, in more places than necessary, is an unwanted overhead, as keys are hard to manage. Phil -- I find the easiest thing to do is to k/f myself and just troll away -- David Melville on r.a.s.f1
From: Phil Carmody on 13 Jun 2010 02:41
Paul Rubin <no.email(a)nospam.invalid> writes: > 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. Mallory seems to always say "valid", I wonder why that is? Phil -- I find the easiest thing to do is to k/f myself and just troll away -- David Melville on r.a.s.f1 |