Date: Thu, 21 Nov 2002 14:45:25 -0500
Reply-To: Ed Heaton <EdHeaton@WESTAT.COM>
Sender: "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From: Ed Heaton <EdHeaton@WESTAT.COM>
Subject: Re: Is there a way to hide the userid & password in PROC SQL scri
Of course you are correct. I know of no method to insure security.
The best we can hope for is to ward off those who are inexperienced
or who don't have the time to hack the system.
Agreed, this is a easy system to hack. However, if I am delivering
a hardcopy of the SAS log and I do not want it to show the password
and username, this should be sufficient.
At a previous job I once had, using something other than SAS (I do
not even remember what I was using.) I requested ######## for the
password in hopes that someone who saw it in the log would think
that the system blotted-out the real password.
Oops! I hope I didn't give away anyone's secret.
Edward Heaton, Senior Systems Analyst,
Westat (An Employee-Owned Research Corporation),
1550 Research Boulevard, Room 2018, Rockville, MD 20850-3195
Voice: (301) 610-4818 Fax: (301) 294-3992
From: Shane Hornibrook [mailto:email@example.com]
Sent: Thursday, November 21, 2002 2:39 PM
To: Ed Heaton
Subject: RE: Is there a way to hide the userid & password in PROC SQL
You have a good point about returning the options to the same state as
they were at the beginning of the macro, however; Maybe my point was lost.
>Embedding the turn-off switch in the macro is effective,
Actually it isn't effective as a real security measure AFAICT;
Embedding the turn-off switch in the macro does nothing for security of
the macro code. The user can redefine how any word in the macro
is interpreted. If the macro writer uses nomprint or nomlogic within
their macro, these 'security' measures are easily circumvented by
redefining the word 'nomprint' to be interpreted as 'mprint' with a
statement such as;
MACRO nomprint mprint;
**** this line causes sas to read NOMPRINT as mprint;
*** you can even redefine DATA as PROC, PROC as DATA, etc.... great
potential for obfuscating code, if you chose to do so.
Perhaps a better solution is in creating a macro variable with the value
of NOMPRINT, and checking the length or a hash of the variable for a
change (to MPRINT) and ERRORABENDing if it does not checksum to the
predefined sum. Thus if someone changes the value of nomprint for the
purposes of revealing your macro code, they also cause an errorabend.
Depending on how security minded you are, you could work in an automatic
email subroutine if someone tries an mprint/mlogic/etc.
On Thu, 21 Nov 2002, Ed Heaton wrote:
>Embedding the turn-off switch in the macro is effective, but macros
>should return these kind of things the way they found them. How
> %local mPrint ;
> %let mPrint = %sysFunc( getOption(mPrint) ) ;
> options nomprint ;
> data foo;
> x = 1;
> Options &mPrint ;
>Edward Heaton, Senior Systems Analyst,
>Westat (An Employee-Owned Research Corporation),
>1550 Research Boulevard, Room 2018, Rockville, MD 20850-3195
>Voice: (301) 610-4818 Fax: (301) 294-3992
>From: Shane Hornibrook [mailto:shornibr@IS.DAL.CA]
>Sent: Thursday, November 21, 2002 10:48 AM
>Subject: Re: Is there a way to hide the userid & password in PROC SQL
>Using nomlogic and nomprint only works until a user redefines nomprint and
>nomlogic (via old-style macros) example below;
>/* some macro */
> x = 1;
>/* user runs it and sees no code in the log, thanks to the options
>nomprint embedded in the macro */
>/** user can try to mprint, but it does not work **/
>/** now use the old style macro to redefine mprint **/
>macro nomprint mprint;
>/* now the user can see the macro ... */
>This works with any macro option shorter than 8 characters (eg mprint,
>mlogic, not symbolgen).
>On Thu, 21 Nov 2002, [iso-8859-1] Suzanne D. McCoy wrote:
>>Use macro variables and turn off mprint, mlogic and symbolgen.
>>> This is for a friend. She doesn't want the users of her code to see the
>>> username and password
>>> Her program:
>>> proc sql;
>>> connect to oracle(user='XXXXX' pass="YYYYY"