topic Re: "CREATE INTERNAL ACCOUNT - PASSWORD UPDATE" in SAS 9.4 in Administration and Deployment

"CREATE INTERNAL ACCOUNT - PASSWORD UPDATE" in SAS 9.4

Micheal_S — Tue, 28 Apr 2015 19:30:21 GMT

Hello Everyone,

I want to know if we have any automated to resolve my below problem.

I have about 6000 users in SMC, For these users i want to update PASSWORD for INTERNAL ACCOUNT in ACCOUNTS TAB of PROPERTIES WINDOW.

One by one i can go and update the password for each user. But it will take lot of time for me to do for 6000 users so do we have any bulk load option for this ?

Thanks,

Mike

Re: "CREATE INTERNAL ACCOUNT - PASSWORD UPDATE" in SAS 9.4

Kurt_Bremser — Wed, 29 Apr 2015 06:45:41 GMT

There are examples for bulk loading/synchronizing the user metadata on the SAS website

SAS(R) 9.4 Intelligence Platform: Security Administration Guide, Second Edition

From this you may be able to glean a method for doing what you want to do

Re: "CREATE INTERNAL ACCOUNT - PASSWORD UPDATE" in SAS 9.4

Micheal_S — Wed, 29 Apr 2015 16:35:30 GMT

I already used this approach to bulk load the users, its creating users thru bulk load but not updating the passwords for internal accounts.

Re: "CREATE INTERNAL ACCOUNT - PASSWORD UPDATE" in SAS 9.4

jakarman — Wed, 29 Apr 2015 19:26:34 GMT

As I do not know of a sas bath utility for that the only other option is coding a program for that. SAS(R) 9.3 Language Interfaces to Metadata

Be aware you are on the path of accessing those passwords and by reading also can decrypt them (SAS is able tot reverse the passwords).
Updating internal passwords wil require the sasadm user that is the same role as root under Unix. Now talk to a security risks manager officer how he thinks of this....

Re: "CREATE INTERNAL ACCOUNT - PASSWORD UPDATE" in SAS 9.4

AndreasMenrath — Thu, 30 Apr 2015 15:21:37 GMT

As Jaap said: the only solution i can think of is using the SAS(R) 9.3 Language Interfaces to Metadata

The standard policy for passwords of internal accounts is that the password consists of a salted MD5 hash of the password.

It may also be a SHA1 hash (see: SAS(R) 9.3 Intelligence Platform: Security Administration Guide).

So if you have admin privileges you may edit the PasswordHash and PasswordHash properties of the corresponding InternalLogin metadata object directly.

Be very very cautious and backup your metadata before you try anything like this. You may damage your metadata beyond repair!

Re: "CREATE INTERNAL ACCOUNT - PASSWORD UPDATE" in SAS 9.4

ronan — Mon, 04 May 2015 15:57:17 GMT

I am not quite sure if this is allowed or even technically feasible (outside SAS R&D powerful realm, that means).

Try exporting your users using SAS Package (Folders tab / System / Security / Users). Then, open up the SPK archive and have a look at its content.

The 'TransportMetadata.xml' file will show you the two attributes PasswordHash string and Salt key which store the internal password.

Salted hashing make the encryption process very difficult to reproduce as far as I know. I guess SAS does not want to make public its encryption methods,

which might be standard or not.

I haven't looked at the OMI Java Doc about internal password update : I might be wrong, but I think the corresponding functions/methods are not provided for obvious reasons...

There is the SAS Deployment Manager which can update some users internal login one by one, but not bulk load these kind of changes for thousands of accounts (as far as I know).

There is also the 'SetPassword' utility, provided with SASPlatformObjectFramework set of tools. But then again, at least in 9.3, it can only update external passwords, not internal password @saspw.

