Re: ??Mnemonic Passwords??

[tachyon]

I suggest you read my rather comprehensive answer to your coding problems with this script posted at Re: To register or not (2)!!! which shows you how to do this as well as fixing a number of other issues with your script.

You have to be joking about using ROT13 encryption right? - that cipher was broken when Ceasar was king. If you want to store passwords you don't need a crappy weak pointless cipher like that. Just do this:

my $password = password(5);
my $salt = 'Na';   # any two char string will do
my $encrypted = crypt( $password, $salt );
print "The encrypted version of $password is $encrypted\n";

print 'Gimmee the password: ';
chomp( my $answer = <> );
print check_password($answer) ? "OK" : "Wrong";

sub check_password {
    my $to_check = shift;
    # I would normally use return COND ? TRUE : FALSE;
    # like this
    # return (crypt( $to_check, $salt ) eq $encrypted) ? 1 : 0;
    # but here it is in baby perl
    if ( crypt( $to_check, $salt ) eq $encrypted ) {
      return 1
    } else {
      return 0
    }
}

sub password{
    my $s = shift;
    srand( $s ^ time ^ $$ );
    @c = split //, "bcdfghjklmnpqrstvwxyz";
    @v = split //, "aeiou";
    my $password = '';
    $password .= $c[int(rand(21))] .$v[int(rand(5))] for 1..4;
  return $password;
}

crypt is a one way hashing algorithm so to check a password you encrypt it and see it it matches the encrypted password. You only store the encrypted password. You can't decrypt one way hashes - thus they are generally more secure than ciphers as the only real way to attack them is a brute force dicttionary attack where you encrypt words and see if they match the hashed value.

cheers

tachyon

s&&rsenoyhcatreve&&&s&n.+t&"$'$`$\"$\&"&ee&&y&srve&&d&&print

[Trimbach]

crypt and other one-way hashing algorithms are not appropriate for every application. Ever try to maintain thousands of user accounts where everyone's password is crypt'ed? It's no fun when you have no way of reminding them what their password is when they forget. Storing passwords in the clear may not be the most secure thing in the world, but if the application isn't critical the convenience may FAR outweigh the lack of security. Both Slashdot and Perlmonks store their password lists un-crypt'ed for that very reason, so that they can email it to people who forget.

The original poster's ROT13 encryption might not be secure, but it's at least reversable, which gives you (slightly) more security than storing plaintext passwords. Sure, he's putting up a chain-link fence instead of a guard tower, but there's a reason why people still use chain-link fences. :-)

Gary Blackburn
Trained Killer

[tachyon]

Given that you can have an industrial strength fence for essentially the same price as a decorative ROT13 one why not just:

use Crypt::Blowfish;
use Crypt::CBC;

$KEY = 'GNUisnotUnix';  # Blowfish will take 56 bytes (448 bits) of ke
+y
my $cipher = new Crypt::CBC( $KEY, 'Blowfish' );

my $enc = encrypt('Hello World');
my $dec = decrypt($enc);
print "$enc\n$dec\n";

sub decrypt { defined $_[0] ? $cipher->decrypt_hex($_[0]) : '' }
sub encrypt { defined $_[0] ? $cipher->encrypt_hex($_[0]) : '' }

cheers

tachyon

s&&rsenoyhcatreve&&&s&n.+t&"$'$`$\"$\&"&ee&&y&srve&&d&&print

[Trimbach]

Well, yeah, there's lots of two-way ciphers available, which would allow you to protect the stored passwords. But even so it's overkill for lots of applications. It will keep Evil Doers from compromising your passwords if they have access to your filesystem, but if they have access to your filesystem you have bigger problems anyway. I personally don't bother encrypting passwords unless money is involved, but, as always, TMTWTDI. :-)

Gary Blackburn
Trained Killer

[jdporter]

In addition to everything else tachyon (and others) have said, I'm going to repeat something I've already mentioned twice and which has gone ignored --
The arguments to rand() should not be hard-coded "magic" numbers, but should be the lengths of the arrays themselves.
It is also worth noting that the int() calls are superfluous, because array indices are automatically int-ified. So:

$c[ rand @c ] , $v[ rand @v ]

jdporter
The 6th Rule of Perl Club is -- There is no Rule #6.

[poj]

# map returns a list so although
print password(5); # result abcdefgh
$p = password(5); print $p ; # result 8

# one fix is to use
return join '',map { $c[ rand @c ], $v[ rand @v ] } 1..4;


poj

[eoin]

JD, when i applied your teqnique for my password generation

sub password
  {
    my( $s ) = @_;
    srand( $s ^ time );
    my @c = split / */, "bcdfghjklmnpqrstvwxyz";
    my @v = split / */, "aeiou";
    return map { $c[ rand @c ], $v[ rand @v ] } 1..4;
  }

It returned the length of the total array, which is 8.(4 two letter sylables). And that isn't what i wanted to do. I wasn't sure how to fix this because $me = newbie.

[jdporter]

I don't know what you're talking about, and I suspect you don't either.
The technique I showed worked perfectly for me.
I'd ask that you try it again.
Here's how I instrumented the code to prove myself right. (Note that the rp sub must come before, because of the prototype.)

  sub rp($$$)
  {
    my $array_name = shift;
    my $array_size = shift;
    my $val = shift;
    printf "$array_name: %d out of $array_size\n", $val;
    $val
  }

  sub password
  {
    my( $s ) = @_;
    srand( $s ^ time );
    my @c = split / */, "bcdfghjklmnpqrstvwxyz";
    my @v = split / */, "aeiou";
    return map { $c[ rp("c",@c,rand @c) ], $v[ rp('v',@v,rand @v) ] } 
+1..4;
  }

jdporter
The 6th Rule of Perl Club is -- There is no Rule #6.