Recommended Password Hash in ASP Classic

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

EDIT: For those who don’t know when hashes passwords, slower hashes are preferred faster to slow down rainbow style attacks.

EDIT2: And yes, of course, speed is not the only valid problem for choosing hashes. My question suggests that, ceteris paribus , the slowest hash method is preferable when hashing a password. Although the collision / reverse engineering problem is of course also a concern, I give priority to speed in this matter, as this is perhaps the most important factor to consider when comparing popular hashing algorithms for use in passwords.

Thanks!

+4
source share
7 answers

Many people seem to hit the interrogator because it is looking for a slow hash function. In fact, ceteris paribus, a slower hash function is safer than a fast one. This is due to the fact that a slower hash function leads to slow generation of rainbow tables and slow forced forced or verbal attacks on a password .

From Thomas Ptachek at http://www.securityfocus.com/blogs/262 , as stated in this Coding Horrible article :

The problem is that MD5 is fast. So are its modern competitors, such as SHA1 and SHA256 . Speed ​​is the design goal of a modern secure hash, since hashes are the building block of almost all cryptosystems, and it is usually a request for each packet or message.

Speed ​​is exactly what you don't want in the password hash function.

Modern password schemes are attacked with incremental password crackers.

Incremental crackers dont pre-calculate all possible crack passwords. They examine each password hash separately, and they dictionary through a password hash function just like your entry into the PHP page will be. Rainbow table crackers like Ophcrack use space to attack passwords; incremental crackers like John the Ripper, Crack and LC5 work over time: statistics and calculations.

A game with a password attack is estimated at the time taken to crack the X password. With rainbow tables, this time depends on how big your table should be and how fast you can look for it. With incremental crackers, the time depends on how quickly you can make a password hash function.

The better you can optimize your password hash functions, the faster your password hash function gets, the weaker your scheme. MD5 and SHA1, even regular block ciphers like DES, are designed to work quickly. MD5, SHA1, and DES are weak password hashes. On modern processors, raw crypto building blocks, such as DES and MD5, can be bit-wise, vectorized, and parallelized to find the password at lightning speed. FPGAs for game implementations cost only hundreds of dollars.

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

To answer your question, it seems like BCrypt is the way to go. However, I could not find any implementations for ASP Classic. If this is true, I would stick with a regular hash function like SHA512.

+12
source

I will ignore the slow part and instead go for the β€œgood” part.

I suggest you use SHA-512 with salt to defeat vocabulary and rainbow attacks. I do not believe that there are known vulnerabilities for SHA-512.

+5
source

If you are trying to defeat brute force attacks, you are better off not using some unsuccessful window / count attempts rather than relying on hashing speed (or hash comparison) to make the attack longer to succeed. Lock the account after a certain number of failed attempts in the crash window and allow new attempts after a considerable time.

This may leave you open to a DOS attack on a well-known (administrative) account, but you can release certain accounts from the lockout policy or have an alternative way - using a secret question / answer - to log in to the locked account before the expiration of the reset period.

[EDIT] To help defeat rainbow attacks - where the attacker extracted your hashed passwords and found matching matches with the same hash - consider using a random salt that is unique to each user, a hashed password, and a fixed salt, which is part of the algorithm, not data. For instance:

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

This should invalidate the rainbow tables, because even knowing the user's salt and the hashing algorithm, the values ​​in the attacker's rainbow tables will not be displayed on your hashed passwords due to the addition of a fixed salt to the algorithm.

With ASP Classic, you will need to do this in the library, not on the page, to make sure the user does not see your fixed salt.

+3
source
 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

An 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 
+2
source

In fact, the best hash function is a function that does not generate any collisions and is unaware of attacks with a rainbow table.

This means: add salt (preferably a different salt for each user) and think about using the SHA2 Hash function (or maybe RIPE-MD, I don't watch much):

One SHA-256 implementation here (I like what they call this one-way encryption):
http://www.freevbcode.com/ShowCode.Asp?ID=2565

We did not test it, but, of course, there are SHA2 versions for classic ASP.

0
source

I personally prefer the Whirlpool algorithm for all of my hashing needs. It produces 512-bit output and therefore has equal SHA-512 space requirements. Unfortunately, I cannot speak authoritatively about how much safer than the other, but there are no egregious flaws in this third version of Whirlpool.

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

(If anyone knows why the SHA should approve of Whirlpool, please let me know.)

0
source

psuedocode for the slowest method:

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

This, of course, is not the safest (or at all), but it is slow ...

(I just point out that doing it slower is not the answer ...)

-3
source

All Articles