You can try also the Password Update Utility / Personal Login Manager (whatever it's called, if it still exists in 9.4), :

20961 - The Password Update utility is available to update login metadata

on a per-user basis, it might be able to update a user's internal login password. Of course, you shall then deploy the tool on your users individual PC.

Good Luck !

Re: "CREATE INTERNAL ACCOUNT - PASSWORD UPDATE" in SAS 9.4

jakarman — Mon, 04 May 2015 16:09:04 GMT

Ronan. it the same xml approach that can be used as batch step. Knowing the xml structure it can be spoofed.

You just described how easy it is to hack (bad way) the metadata contents for all the sensitive content withoud leaving an traceability/auditability events for that.

Re: "CREATE INTERNAL ACCOUNT - PASSWORD UPDATE" in SAS 9.4

Kurt_Bremser — Tue, 05 May 2015 05:23:03 GMT

One could try to recreate the password hash by using the standard methods provided by UNIX systems to hash their passwords in /etc/security/passwd or /etc/shadow. Maybe SAS uses the same function internally.

See Crypt (C) - Wikipedia, the free encyclopedia

Re: "CREATE INTERNAL ACCOUNT - PASSWORD UPDATE" in SAS 9.4

ronan — Tue, 05 May 2015 10:55:33 GMT

Sure, Kurt, but this would be a little bit like reverse-engineering at random : SAS might have re-used standard encryption techniques based on Unix (eg shadow), RSA etc. but it might have done otherwise, as well. :smileyconfused: If you have a copy of the technical specs, out of curiosity I'll be very interested to have a look . I think this is typically grey area where no one outside the Dev team should have acces.

Re: "CREATE INTERNAL ACCOUNT - PASSWORD UPDATE" in SAS 9.4

ronan — Tue, 05 May 2015 11:12:48 GMT

Yes, I was curious to test quickly how the XML extraction process worked in order to use it in a batch step for updating the passwords. Then I discovered things were not so simple : SAS stored @saspw password in two components (1) Hash String / (2) Salt key. Since I am not well versed in encryption/hacking wizardry, I can't tell how difficult this would be to reproduce the process. For me, at first sight this is not a piece of cake.

Back to the original question, I suggest two possible workarounds :

1) change the user authentication directory : instead of internal (@saspw) authentication, use the company (Active Directory, LDAP etc.) exernal user database; this would take some time, but it is definitely safer and easier to maintain imho.

It's not a recommended practice to create a separate user Directory, distinct from the default Directory because this opens a possibilly of hacking user's credentials and (unwisely) assigns to the SAS Admin the responsibility to prevent the security breach.

Authentifying against the external Directory, like Active Directory can further improve both user's experience with SAS and password security if you implement Single Sign On (if available in your organisation)

2) Change the password updating process and transfer the task to the end user with the Password Update Utility / Personal Login Manager (if still available in 9.4).

Re: "CREATE INTERNAL ACCOUNT - PASSWORD UPDATE" in SAS 9.4

Kurt_Bremser — Tue, 05 May 2015 12:05:14 GMT

I was just curious if the crypt() function call would yield the same hashed password if fed with the salt from the metadata and the known password of a given user for test purposes.

One would have to write a small C program for this.

Is the System / Security folder something that was new after SAS 9.2? I can't find it in my installation.

Re: "CREATE INTERNAL ACCOUNT - PASSWORD UPDATE" in SAS 9.4

ronan — Tue, 05 May 2015 12:31:10 GMT

Yes, the system/security folder hierarchy has been available since 9.3 to include new objects like ACTs, Groups, User or Roles in the Package export/import process.

http://bi-notes.com/2013/11/sas-administration-migration-users-groups-roles/

Re: "CREATE INTERNAL ACCOUNT - PASSWORD UPDATE" in SAS 9.4

jakarman — Tue, 05 May 2015 14:04:09 GMT

Ronan, several things.

1/ The SMC is just one interface to metadata the folder structure is a new approach. With SAS-VA there is a web-based interface as has the event-manager. The real thing is the login-table part of the metadata tables and all those backups.

