Crypt-Passphrase

 view release on metacpan or  search on metacpan

lib/Crypt/Passphrase.pm  view on Meta::CPAN

 my ($hash) = $dbh->selectrow_array("SELECT password_hash FROM users WHERE name = ?", {}, $user);
 if (!$authenticator->verify_password($password, $hash)) {
     die "Invalid password";
 }
 elsif ($authenticator->needs_rehash($hash)) {
     my $new_hash = $authenticator->hash_password($password);
     $dbh->do("UPDATE users SET password_hash = ? WHERE name = ?", {}, $new_hash, $user);
 }

=head1 DESCRIPTION

This module manages the passwords in a cryptographically agile manner. Following Postel's principle, it allows you to define a single scheme that will be used for new passwords, but several schemes to check passwords with. It will be able to tell you...

Note that this module doesn't depend on any backend, your application will have to depend on one or more of the backends listed under L</SEE ALSO>

=head1 METHODS

=head2 new

 Crypt::Passphrase->new(%args
     encoder    => 'Bcrypt',
     validators => [ 'SHA1::Hex' ],
 )

This creates a new C<Crypt::Passphrase> object. It takes three named arguments:

=over 4

=item * encoder

A C<Crypt::Passphrase> object has a single encoder. This can be passed in three different ways:

=over 4

=item * A simple string

The name of the encoder class. If the value starts with a C<+>, the C<+> will be removed and the remainder will be taken as a fully-qualified package name. Otherwise, C<Crypt::Passphrase::> will be prepended to the value.

The class will be loaded, and constructed without arguments.

=item * A hash

The C<module> entry will be used to load a new Crypt::Passphrase module as described above, the other arguments will be passed to the constructor. This is the recommended option, as it gives you full control over the password parameters.

=item * A Crypt::Passphrase::Encoder object

This will be used as-is.

=back

This argument is mandatory.

=item * validators

This is a list of additional validators for passwords. These values can each either be the same an encoder value, except that the last entry may also be a coderef that takes the password and the hash as its arguments and returns a boolean value.

This argument is optional and defaults to an empty list. The encoder is always considered as a validator and thus doesn't need to be specified.

=item * normalization

This sets the unicode normalization form used for the password. Valid values are C<'C'> (composed; the the default), C<'D'> (decomposed), C<'KC'> (legacy composed) and C<'KD'> (legacy decomposed). You should probably not change this unless it's neces...

=back

=head2 hash_password

 $passphrase->hash_password($password)

This will hash a C<$password> with the encoder cipher, and return it (in crypt format). This will generally use a salt, and as such will return a different value each time even when called with the same password.

=head2 verify_password

 $passphrase->verify_password($password, $hash)

This will check a C<$password> satisfies a certain C<$hash> and returns success or not. It will always return false if C<$hash> isn't defined.

=head2 needs_rehash

 $passphrase->needs_rehash($hash)

This will check if a hash needs to be rehashed, either because it's in the wrong cipher or because the parameters are insufficient.

Calling this only ever makes sense after a password has been verified.

=head2 recode_hash

 $passphrase->recode_hash($hash)

This recodes a hash if needed. This is mainly relevant when upgrading to a new pepper, but can also be relevant when a cipher has multiple known encodings (e.g. scrypt). It will return the hash unmodified otherwise.

=head2 curry_with_hash

 $passphrase->curry_with_hash($hash)

This creates a C<Crypt::Passphrase::PassphraseHash> object for the hash, effectively currying C<Crypt::Passphrase> with that hash. This can be useful for plugging C<Crypt::Passphrase> into some frameworks (e.g. ORMs) that require a singular object to...

=head1 TIPS AND TRICKS

=head2 Custom configurations

While encoders generally allow for a default configuration, I would strongly encourage anyone to research what settings work for your application. It is generally a trade-off between usability/resources and security.

If your application is deployed by different people than it's developed by it may be helpful to have the configuration for C<Crypt::Passphrase> part of your application configuration file and not be hardcoded so that your users can choose the right s...

=head2 Unicode

C<Crypt::Passphrase> considers passwords to be text, and as such you should ensure any password input is decoded if it contains any non-ascii characters. C<Crypt::Passphrase> will take care of both normalizing and encoding such input.

=head2 DOS attacks

Hashing passwords is by its nature a heavy operations. It can be abused by malignant actors who want to try to DOS your application. It may be wise to do some form of DOS protection such as a proof-of-work scheme or a captcha.

=head2 Levels of security

In some situations, it may be appropriate to have different password settings for different users (e.g. set them more strict for administrators than for ordinary users).

=head1 SEE ALSO

=head2 Encoders

The following encoders are currently available on CPAN:



( run in 0.753 second using v1.01-cache-2.11-cpan-df04353d9ac )