view release on metacpan or  search on metacpan

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

B<THIS MODULE IS DEPRECATED>. For a module that's more extensible, and
less held-back by legacy algorithms, you may want to use
L<Crypt::Passphrase|Crypt::Passphrase> instead.

This is the base class for a system of objects that encapsulate
passphrases.  An object of this type is a passphrase recogniser: its
job is to recognise whether an offered passphrase is the right one.
For security, such passphrase recognisers usually do not themselves know
the passphrase they are looking for; they can merely recognise it when
they see it.  There are many schemes in use to achieve this effect,
and the intent of this class is to provide a consistent interface to
them all, hiding the details.

The CPAN package Authen-Passphrase contains implementations of several
specific passphrase schemes in addition to the base class.  See the
specific classes for notes on the security properties of each scheme.
In new systems, if there is a choice of which passphrase algorithm to
use, it is recommended to use L<Authen::Passphrase::SaltedDigest> or
L<Authen::Passphrase::BlowfishCrypt>.  Most other schemes are too weak
for new applications, and should be used only for backward compatibility.

=head2 Side-channel cryptanalysis

Both the Authen-Passphrase framework and most of the underlying
cryptographic algorithm implementations are vulnerable to side-channel
cryptanalytic attacks.  However, the impact of this is quite limited.

Unlike the case of symmetric encryption, where a side-channel attack can
extract the plaintext directly, the cryptographic operations involved in
passphrase recognition don't directly process the correct passphrase.
A sophisticated side-channel attack, applied when offering incorrect
passphrases for checking, could potentially extract salt (from the
operation of the hashing algorithm) and the target hash value (from
the comparison of hash values).  This would enable a cryptanalytic or
brute-force attack on the passphrase recogniser to be performed offline.
This is not a disaster; the very intent of storing only a hash of
the correct passphrase is that leakage of these stored values doesn't
compromise the passphrase.

In a typical usage scenario for this framework, the side-channel attacks
that can be mounted are very restricted.  If authenticating network
users, typically an attacker has no access at all to power consumption,
electromagnetic emanation, and other such side channels.  The only
side channel that is readily available is timing, and the precision of
timing measurements is significantly blunted by the normal processes of
network communication.  For example, it would not normally be feasible
to mount a timing attack against hash value comparison (to see how far
through the values the first mismatch was).

Perl as a whole has not been built as a platform for
side-channel-resistant cryptography, so hardening Authen-Passphrase and
its underlying algorithms is not feasible.  In any serious use of Perl
for cryptography, including for authentication using Authen-Passphrase,
an analysis should be made of the exposure to side-channel attacks,
and if necessary efforts made to further blunt the timing channel.

One timing attack that is very obviously feasible over the network is to
determine which of several passphrase hashing algorithms is being used.
This can potentially distinguish between classes of user accounts,
or distinguish between existing and non-existing user accounts when an
attacker is guessing usernames.  To obscure this information requires
an extreme restriction of the timing channel, most likely by explicitly
pausing to standardise the amount of time spent on authentication.
This defence also rules out essentially all other timing attacks.

=head1 PASSPHRASE ENCODINGS

Because hashed passphrases frequently need to be stored, various encodings
of them have been devised.  This class has constructors and methods to
support these.

=head2 crypt encoding

The Unix crypt() function, which performs passphrase hashing, returns
hashes in a textual format intended to be stored in a text file.
In particular, such hashes are stored in /etc/passwd (and now /etc/shadow)
to control access to Unix user accounts.  The same textual format has
been adopted and extended by other passphrase-handling software such as
password crackers.

For historical reasons, there are several different syntaxes used in this
format.  The original DES-based password scheme represents its hashes
simply as a string of thirteen base 64 digits.  An extended variant of
this scheme uses nineteen base 64 digits, preceded by an "B<_>" marker.
A more general syntax was developed later, which starts the string with
"B<$>", an alphanumeric scheme identifier, and another "B<$>".

In addition to actual passphrase hashes, the crypt format can also
represent a couple of special cases.  The empty string indicates that
there is no access control; it is possible to login without giving a
passphrase.  Finally, any string that is not a possible output of crypt()
may be used to prevent login completely; "B<*>" is the usual choice,
but other strings are used too.

crypt strings are intended to be used in text files that use colon and
newline characters as delimiters.  This module treats the crypt string
syntax as being limited to ASCII graphic characters excluding colon.

=head2 RFC 2307 encoding

RFC 2307 describes an encoding system for passphrase hashes, to be used
in the "B<userPassword>" attribute in LDAP databases.  It encodes hashes
as ASCII text, and supports several passphrase schemes in an extensible
way by starting the encoding with an alphanumeric scheme identifier
enclosed in braces.  There are several standard scheme identifiers.
The "B<{CRYPT}>" scheme allows the use of any crypt encoding.

This module treats the RFC 2307 string syntax as being limited to ASCII
graphic characters.

The RFC 2307 encoding is a good one, and is recommended for storage and
exchange of passphrase hashes.

=cut

package Authen::Passphrase;

{ use 5.006; }
use warnings;
use strict;