Project

General

Profile

Actions

Bug #8593

closed

UserManagement need to have hashed password for both Linux and AIX

Added by François ARMAND almost 8 years ago. Updated over 7 years ago.

Status:
Released
Priority:
N/A
Category:
Web - Config management
Target version:
Severity:
UX impact:
User visibility:
Effort required:
Priority:
Name check:
Fix check:
Regression:

Description

In #4785, we added the old school Unix 56bit DES "crypt" hash for AIX.

But the is too limited, because 1/ AIX support its own version of SHA-* hashed password, which should really be used by now, and 2/ we want to be able to transparently defined user on both AIX and Linux plateform in one directive, and have Rudder do the hard work of knowing what the plateform need.

For 1/ we need to conform to method described in http://superuser.com/questions/906771/can-i-manually-replace-password-hashes-in-the-aix-etc-security-passwd-file and format described in http://www.ibmsystemsmag.com/aix/administrator/security/password_hash/?page=2

For 2/ we need to generate two hash variables for each user, one with Aix format, the other with Linux shadow format.


Subtasks 5 (0 open5 closed)

Bug #8626: Adapt DirectiveEditor for master-slave password fieldsReleasedNicolas CHARLES2016-06-30Actions
Bug #8627: Create UserManagement v7 with a variable for AIX passwordsReleasedBenoît PECCATTE2016-07-19Actions
Bug #8708: Missing entry in list of maintained technique after creating usermanagement v7ReleasedAlexis Mousset2016-07-19Actions
Architecture #8707: Upmerge #8593 into RudderReleasedNicolas CHARLES2016-07-19Actions
Bug #8713: Missing sealerate as dependencyRejectedVincent MEMBRÉ2016-07-19Actions

Related issues 2 (1 open1 closed)

Related to Rudder - Bug #4785: Missing "Unix Crypt Des" algo type for AIX passwordReleasedNicolas CHARLES2014-04-29Actions
Related to Rudder - User story #8632: Password-Type field in metadata.xml could use a double-check fieldNewActions
Actions #1

Updated by François ARMAND almost 8 years ago

  • Related to Bug #4785: Missing "Unix Crypt Des" algo type for AIX password added
Actions #2

Updated by François ARMAND almost 8 years ago

  • Related to Bug #6963: The user creation technique doesn't work on AIX added
Actions #3

Updated by François ARMAND almost 8 years ago

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.

Actions #4

Updated by François ARMAND almost 8 years ago

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.

Actions #5

Updated by Nicolas CHARLES almost 8 years ago

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.)

Actions #6

Updated by François ARMAND over 7 years ago

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 "..".

Actions #9

Updated by Nicolas CHARLES over 7 years ago

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

Actions #10

Updated by François ARMAND over 7 years ago

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.

Actions #11

Updated by François ARMAND over 7 years ago

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.

Actions #12

Updated by François ARMAND over 7 years ago

  • Subject changed from Need to output same power hashed password for both Linux and AIX to UserManagement need to have hashed password for both Linux and AIX

So, thanks to hashcat code, we found that AIX doens't ACTUALLY USE SHA-CRYPT. These is a little frustrating. But now everything is ok, and people looking for how to hash password for AIX will be able to find it in class AixPasswordHashAlgo.

Actions #13

Updated by François ARMAND over 7 years ago

  • Status changed from In progress to Pending technical review
  • Assignee changed from François ARMAND to Nicolas CHARLES
  • Pull Request set to https://github.com/Normation/cf-clerk/pull/84
Actions #14

Updated by Jonathan CLARKE over 7 years ago

  • Related to deleted (Bug #6963: The user creation technique doesn't work on AIX)
Actions #15

Updated by François ARMAND over 7 years ago

  • Related to User story #8632: Password-Type field in metadata.xml could use a double-check field added
Actions #16

Updated by Nicolas CHARLES over 7 years ago

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

Actions #17

Updated by François ARMAND over 7 years ago

  • Status changed from Pending technical review to Pending release
  • % Done changed from 0 to 100
Actions #18

Updated by Alexis Mousset over 7 years ago

  • Status changed from Pending release to Released

This bug has been fixed in Rudder 3.1.12 and 3.2.5 which were released today.

Actions

Also available in: Atom PDF