Modifying a SHA256 system to be ASIC resistant

Question

I am looking for a way to protect a system utilizing SHA256 on semi-weak passwords against brute force attacks using ASIC-levels of hash-power, ideally by designing a system that is ASIC resistant.

The following scenario is theoretical in nature, and is concluded as a question on how ASICs work at a hardware level.

Suppose I have a platform in which funds are protected by a 12 character password which is A-Z, a-z, 0-9

The hash used on the passwords is SHA256, and sufficient salt is used to prevent rainbow table attacks.

Suppose there are GPUs that can brute force SHA256 around 2000 MH/s and an attacker has an expensive stack of 100 of these GPUs. If the hash of a single password were leaked, it would take ~250 years on average for the attacker to find the password for the leaked hash.

Now, suppose ASICs start emerging for brute forcing SHA256 and can do so at around 100Th/s (similar to what we are seeing Bitcoin mining ASICs accomplish with Bitcoin's SHA256d), if one of these ASICs was then applied to my leaked salted hash, it would now take on average ~2 days to crack.

(Note: The main flaw here is that the passwords used by my platform are weak as they have to be 12 characters long, increasing the length would obviously solve this problem, but in my scenario the length must be 12 characters long)

I set out to devise a scheme that will be ASIC resistant, I propose we use a variable we will call 'sugar' which would be a bit of data added to the salted hash, which is then hashed again, e.g. SHA256(sugar+SHA256(salt+weakPassword)). The theory behind this is that, if an ASIC is built to brute force my platform, I can simply change the 'sugar' and now the entire ASIC is designed to brute force the old set up on a hardware level.

Would this work or am I misunderstanding how ASICs are built and it would be trivial for an ASIC to update the proposed 'sugar' variable?

Answer 1

A problem with SHA256 is that it's fast, which makes it possible to verify many possible passwords each second. A standard way to make a password hashing function slow is to perform many iterations of an underlying hash function. For example, PBKDF2 is more or less a loop of hash calculations. When performing 10,000 hash calculations for one password, cracking also becomes 10,000 times slower.

ASICs may be faster at computing hashes, but they differ from general computers in that they lack memory. Scrypt tries to take advantage of that, by requiring memory for the hash function. By requiring a couple of MB of memory, the hash is still easy to compute for computers, but it becomes harder and more expensive to implement that in ASICs.

Finally, I would recommend Argon2 as a password hash function. Another password hashing function such as bcrypt, scrypt or PBKDF2 are also fine. But hashing passwords with a single round of SHA256 is really not sufficient, especially if you are worried about attackers with custom hardware and unlimited budget.

I propose we use a variable we will call 'sugar' which would be a bit of data added to the salted hash

This is usually called a pepper, and I would say there is no consensus on whether using a pepper is a good idea from a security point of view.