[Tutor] passwords in scripts

[Ben Vinger]

Compiling is certainly helpful in my case, and I did
not realise how simple it was until you explained it. 
I estimate that most of our MCSEs will not know about
the strings command or attempt to look inside
something like test.pyc for a password.
As for users, I'll be amazed if they tried it.   And
real crackers - I think our network/firewall people
know what they are doing, so I assume crackers are
kept out.
So, yes, I will use this until I've done something
with crypt and/or expect.  
Finally, regarding changing the policy about telnet -
it looks to me like the network where I am (I'm very
new), is secure on the networking side however lax it
might be on the server side.  It is 100% switched,
which means that only by controlling a switch can
cleartext stuff be seen, and the switches are
well-protected (also physically).  So while I might
agree with everyone who mentioned it, I will leave the
Unix security to whoever in our large organisation's
concern it is.  I just want to avoid endangering it
myself.

Thanks
Ben

--- Danny Yoo <dyoo at hkn.eecs.berkeley.edu> wrote:

> 
> 
> On Tue, 24 Jan 2006, Ivan Furone wrote:
> 
> > I'm not sure I understand what you are saying
> here. Surely if the file
> > is compiled it can just run (and will only need to
> be RE-compiled when I
> > have to change the code (such as when one of the
> servers has their
> > password changed).
> 
> Hi Ivan,
> 
> But the issue is that hardcoding passwords in a
> program doesn't really
> protect that password from exposure.  For example:
> 
> ######
> bash-3.00$ cat test.py
> message = "hello, this is a test"
> bash-3.00$ python
> Python 2.3.3 (#1, Nov  7 2005, 22:36:37) [C] on
> sunos5
> Type "help", "copyright", "credits" or "license" for
> more information.
> >>> import test
> >>> ^D
> #######
> 
> 
> Doing the import will cause test.py to be compiled
> to 'test.pyc':
> 
> ######
> bash-3.00$ ls -l test.pyc
> -rw-r--r--   1 dyoo     other        143 Jan 24
> 10:55 test.pyc
> ######
> 
> 
> But watch what happens here:
> 
> ######
> bash-3.00$ strings test.pyc
> hello, this is a testN(
> message(
> message(
> test.pys
> ######
> 
> Our secret string shows right up!
> 
> 
> 
> This works even if we're talking about C code:
> 
> /******/
> bash-3.00$ cat test.c
> #include <stdio.h>
> int main(int argc, char** argv) {
>   char *msg = "hello";
> }
> bash-3.00$ gcc test.c
> bash-3.00$ strings a.out
> hello
> /******/
> 
> 
> So the fact that we're "compiling" code doesn't do
> anything significant to
> add security: those string literals are ripe for the
> taking for anyone
> competent enough to use the 'strings' command.  So
> that's what we're
> trying to warn you about.  Compiling code is not a
> magic wand to obscure
> secrets.
> 
> 
> Hope this helps!
> 
> _______________________________________________
> Tutor maillist  -  Tutor at python.org
> http://mail.python.org/mailman/listinfo/tutor
> 



	
	
		
___________________________________________________________ 
Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com