It is the tjem same as the id or lsuser/lsgroup command in Unix that are getting the information from the etc/password or shadow (password) or LDAP connection. The shadow password and LDAP are the real sensitive objects.

2/ Security by obscurity is bad policy often being cursed as it will break. More the question when than whether it will happen. It is better having good guys getting it hacked than the bad guys. That is what a RDP Responsible Disclosure Policy is about. Reverse engineering is allowed when there is need the validate operational consistency/integration when not delivered by te supplier(s).This is european law.

3/ Direct LDAP access is bypassing the host Unix LDAP option. Bypassing the host LDAP connection will leave you with an unmanaged host security environment. That is going into using shared accounts instead of personal accounts. This is not acceptable to normal regulations guidelines.

Yes the bad things happens, it doesn't turn them into best ones even when you call them "best practices".

4/ There is a hash and salt as documented. SAS(R) 9.4 Metadata Model: Reference . The hash will be likely a md5 (found somewhere) easy for a hacke to be checked. It should be a one-way hash according to normal indentity guidelines. We know of SAS it is a recoverable hash as it can be used in the authdomain setting for external connection not knowing anything of SAS. The found note that the salt can be changed (9.4) for internal accounts is making the same statement. As the password are not isolated (no shadowed version) there is possible breach in the same way web-shops are hacked. No they are not using the crypt() routine but there muse be a SAS password decrypt one.

I believe AndreasM can describe it completely.

Re: "CREATE INTERNAL ACCOUNT - PASSWORD UPDATE" in SAS 9.4

AndreasMenrath — Tue, 05 May 2015 19:39:30 GMT

I just played around with it. Here are my 2 cents.

I created a new internal metadata user foo@saspw and gave it the password "foobar".

Then i extracted the metadata part with the salt and hashed password.

The salt seems to be a random string. here: p2PS

The hashed pass was: cm5vLecjDeNbyNYxTDAqsg==

Now i changed the password with the management console and wrote a little SAS skript to set back the original values:

%macro setPW(user, salt, hashed_pass);

data _null_;

length id $20

type omsUri $256;

call missing(id, type, omsUri);

omsUri = "omsobj:InternalLogin?InternalLogin[ForIdentity/Person[@Name='&user.']]";

rc=metadata_resolve(omsUri,type,id);

if rc ne 1 then do;

put "ERROR: user &user.@saspw does not exist!";

stop;

end;

rc=metadata_setattr(omsUri,"Salt","&salt.");

if rc ne 0 then put "ERROR: setting salt failed";

rc=metadata_setattr(omsUri,"PasswordHash","&hashed_pass.");

if rc ne 0 then put "ERROR: setting passwordhash failed";

run;

%mend setPW;

%setPW(foo, p2PS, %str(cm5vLecjDeNbyNYxTDAqsg==))

It was a full success. After that i was able to login as foo@saspw with the original password foobar. So the password can be set for internal accounts.

BTW: i think to see SAS metadata objects of the type InternalLogin you have to be in the role Administrator. As a standard user i was not able to see these objects.

Now comes the part how you can put all findings together.

As mentioned in my post above the default hashing algorithm is MD5, but may also be changed to SHA1. See SAS documentation.

The salt seems to be a 4 character random string with uppercase and lowercase characters and digits. You may calculate a random salt by yourself.

Now some super secret SAS algorithm kicks in to take the salt and your clear text password to create a new string which should be hashed.

The output of the MD5 hash are just some bytes. To represent it like the hash observed there must be a formatting/encoding of these bytes.

To sum it up these are the steps necessary in pseudo code:

1) md5input = secretStringOperation(salt, password);

2) hashoutput = md5(md5input);

3) hashedpassword = secretFormating(hashoutput);

To figure out the steps in 1) and 3) you can just play around with my sample data on a website like this: https://quickhash.com/

