umailedit (3/18/2013)
Not sure I agree. Plenty of people recommend using one-way hashes for passwords: http://stackoverflow.com/questions/2549988/whats-the-recommended-hashing-algorithm-to-use-for-stored-passwords
One way hashing can be done using encryption algorithms instead of hashing algorithms. You can try more than a million different passwords per second with sha1 and sha2. Not so many with one way two fish encryption with a 100 rounds.
Not so many with SHA-1 or one of the SHA-2 family with 100 rounds, either. You're not arguing for encryption vs. hashing, you're arguing for enough rounds to take more time vs. not enough rounds (say, 1).
As far as recommendations for hashing,
http://csrc.nist.gov/publications/drafts/800-118/draft-sp800-118.pdf, Guide to Enterprise Password
Management (Draft) states
"Passwords should not be stored without additional security controls to protect them. Examples of such security controls include:
...
Storing one-way cryptographic hashes for passwords instead of storing the passwords themselves.
...
Federal agencies must protect passwords using FIPS-approved cryptographic algorithm implementations.
...
Many
authentication systems support the protection of passwords only with cryptographic algorithms and implementations that are either no longer FIPS-approved (e.g., DES) or were never FIPS-approved (e.g., MD4, MD5, RC2, RC4). In such situations, agencies must use compensating controls to protect the passwords using FIPS-approved cryptographic means.
"
Which indicates that for some U.S. based uses, Twofish is right out. Using SHA-1 or SHA-2 with a sufficient number of rounds (using the PBKDF2 algorithm) would thus be a reasonable choice. Other countries and industries have other standards.