http://qs321.pair.com?node_id=524637


in reply to how to crypt and decrypt password from 4 to 15 characters in length

Depending on your application, it may be better (more secure) to store the password in a way that it cannot be decrypted at all: Using a one-way hash function (such as MD5 or SHA1) you can still check if a given entry matches the correct password (because it will hash to the same "crypted" version), but since the hash-function cannot be reversed, you do not have to worry much about it being compromised at the storage level (*).

Of course, this also makes it impossible for the administrator to recover a forgotten user password. All he can do is reset it to a new one.

If that drawback (which can also be seen as a feature) is not a problem in your case, you should consider going with a hash function rather than a cypher. If you do want to implement a local keystore (such as what a browser uses for site passwords) then please go with one of the various Crypt::* suggestions.

Update: (*) While the hash value cannot really be decrypted, it is possible to brute-force crack it by trying all possible passwords for a match, which works quite well for poor (short/simple) passwords. This is why we have shadow password files these days (as opposed to storing the hashed password in /etc/passwd where everyone can take a shot at the guessing game).

  • Comment on Re: how to crypt and decrypt password from 4 to 15 characters in length

Replies are listed 'Best First'.
Re^2: how to crypt and decrypt password from 4 to 15 characters in length
by tirwhan (Abbot) on Jan 21, 2006 at 07:42 UTC

    Using a hash function for passwords is a good suggestion, ++. However, there are known attacks for MD5 and SHA-1. While these attacks are not yet considered serious enough to recommend switching applications away from these hashing methods, better algorithms exist and should be used for new apps (this is particularly true for MD5). Both Digest::SHA and Digest::SHA::Perl can use SHA-256, which is stronger, so you should use it instead.


    There are ten types of people: those that understand binary and those that don't.
[reply]
[d/l]
      Note that recent advances against hashing affect _collision resistance_, i.e., make it feasible to generate identical hashes from different inputs. These kinds of weaknesses don't directly influence the security of password one-wayness. (They don't let one create a password with the same hash as any particular other one.)
[reply]

        True, which is why I said there is no need to migrate existing applications at this point. However, the existence of collision attacks makes it more likely that preimage attacks (which would allow to generate an input that will produce a given existing hash) will be found. More secure algorithms exist and are not prohibitively computationally expensive, no reason not to use them.


        There are ten types of people: those that understand binary and those that don't.
[reply]
[d/l]

In Section Seekers of Perl Wisdom