Rudder

Some more thoughts and constrains.

At a functionnal level:

- we need to make a new version of the technique
- we need to remove "linux-" in the name of hash (because it does not make sens to have "linux-shadow-sha256" for something usable for both Linux and AIX (and perhaps other in the future))
- we need to be able to migrate transparently from previous version of the technique to that one for pure Linux user, either by keeping the "linux only" version (quite ugly), or by having a way for the new hash type to read/use previously stored linux algo. No way someone with only Linux box want to redefined all it's user password when migrating the technique.

At a technical level:

We have a USERGROUP_USER_PASSWORD variable in metadata, and today it is used in the .st file like:

&USERGROUP_USER_PASSWORD:{password |"usergroup_user_password[&i&]" string => "&password&"; }&

The general idea is to be able to have variation based on the OS, so something like

&USERGROUP_USER_PASSWORD_LINUX:{password |"usergroup_user_password_linux[&i&]" string => "&password&"; }&
&USERGROUP_USER_PASSWORD_AIX:{  password |"usergroup_user_password_aix[  &i&]" string => "&password&"; }&

So we need to have the "password" input type generate several variable available in string template.

And finally, we don't have versionning at the variable type level.
So, either we build a new password input type (which could make sense if the UX evolve a lot between current version and next one), or we need to ALSO keep USERGROUP_USER_PASSWORD variable available in string template, to still have previous version of technique working.

Having a new input type may make even more sense if we decide to change the UI of the field.

For more context, currently we store values in that format in LDAP:

USERGROUP_USER_PASSWORD[0]:linux-shadow-sha512:$6$CtSfMmHE$lbSEZCFlClrR4izHt2Q.4ns/Y9gBw4dUpuhxJFOQUkdoMLBKxzaK3lAqSMR2.9Vmbu3A4zHXwMc8IIPgRxxhT.

So, that's not really good to make it extensible. But, at first look, it could be kind of JSON:

{ 
    "linux-shadow-sha512" : "$6$CtSfMmHE$lbSEZCFlClrR4izHt2Q.4ns/Y9gBw4dUpuhxJFOQUkdoMLBKxzaK3lAqSMR2.9Vmbu3A4zHXwMc8IIPgRxxhT." 
}

And then, extended like:

{ 
    "linux-shadow-sha512" : "$6$CtSfMmHE$lbSEZCFlClrR4izHt2Q.4ns/Y9gBw4dUpuhxJFOQUkdoMLBKxzaK3lAqSMR2.9Vmbu3A4zHXwMc8IIPgRxxhT." 
  , "aix-sha512": "{ssha512}06$otYx2eSXx.OkEY4F$No5ZvSfhYuB1MSkBhhcKJIjS0.q// wdkcZwF9/TXi3EnL6QeronmS0jCc3P2aEV9WLi5arzN1YjVwkx8bng.." 
} 

Etc.

So a migration path from userManagement 6 => the one implementing that could be not that hard to build.

Detail on how the AIX password is hashed:
Using sha256 or sha512, the default salt_len is 16 on AIX while on Linux i believe its 8

On AIX they use hashing iterations and default cost_num is 6 (default hashing iterations is 2^cost. The valid value of cost is an integer between 4 and 31, inclusive.)

So, as feared I can't reproduce the AIX output based on standard sha2crypt algo in Apache commons-codec, based on http://www.akkadia.org/drepper/SHA-crypt.txt

So, either there is something different in the actual AIX implementation, or I didn't get the correct parameters somehow.

Example: for a password "secret", with SHA-512, with cost of 10, so 2^10 (i.e 1024) rounds:

aix: {ssha512}10$ty4Mu0qM6c2vUZnV$r2/uxZIca0ilpsGATRX4fRwFX0sfJ.4mbYQO92dyZcZ63feBvpBp5yfYFFbN3jQZt3fArg0wbqZp0cGLmlpn..
me : {ssha512}10$ty4Mu0qM6c2vUZnV$UwKzx844eYD.sr9CzBRO9/j8QtsrCV6BpzZCjtMGGrtbgVANNTwtLj3p6SeVWNT92nsOuLENgIrBw2Z8wX3h80

(yeah, all the known parts are ok, only the hashed one is problematic :)

Something is strange. Whateever the cost, AIX hash seems to ends with "..".

This is not very encouraging: http://www.openwall.com/lists/john-users/2013/02/13/12

you might be interested in
http://www.ibmsystemsmag.com/aix/administrator/security/password_hash/?page=2

and also http://hashcat.net/hashcat/ that can reproduce AIX sha hash

Nicolas CHARLES wrote:

you might be interested in
http://www.ibmsystemsmag.com/aix/administrator/security/password_hash/?page=2

It was actually on the description of the ticket, but don't say anything on the actual algo used.

So, I didn't find any discussion about what is actually used in AIX.

As noted by Nicolas, hashcat DOES have support for AIX scheme (md5, sha1, sha256, sha512). The source code even contains a "sha512aix_encode" function defined in src/engine.c, used in src/hashcat-cli.c.

The code is a little obscure to me (I would say highy optimized C crypto code :) but it should be possible to use that to get the algo and translate it into Java. It will need quite some work, though.

this is super confusing that the derive is lowercase, but the resulting variable name is uppercase