Others have commented on the problems with your approach and the way you have coded it. But I gather that your main concern is to make sure that each new person is guaranteed to get a unique password, and you're worried that your current code might not accomplish that.

You are using an SQL-ish database to store names and passwords, so it should be the case that you can (and should) apply a "UNIQUE" constraint on both the name and the password fields -- this way, it you try to insert a row that uses a value already present in the table, the database will reject it, and the insert statement will fail.

This would also mean that you need to work out how to check and handle the return status of the statement execution. Sometimes, the default behavior with DBI is to "die" when something goes wrong, but the way to alter and control this is explained in the DBI man page. (Yes, that man page is long and complicated, but if you're going to use DBI, you need to need to read the man page.)

Of course, you could also take the time to check for the existence of a given user name in the database before you try to insert it -- e.g. (using the table and column names that you seem to have in your database):

my $sql = "select login from login where login like ?";
# (I would have used different names for table and column)

my $sth = $dbh->prepare( $sql );

my $newname = "whatever";

$sth->execute( $newname.'%' );
my $likenames = $sth->fetchall_arrayref;

# update: remembered that fetchall_arrayref returns AoA,
# so added map to get actual field values into grep
# (also remembered to include the "execute" step above)

if ( grep /^\Q$newname\E$/, map { $$_[0] } @$likenames ) {
    $newname .= "00";
    while ( grep /^\Q$newname\E$/, map { $$_[0] } @$likenames ) {
        $newname++;
    }
}
[download]

After you generate some password string (preferably using the CPAN module suggested above), you can use this sort of logic to check that it's unique and tweak it if necessary.