04-28-2015 03:30 PM
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 ?
04-29-2015 02:45 AM
There are examples for bulk loading/synchronizing the user metadata on the SAS website
From this you may be able to glean a method for doing what you want to do
04-29-2015 03:26 PM
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....
04-30-2015 11:21 AM
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!
05-04-2015 11:57 AM
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), :
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 !
05-05-2015 01:23 AM
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.
05-05-2015 06:55 AM
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.
05-05-2015 08:05 AM
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.
05-05-2015 08:31 AM
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.
05-04-2015 12:09 PM
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.
05-05-2015 07:12 AM
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).
05-05-2015 10:04 AM
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.
05-05-2015 03:39 PM
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);
length id $20
type omsUri $256;
call missing(id, type, omsUri);
omsUri = "omsobj:InternalLogin?InternalLogin[ForIdentity/Person[@Name='&user.']]";
if rc ne 1 then do;
put "ERROR: user &user.@saspw does not exist!";
if rc ne 0 then put "ERROR: setting salt failed";
if rc ne 0 then put "ERROR: setting passwordhash failed";
%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.
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!
05-06-2015 01:20 AM
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.