On 11/6/07, Inventor <[EMAIL PROTECTED]> wrote:
> I would like to code up a test game in which the user must write a
> simple set of nested for loops that try every password code against a
> perl guardian script until they get the right password. To accomplish
> this, I need one perl script that acts like the computer being
> accessed and another that acts like the attacker spy script.
> 1. How can I establish the process-to-process communication with
> perl?
Have you seen the perlipc manpage?
perldoc perlipc
> 2. How do I do that encrypted password thingie where the perl script
> stores the password as an encrypted text string?
Are you looking for the crypt() function?
perldoc -f crypt
I'd probably write the "guardian" program so that it takes the
"password" as a command-line argument, answering simply "good
password" for the correct one or "bad password" for anything else.
That means that the caller can use simple code like this to check a
password:
my $success = (`/path/to/guardian $password` =~ /good/);
There's more than a little overhead for calling a program in
backticks. That may be what you want, since you want this to take the
user some time. But it would be faster to have the user call crypt()
directly. A tech-savvy player who can find the encrypted password will
be able to test passwords significantly faster than other players by
skipping the guardian.
If you're using crypt() to validate the password, you should give the
poor user something of a hint; it is intended to take quite a while to
brute-force a password without any hint at all. For example, your hint
could say that the password is six characters long, including four
capital letters and two digits, so any program that tries passwords
like PEANUT or 142857 is wasting its time. That still leaves lots of
passwords like 42FRED or FRED42 or FR4E2D to try, but only millions of
them, not trillions.
Since it's a game, you may want your guardian program to count the
number of times it's called. If a player has called it many too many
times, maybe the game should offer a more generous hint, because
without a hint the player is probably not having fun any more.
Hope this helps!
--Tom Phoenix
Stonehenge Perl Training
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
http://learn.perl.org/
