Recommended hash for passwords in ASP Classic

问题:

What is the slowest (therefore best) hash algorithm for passwords in ASP Classic?

EDIT: For those unaware, when hashing passwords, slower hashes are preferred to faster to help slow rainbow table style attacks.

EDIT2: And yes, of course speed isn't the only valid concern for hash selection. My question assumes that All other things being equal, the slowest hash method is preferred when hashing a password. Though collision/reverse engineering is of course a concern too, I'm prioritizing speed in this question since it is arguably the most critical factor to consider when comparing popular hash algorithms for use on passwords.

Thanks!

回答1:

A lot of people seem to be beating on the question-asker because he's looking for a slow hash function. Actually, all other aspects being equal, a slower hash function is more secure than a fast one. This is because a slower hash function results in slower generation of rainbow tables and slower brute forcing or dictionary attacks on the password.

From Thomas Ptacek at http://www.securityfocus.com/blogs/262, as referenced in this Coding Horror article:

The problem is that MD5 is fast. So are its modern competitors, like SHA1 and SHA256. Speed is a design goal of a modern secure hash, because hashes are a building block of almost every cryptosystem, and usually get demand-executed on a per-packet or per-message basis.

Speed is exactly what you don’t want in a password hash function.

Modern password schemes are attacked with incremental password crackers.

Incremental crackers don’t precalculate all possible cracked passwords. They consider each password hash individually, and they feed their dictionary through the password hash function the same way your PHP login page would. Rainbow table crackers like Ophcrack use space to attack passwords; incremental crackers like John the Ripper, Crack, and LC5 work with time: statistics and compute.

The password attack game is scored in time taken to crack password X. With rainbow tables, that time depends on how big your table needs to be and how fast you can search it. With incremental crackers, the time depends on how fast you can make the password hash function run.

The better you can optimize your password hash function, the faster your password hash function gets, the weaker your scheme is. MD5 and SHA1, even conventional block ciphers like DES, are designed to be fast. MD5, SHA1, and DES are weak password hashes. On modern CPUs, raw crypto building blocks like DES and MD5 can be bitsliced, vectorized, and parallelized to make password searches lightning fast. Game-over FPGA implementations cost only hundreds of dollars.

Some comments on the PHP MD5 documentation also discuss preference for slowness.

To answer your question, it looks like BCrypt is the way to go. However, I have not been able to find any implementations for ASP Classic. If that's true, I would stick with a regular hash function like SHA512.

回答2:

I'll ignore the slow part, and instead go for the "good" part.

I suggest you use SHA-512 with a salt to defeat dictionary and rainbow table attacks. I don't believe there are any known vulnerabilities for SHA-512.

回答3:

If you are trying to defeat brute force attacks you are better off enforcing some failed attempts window/count rather than relying on the speed of the hashing (or hash comparison) mechanism to make the attack take longer to succeed. Lock out the account after a certain number of failed attempts within the failure window and only let new attempts be made after a significant amount of time has elapsed.

This could leave you open to a DOS attack against a well-known (administrative) account, but you could exempt certain accounts from the lockout policy or have an alternate way -- using a security question/answer -- to logon to a locked out account before the reset period has elapsed.

[EDIT] To help defeat rainbow attacks -- where the attacker has retrieved your hashed passwords and finds suitable matches that hash to the same values -- consider both using a random salt unique to each user's hashed password and a fixed salt that is part of the algorithm, not the data. For example:

  testHash = computeHash( user.salt + "98hloj5674" + password );
  if (testHash == user.hashedPassword)
  {
      valid = true;
  }

This should invalidate the rainbow tables since, even knowing the user's salt and the hash algorithm, the values in the attacker's rainbow tables won't map onto your hashed passwords because of the addition of the fixed salt in the algorithm.

With ASP Classic, you'd have to do this in a library instead of on the page to make sure that the user couldn't see your fixed salt.

回答4:

Dim sPassword, sSalt
sPassword = "Lorem"
sSalt = "Ipsum"
With CreateObject("CAPICOM.HashedData")
  .Algorithm = 0 ' CAPICOM_HASH_ALGORITHM_SHA1
  .Hash sPassword & sSalt
  Response.Write "Here is your hash: " & .Value
End With

Capicom documentation

Algorithm is any of the following:

CAPICOM_HASH_ALGORITHM_SHA1      = 0
CAPICOM_HASH_ALGORITHM_MD2       = 1
CAPICOM_HASH_ALGORITHM_MD4       = 2
CAPICOM_HASH_ALGORITHM_MD5       = 3
CAPICOM_HASH_ALGORITHM_SHA_256   = 4 - Not supported on Windows XP or 2000
CAPICOM_HASH_ALGORITHM_SHA_384   = 5 - Not supported on Windows XP or 2000
CAPICOM_HASH_ALGORITHM_SHA_512   = 6 - Not supported on Windows XP or 2000

回答5:

Actually, the best hash function is the one that generates no colisions and is not suspectible to rainbow-table attacks.

That means: Add a Salt (preferably a different Salt for every user), and think of using a SHA2 Hash function (or maybe RIPE-MD, I have not looked at that much):

One implementation of SHA-256 is here (i love how they call it "one-way encryption"):
http://www.freevbcode.com/ShowCode.Asp?ID=2565

Have not tested it though, but there are certainly SHA2 implementations for Classic ASP.

回答6:

I personally prefer the Whirlpool algorithm for all of my hashing needs. It produces a 512 bit output and thus has equal space requirements to SHA-512. Regretfully, I cannot speak authoritatively as to whether one is more secure than the other, but there do not appear to be any flagrant weaknesses in this the third version of Whirlpool.

The reference implementations are in the public domain, which is good because I rarely find this implemented by default in various tools and languages.

(If anyone knows of a good reason why SHA should be favored over Whirlpool, please let me know.)

回答7:

psuedocode for the slowest method:

function hashPassword(password)
    sleep for 10 seconds
    return password
end function

This certainly isn't the most secure (or at all) but it's slow...

(I'm just pointing out that making it slower is not the answer...)