Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 15 Aug 2012 07:00:02 +0400
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: SRP

Jim -

This is very nice.  Thank you!

On Tue, Aug 14, 2012 at 10:09:31AM -0500, jfoug wrote:
> I am not sure of the leak. I have seen no 'real' hashes.

Same here.  How about we target genuine SRP as released at
http://srp.stanford.edu/download.html for now?  That would be of some
use on its own - hopefully even of more use than targeting Blizzard's
"custom SRP".

> At this time, I am hesitant to release this, since we really do not
> know if this is correct,

Maybe you can build/install SRP, generate some test verifiers, and use
those?  I just downloaded srp-2.1.2.tar.gz from the URL above and took a
look.  At first glance, it appears to use SHA-1 in the verifiers.
Specifically, I looked at the function t_makepwent() and its uses from
base/src/passwd.c and base/pam_eps/pam_eps_passwd.c.

> Some 'assumptions' I have made:
> 
> Username data uppercased.
> 
> Password uppercased.

When we don't target Blizzard's SRP verifiers specifically, these
assumptions will need to be removed or made optional.

> Format is:
> $WoWSRP$256_bit_hash_in_upper_case$salt_in_upcase_hex*USERNAME_UPCASE

The official SRP distribution already includes some code to format
verifiers as ASCII strings:

_TYPE( void )
t_putpwent(ent, fp)
     const struct t_pwent * ent;
     FILE * fp;
{
  cstr * strbuf = cstr_new();
  char saltbuf[MAXB64SALTLEN];

  fprintf(fp, "%s:%s:%s:%d\n", ent->name,
	  t_tob64cstr(strbuf, ent->password.data, ent->password.len),
	  t_tob64(saltbuf, ent->salt.data, ent->salt.len), ent->index);
  cstr_clear_free(strbuf);
}

We can't use the colon between the encoded ent->password.data and
ent->salt.data, but with the colon replaced by '$' the rest of the
string format should be usable as-is.  prepare() can take care of
extracting field[1] and field[2].

Thanks again,

Alexander

Powered by blists - more mailing lists

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