Message-ID: <CAFWeb9+j3Dfdv9=neF_Bo-sLS+U+UpPJxuUo1PQ0haGzjWdHSw@mail.gmail.com>
Date: Tue, 19 Feb 2013 01:50:40 +0000
From: Alec Muffett <alec.muffett@...il.com>
To: discussions@...sword-hashing.net
Subject: Re: [PHC] Password hashes as URIs

On 18 February 2013 23:45, Tony Arcieri <tony.arcieri@...il.com> wrote:
> A scheme like this could allow someone to have several different password
> hashing schemes active at once (e.g. if they started with one scheme but are
> lazily upgrading to another, newer scheme) and would also allow
> interoperability between these libraries.
>
> Yay? Nay?

OK; when I was at Sun, Casper Dik, Darren Moffat and I came up with
the "Pluggable Crypt" framework to address the desire to want to
intermingle different kinds of hash in one directory/map/password
file, and to support upgrades.

And, frankly, to do something better.

A lot of the backplot is documented here:
http://dropsafe.crypticide.com/article/1389 - which I won't bother to
cut and paste from since it's fairly readable; the companion algorithm
(SunMD5) is something that Alexander will rant about at length if you
permit, but that's not relevant right now. :-)

What might be relevant was what we were trying to do, which was
support having ciphertexts which looked a bit like this:

   $caesar$shift=13$frfnzr

...which any reasonably intuitive cryppie will work out has a
plaintext of 'sesame'; similarly we wanted:

    $sha256$rounds=9000,usersalt=fred,sitesalt=/etc/sitesalt$hTZC3WSMcaAro.iC6RMgU.Ek.....

...or possibly:

    $sha256$usersalt$sitesalt$resultinghash

...and we got into a massive, multi-week argument about formats of
data, whether we should go with "$" separators between positional
fields throughout - or establish an encoding system for
"key1=value1,key2=value2" - somehow guaranteeing that the keys and
values would be clean (free of ":" characters that would corrupt
passwd records - solution: base64 everything) and and and ...

It was a bit of a nightmare.

Eventually we hit on a solution: "stop being control freaks"

So instead the pluggable crypt architecture goes looking for
ciphertexts beginning with "$" and uses whatever comes after the first
"$" and before the next dollar-or-end-of-string to look up the name of
a shared library as specified in a config file:

    http://docs.oracle.com/cd/E19253-01/816-4557/concept-23/index.html

The remainder of the string, from the second "$" onwards (INCLUSIVE)
is *passed into* that shared library for it to do as it damn well
pleases.

End of problem, end of furious geek argument.

Tony may well like the contents of the manpage I linked to, it
contains stuff like:

  CRYPT_ALGORITHMS_ALLOW=1,2a,md5,5,6
  CRYPT_ALGORITHMS_DEPRECATE=__unix__
  CRYPT_DEFAULT=2a

...which specifies which hashes our system recognises (allow) and
which ones it will never allow you to create a new has using
(deprecate; here we are deprecating the traditional Morris crypt so
that we evolve away from it with each new password change) - and
finally which algorithm will be used to generate a new has should a
specific one not be specified (default; in this case 2a, which is
Blowfish).

The complementary half to this is the dynamically loaded
crypt_gensalt() routine:

    http://docs.oracle.com/cd/E19683-01/817-0677/6mgf9b5sh/index.html

...which when passed both the user's previous salt and a "userinfo"
(pw_passwd) structure, would generate a new salt prefix for whatever
algorithm was now de jure.

The reason for this was obvious: putting usernames and other stuff
into saltstrings was highly desirable, plus it was an opportunity/hook
for automatically increasing the number of rounds / or whatever new
administrative policy thing we wanted to enforce. Such policy could be
provided with "key=value"-type syntax, something like:

           caesar /usr/lib/security/$ISA/crypt_caesar.so shift=13

...in this config file, so that syntax came in handy after all; still
easier not to assume you can parse the actual *ciphertexts* though.

Overall it is very well-received and successful; several OSF/1 sites
implemented the DEC "crypt16()" shared library, marked it as ALLOWed
but DEPRECATEd, with a default of "2a" and then told their users to
change their passwords.  The result was a transparent migration to
Blowfish.

Some of the discussion around people doing exactly this can be found in:

https://groups.google.com/group/comp.unix.solaris/browse_thread/thread/6c6d589f4dfa6ba/e3dbf82cbea86989

And then there were the Government agencies which insisted on
rolling their own hashes and where formerly they had to have
replacement binaries for indefinite numbers of applications, suddenly
everything worked transparently.  I don't know if they were pleased or
annoyed by that.

Hope this helps.  In summary I would say that, from experience,
arguing over a URI syntax will just drive you insane.  Easier just to
agree on a text encoding for everything after the second "$" sign and
leave that to the implementors to sort out.

    - alec

Links:

crypt_gensalt: frontend for salt generation
http://illumos.org/man/3C/crypt_gensalt

crypt_gensalt_impl: implementation-specific backends for salt generation
http://illumos.org/man/3C/crypt_gensalt_impl

crypt_genhash_impl: implementation-specific backends for hash generation
http://illumos.org/man/3C/crypt_genhash_impl

sample code
https://github.com/illumos/illumos-gate/blob/master/usr/src/lib/crypt_modules/bsdbf/bsdbf.c
https://github.com/illumos/illumos-gate/tree/master/usr/src/lib/crypt_modules/bsdbf
(directory)

sunmd5
https://github.com/illumos/illumos-gate/blob/master/usr/src/lib/crypt_modules/sunmd5/sunmd5.c

crypt.conf / config files
http://illumos.org/man/4/crypt.conf
http://illumos.org/man/4/policy.conf # solaris broke out some of the
function to this for some reason


-- 
http://dropsafe.crypticide.com/aboutalecm

Powered by blists - more mailing lists