Quote from: eleuthria on June 20, 2011, 02:15:01 AM

Stats are now fixed for some people that had problems. I re-sync'd the worker database after UK was taken down and NL2 was put up. Some workers were set to hidden and later un-hidden on the main server. This change did not filter into the slave servers so the stats were not being sent to My Account/API.

Regarding our password security:
All user submitted data to BTC Guild is run through prepared queries to prevent SQL Injection attacks. Nobody will be feeding bad data into a form, API query, or general page with GET/POST data that will be able to pull down our database information or modify it.

User passwords are stored using a hash of the original password, and salted with various miscellaneous user data information, system variables at the time of launch, AND a salt string stored on the server that is inaccessible via an HTTP request or SQL. The only way to obtain ALL of the salt information used on a password would be ALL of the following:
1) Getting the full user database pulled down AND
2) Getting the full code used to prepare a salt for the password AND
3) Accessing the shell to obtain the local system file which contains additional salt data

The shell is IP Blocking SSH and SQL connections from any IP address that is not mine, adding yet another hurdle an attacker would have to somehow bypass to obtain before they could begin attempting to reverse engineer passwords from the stored hashes.

With all the layers it is almost irrelevant, but is the hash MD5 or something considered secure? MD5 has been deemed inferior for quite awhile now. It sounds like you use some unique way to make the salt and key very difficult to determine, and that implies encryption and not a one way hash like MD5 or SHA1. So, I am afraid that I did not quite follow what was hashed and stored in the database. Clearly running a lot of crypto and getting a hash of the result for every login would be expensive, do that is why I ask.