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. ... View more

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! ... View more

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! ... View more

Da kein Feedback mehr von Holly kam und mir die Antwort als plausibel erscheint, markiere ich die Antwort von run; als richtige Antwort um die Lösung zu honorieren. ... View more

Hallo Herr Braun, genau hierfür ist die Kategorie Projekte und Tools gedacht. Und nützliche Tools kann schließlich jeder gebrauchen 🙂 Hiermit möchte ich mein Interesse an Ihrem Vorschlag bekunden und mich schon einmal herzlich für Ihre Mühen bedanken. Viele Grüße, Andreas Menrath ... View more

Hallo Hans, für ihr Einsatzszenario zur Datenabfrage würde ich generell von der Verwendung von Webservices abraten. Insbesondere bei größeren Datenmengen bekommt man ziemlich schnell Probleme. Außerdem hat man noch ziemlich viel Mehraufwand, da man den Webservice schreiben muss und auch noch die Daten in das entsprechende Übertragungsformat (XML oder JSON) konvertieren muss. Anstelle eines Webservices würde ich empfehlen die von SAS bereitgestellten Daten-Schnittstellen mit ODBC-, OleDB- oder JDBC- Treibern zu verwenden. Ich gehe davon aus, dass SAP mindestens einen der oben genannten Treiber unterstützen wird. Die Daten lassen sich dann einfach mit SQL Syntax abfragen und auch einschränken, z.B. select * from libref.tabelle where Kundennummer = 123 Viele Grüße, Andreas ... View more

PS: bitte den eigenen Beitrag bearbeiten und nicht ständig einen neuen Beitrag anlegen! Die 4 anderen Beiträge zum selben Thema wurden daher gelöscht. ... View more

Hallo Swen, eine solche Einstellung ist mir nicht bekannt. In der Regel behindern die automatischen Vorschläge von SAS aber auch nicht den Programmierfluss, d.h. Sie können den Variablennamen auch einfach weitertippen, während die Autocomplete-Suche noch läuft. Viele Grüße, Andreas ... View more

Hi Chris, thank you for your valuable feedback. I finally found some time to play around with this feature and the settings. My findings are also based on SAS(R) 9.4 Guide to Metadata-Bound Libraries, Second Edition. 1) To my former post: DESCRIBE VIEW requires ALTER priviliges in the metadata for the view. Even if these rights are granted the user won't see the password as clear text in the log. Instead the log contains some information like that: select *  from LIB.TABLE(read=XXX write=XXX alter=XXX); 2) Chris@SAS wrote: As I noted in my article, the password value is not a security loophole or backdoor that can grant access to anyone who knows it. It's simply like a PIN for the administrator to later make changes to the contents of the secured library or its properties. Still, admins should guard the password and keep track of it. I highly disagree. These passwords are the keys to the kingdom. Users who have metadata read rights on the secured library can use it to bypass all security layers. That's exactly what the row-level security concept does; therefore it is necessary to include the passwords in the view, because the user who will execute the view will not have metadata read and select rights on the secured table with all rows. I used this code for some tests on a copy of the sashelp.prdsale table: libname sample 'C:\SAS\SomeSampleData\RowLevelSecurityTest'; proc authlib library=sample;    create securedlibrary='sample' securedfolder='RowlevelSecTest'       pw=secret; quit; proc sql;    create view sample.prdsale_subset as       select *       from sample.prdsale(pw=secret)       where _METADATA_AUTHENTICATED_USERID_ = 'SASNOBODY@SAS94'            and country = "GERMANY" ; quit; Then i used SMC to grant a test user only access to the prdsale_subset table. When i access the view as the test user i find some warnings in the log: WARNING: The secured table object information for data set SAMPLE.PRDSALE.DATA could not be obtained from the metadata server or          has invalid data. WARNING: The metadata server does not have a secured table object with the external identity "67AB2A08-XXXX-XXXX-XXXX-XXXXXXXXXX"          or you do not have ReadMetadata permission to see it. When this test user knows the password to the library then the security can be completely bypassed and the user can access all tables and rows inside the secured library: proc sql;   select *   from sample.prdsale(pw=secret); quit; 3) at last it is confusing that this test user which has only basic rights can see all passwords associated with the secured library: When the metadata object is exported i can see that the password "secret" was stored as "{SAS014}60AF7C50405EC46419AAAAA8" inside the metadata. I hope that this password cannot be reversed as easily as the other {SASxxx} encoded passwords and are really good "battle-tested". Best Regards, Andreas ... View more

Wow, amazing security concept. Putting passwords inside of a view! Has anyone considered that a malicious user could just run a PROC SQL; DESCRIBE VIEW <view_with_passwords_inside>; QUIT; and steal the passwords inside to bypass all your security layers to view all rows? My experience on row-level security in a nutshell: it can only be achieved if you can ensure that your end users cannot run custom code on the application servers. ... View more

Ich habe den Trick auch gerade bei SAS Studio ausprobiert. Hier funktioniert das leider nicht . Der Code wird immer unformatiert in die Zwischenablage kopiert. ... View more