HINT: i you need more than 10 tries you are thinking to complex.

Conclusion:

The whole process could be reversed in less than an hour. So there is no security here.

Is MD5 secure? Yes and no: yes, because it cannot be reverted. So it is not possible to exactly revert the original password in clear text. And no, because there are tools out there that can. See wikipedia article: MD5 - Wikipedia, the free encyclopedia

The good part is that normal SAS users are not able to see the internal logins in the metadata. Only admins. So this should not be a security issue.

But i disagree with Jaap that SAS will be able to revert the passwords. IMHO SAS will just do the steps mentioned above and compare the hash. If the user entered the password correctly then the calculated hash should be identical to the hash in the metadata and access is granted. If the calculated hash is different from the stored hash then the password has to be wrong.

Back to the original question:

yes, it is possible to change the passwords of internal accounts in batch mode. But i would not recommend it! If you change the password e.g. of the sasadm@saspw or sastrust@saspw by accident this way your SAS platform will stop working and may be damaged beyond repair!

Re: "CREATE INTERNAL ACCOUNT - PASSWORD UPDATE" in SAS 9.4

jakarman — Wed, 06 May 2015 05:16:35 GMT

Andreas, thanx for your extensive explanation. I agree with you argmumentation, so where is the point we are in disagree.
That is the external connection option AUTHDOMAIN=. What is up there, that we are in disagreement?

- The user and password validation is done by the external side, for instance Oracle, SQL-server, Postgres Teradta or whatever.

That password validation is done by unknown routines by SAS and the external doesn't know anything of SAS.

- The only option I see how this can work is that the User/Password is handed over is some part of the interface of the connection.

As the ODBC interface client of the RDBMS is support encryption over the wire by his own dedicated than the place the password is clear text must be a that interface.

- The external Authdomain is stored often the PWencode option.

My conclusion is that that part must be reversible and not a one way hash.

Re: "CREATE INTERNAL ACCOUNT - PASSWORD UPDATE" in SAS 9.4

Kurt_Bremser — Wed, 06 May 2015 05:20:20 GMT

The problem with readable hashes is not that it could be possible to recreate the original password, but (with enough computing power) to create or find "a" password that leads to the same hash. For UNIX passwords there are databases that fit onto a single CD that let you crack most systems once you can read the hashed passwords. Unless the important users have randomly generated PWs.

Re: "CREATE INTERNAL ACCOUNT - PASSWORD UPDATE" in SAS 9.4

jakarman — Wed, 06 May 2015 17:43:22 GMT

Kurt, Andreas, I agree that hashes shouldn't be a reverse hash like AES TLS. This is how normally user passwords are treated.
Now see this one: SAS(R) 9.4 Intelligence Platform: Security Administration Guide, Second Edition It is documented by SAS you can downgrade to MD5 (sas002)

" Set the following options:

STOREPASSWORDS="SAS002"
HashPasswords="MD5"

Note: The latter setting is within the InternalAuthenticationPolicy section of the omaconfig.xml file."

It is followed by the description of a process you can reencrypt the existing stored passwords.
Please explain how this is possible when then decryption of the original password is not possible. It is a contradiction isn't it?

Re: "CREATE INTERNAL ACCOUNT - PASSWORD UPDATE" in SAS 9.4

AndreasMenrath — Thu, 07 May 2015 13:44:03 GMT

No, it's not a contradiction. But you need to distinguish between two types of passwords:

1) SAS Internal passwords, which are only used for SAS Internal Accounts which are hashed in MD5 or SHA1.

2) SAS encoded passwords for all the rest (database users, OS users, LDAP, etc.). Encoded passwords use the SAS internal algorithm SAS001, SAS002, SAS003 or SAS004 and can be decoded back to the original password in clear text by SAS.

The documentation you referenced says it only supports reencrypt existing stored passwords and exchange the master passphrase for SAS003 and SAS004 encoded passwords.