I'd like to share our answer to an interesting question regarding SHA-1 and the authentication scheme implemented by Dwolla's Off-Site Gateway Submit Directly flow:
"I'm looking at the developer stuff on checkout workflow, and see that the "signature" being transmitted between Dwolla and a business website is specified to use the SHA1 hash system. It is my understanding that that method is becoming vulnerable to an attack that has adequate computing power behind it. So, what other hash methods are allowable, for a business interacting with Dwolla? Thanks in advance!"
Though there are some weaknesses with SHA-1, they relate only to hash collisions. This means the weaknesses aren't helpful to attackers who are trying to determine the underlying input(s) of the hash. The only way to obtain the input(s) is by brute force.
In our case, the input of the signature hash is a concatenation of the Application Key, timestamp, and OrderID. These are all provided in the checkout form, so the attacker knows what the input is. What the attacker doesn't have is the Application Secret, which is a 50 character string used as the key in this key-based hash.
In order to forge a signature, the attacker would need to obtain the App Secret by way of brute force. If we assume the search space per character is all alphanumeric characters and 3 symbols ("+", "/", and "="), that leaves us with 65 possible characters. Since the secret is 50 characters long, we can say that an attacker would need to make
or
attempts to exhaust all possibilities.
Let's say an attacker can hash 10 million candidates per second on a single CPU. To exhaust all possibilities, it would take roughly:
Even if he has a large farm of machines running, say 1000 machines, with a collective power of 10 billion hashes/sec, it'd still take roughly:
The sheer size of the Secret string renders brute force an infeasible way to obtain it. I would recommend reading Jeff Atwood's write up about hashes.
0 comments:
Post a Comment