To thwart this type of brute force search, we do not use a simple one-step hash. Instead, our new system stores the a hash of the password using a large number of cycles of a very computationally expensive hash, made more secure with a large 256 bit random salt. To get a sense of how long a 256 bit salt is, an example would be bb5d3f9c0e396c3f8884f24ec43a16a31e6139e4e10d44512c261fc305df427f.
These security measures mean that an attacker must have a prohibitive amount of computing resources to "crack" any passwords that may be exposed if our database server, hosted by a third party, is compromised.
These security measures mean that an attacker must have a prohibitive amount of computing resources to "crack" any passwords that may be exposed if our database server, hosted by a third party, is compromised.
This looks like the right way to do it.
Hmmmm....I wonder what hashing algorithm they are using?
It looks like they might be using scrypt from their last commits. Or why else make this commit at this time? I hope it's a lot of rounds.
https://github.com/Grandpa-Jones/Synergy/commit/df02c93105bc03772e9af58f6b80f6886cfb61e5#diff-31dd861cd0a6a9747cbc540ac1e3bf72R362
Code:
Value scrypthash(const Array& params, bool fHelp)
{
if (fHelp || params.size() < 3 || params.size() > 4)
throw runtime_error(
"scrypthash [force=false]\n"
"The and arguments are strings, is an integer.\n"
"If [force] is false, then bigger than 1024 trigger an error.\n"
"Returns hex of the hash sha256(scrypt(sha256(message, salt))).");
{
if (fHelp || params.size() < 3 || params.size() > 4)
throw runtime_error(
"scrypthash [force=false]\n"
"The and arguments are strings, is an integer.\n"
"If [force] is false, then bigger than 1024 trigger an error.\n"
"Returns hex of the hash sha256(scrypt(sha256(message, salt))).");
It is, of course, irrelevant that you or anyone has "discovered" the hashing algorithm we use. The security doesn't depend on an attacker's not knowing the hashing algorithm. It's good to keep as much secret as possible, but real security does not rely on keeping algorithms (or even the salt) secret. It's how you use them that matters.
The original implementation of the hashing algo we use was pure C# and was too slow. To make it faster, I used the C++ scrypt implementation already in the wallet code base and made an RPC call from it. We could have re-wrote the C# implementation to make it as fast as the C++ implementation, but there was no need. We have to have a wallet running anyway to do things like burn coins.