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 <[EMAIL PROTECTED]> 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@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
_______________________________________________
Tutor maillist - Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor
