system password

[Ivy]

Dearl all, 

I need to use my system name and password to log in a server database. 

I would like to creat a Macro program for the system name and password. I can use " sysuserid " to get my system ID. Is there any function I can get my system password ?

Thank you very much,
Ivy 

[Kurt_Bremser]

No.

The system only stores an encrypted hash of the password against which the password you enter is verified. No system ever holds the entered password any longer than the login process takes. Not in files, and not in memory.

BTW, the hash is usually stored in a protected location only accessible to the system's superuser.

Either set up a system for single sign on across applications, or keep on entering passwords where needed. Anything else is extremely dangerous, securitywise.

[jakarman]

Kurt,  "No system ever holds the entered password any longer than the login process takes. Not in files, and not in memory." 
Than knowing SAS does this it several places... The metadata hashes can be read. During a cleint session the connection can be reestablished. The pwencoded hashed can be reverted as external systems do not understand SAS pwencode but you can use those in sas programs. That is hurting security compliancy.

[Kurt_Bremser]

When I use "system" in that context it always means operating system. And there may be "operating systems" that do keep passwords in memory, but those are not operating systems at all, no matter what they call themselves.

[jakarman]

Kurt, can't resist as the security design of Unix is the worst of any OS used these days. Why?
- having a service process running it doesn't reflect any changes in the associated groups of the current security definition. You have to rstaret service processes.  At Windows and Z/OS you don't need that restart. 
- the sys_auth memory control blok is still limited to 16. Unless you are aware of that you can be trapped that have more that 16 groups associated wiht a key will drop those without any warning or notice. Possible opening up access not being intended.

- The securiyt model at unix the DAC approach is that difficult for al lot of people that they want the ACL approach of Windows.

Dont bother about user context switching (sudo) it should fixed these days as even that could behave unexpectly different (3 phases).

The usage of privliged accounts in the aspect of security compliancy s still not understood by a lot of SAS technicians. 
It makes not much sense bashing OS you don't like. The best thing would ber understanding them all.

[Kurt_Bremser]

Jaap,

<RANT>

and that's why the UNIXen are flooded with viruses and trojans, while Windows is completely unscathed. Heh.

Sorry, but I go with the track record here, and with manageability. Windows is utter bull**bleep** in both respects. IMO. Just look at the hoops people need to jump through to get a SAS batch scheduled in Windows.

Restarting processes in UNIX is a) no hassle and b) usually not necessary, just do a kill -1. If a service process can't do that, than the programmer of the service process messed up, not Thompson, Kernighan and Ritchie. Who had more brains regarding system design than the moron Gates by orders of magnitude. (Gates is a moron when it comes to computers, but he's a genius when it comes to selling fridges to the Inuit)

On top of that, you have to relearn everything with every major Windows release. API changes, UI changes, as if everything before was dreck.

All the UNIX knowledge I started to acquire 30 years ago is still in use.

I stopped supporting Windows anywhere some 15 years ago; I got better things to do with my time, and I try to keep my blood pressure low.

Sometimes I get the feeling that if we transferred the dumbest monkey from the Schoenbrunn Zoo to Redmond, the average IQ in both locations would rise.

</RANT>

[jakarman]

Kurt, I am working and promoting the Unix SAS approach. The frustrations as bad managability of that by human opinions is the real lif fact. I doesn't help or improve that situation to go into flames and giving rants.  isn't it.

The better approach IMO would be to admit all those shortcomings and work on making them better by:

- some technical replacements
- attitude behavior changes.   (eg allowing privileged accounts and bartch scheduling at Unix)
- use the advantages of a Unix instead of violating those.  

  

[jakarman]

You could use alle those mentioned options. One other option SAS-base code based is having that extrenal sensitive data being stored in a password encrytped (in reality the hash is the password) SAs-dataset that is secured by your personal home location.
Having trusts at the OS level can create a technical single signon. Those trust can introduce some vulenerablity that is unacceptable by business policies.

[Ivy]

Thank you very much for the knowledge shared, 

Ivy