Topic: [~1000 GH/sec] BTC Guild - 0% Fee Pool, LP, SSL, Full Precision, and More - page 91. (Read 379078 times)

The weaknesses in MD5 are largely overhyped.  It is still just fine when used in a salted + iterated password hash system.  Even shitty old DES would be fine in this system, if not for the tiny keyspace.

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.

I wasn't.  Isn't that what I said?  I made a trade there (against my better judgement, but volume was so low on trade hill when I wanted to do this that I decide to use Mtgox.  I just remember the change left in my account (which I believe was a little over $7).  I didn't withdraw it since I didn't see the point of paying a fee of any kind when I was likely to cash in coins at some point and I would just withdraw it then.  So if it isn't obvious, I made a coin purchase our there would have been no "change".  I sold much of my mining proceeds when prices were in the $35+ range and with the recent correction I essentially "rebalanced" my bitcoin position (which was all based on mined coins anyway).  The trade and coin withdrawal was late on 6/17 CDT.  Care for any more details of my personal business?

My point is, if you are going to infer something, in this case that I logged in and checked my balance, then you better pay more care and attention.  Inferences are much more dangerous than implications, especially since you clearly did not entirely comprehend my post when I said my account is gone, because that is EXACTLY what I mean.

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.

You can't, all accounts have been disabled, and the site is down anyway.
There is a .csv file out online, with everyone's username, email, and hashed password (which I think is already broken) from Mt. Gox.

Go read some threads on the bitcoin discussion subforum.

It is all in the way it gets used.  MD5 is perfectly fine for passwords, when used properly.

eleuthria, please make sure you aren't doing anything strange when storing passwords.  Your best bet is to use the crypt() function built into PHP, and make sure you are generating a proper (random) salt string to force MD5, Blowfish or SHA.

How were you even able to login to check your account?  They have had logins unavailable at Mt.Gox for several hours now in an effort to restore accounts in what they are calling a "roll back".  I have been trying all day to login to my Mt.Gox account to check my balances.

MD5 I suppose? That hasn't been considered secure for a long time now.  SHA1 is what I think has become the defacto standard.

EDIT:  It seems that they blasted my account entirely!  I am sure they must have it "stored" somewhere.  Anyway, message sent.  Fortunately, I had a balance of less than $10USD and no bitcoins at all.  I think it may just stay that way forever [if I get the account restored properly, the balance will drop to $0.00].

Oh, my bad.  I didn't see the answer to that [and yes, that is obvious in hind sight and not to mention that the source of the DNS query is likely another DNS and not the mining software].  Sorry for the extra posts.  My idea about syncing by account is obviously stupid as well since it needs the IP address BEFORE it can send worker authentication.  Smack me upside the head with a stupid stick.

Fixed US Central's last share time.  It wasn't running ntpd to keep time's sync'd up regularly.

Last submitted share statistics arent correctly shown, at least for uscentral server (cant check for others).

EDIT:
Looks normal again.

So if you have not heard about the Mt. Gox incident you may want to take a look.
https://support.mtgox.com/entries/20208066-huge-bitcoin-sell-off-due-to-a-compromised-account-rollback

As a general practice it would be best to change any password(s) that you used that were the same as Mt. Gox. You might also want to check out this site and maybe utilize "password haystacking" to beef up your password security.

https://www.grc.com/haystack.htm

If you used the same (or similar) username and the same password on BTC Guild as you do on MtGox, change it immediately.  The leak at MtGox already has many people proving the hashed passwords in the database can be brute forced into their original plaintext.

eleuthria already posted the explanation:
Mining clients don't cache server IPs, so they're doing fresh DNS lookups for every getwork request, so it's possible that the server changes during a mining session. If the miner requests work from the UK server and then later submits the result to the NL server, things go wrong.

Right, but WHY couldn't it?  Was it because each pool server could handle different loads than others and the DNS round robin was very simple so that the weaker servers were getting overloaded?  Or was it because the DNS balancer itself couldn't handle it [that seems unlikely].  That is why I made a post within the last hour about load balancing.  Deepbit manages it pretty well [but doesn't suffer the limitations of push pool forcing restarts when server changes occur]. 

eleuthria, please put the serverload in some kind of API
I don't want to manually switch servers for my miners.

Or you somehow fix the balancing

He turned it off because it couldnt handle the connections.

Why did you shut DNS load balancing off?  Was it doing it purely on a connection basis [thus servers that were less capable than others were getting too much traffic]?  I think each server could have a service interface available to respond about the percentage of total capacity and that could be used for the DNS load balancing.  I have never been fond of DNS load balancing in general since a lot of software will believe there are no connections to a server that has actually gone down [but the machine is responsive] and start directing all traffic at it.  In your case though, I am not sure there is much of a better way.  Perhaps a dedicated service that does nothing but smartly resolve DNS queries and include worker/account information [to keep all workers for a given user pointed at the same pool server .. a bit of caching no doubt] and it does nothing else, it could be reactive to outages.  Maybe then, you make the IP address of all the servers private and if individuals have issues with being directed to a server that is giving them issues, they could have a UI option to "prefer" a specific server.  Granted, people can figure out the IP they are attaching too, but that is not much use if you do maintenance and change the address for whatever reason [which I suspect isn't that uncommon based on Deepbit].  That would give you the ability to remove a server from the balancer and then take it offline for maintenance or whatever and then bring it back up.  It would also allow the service to detect when a server has gone dark and direct traffic elsewhere [hopefully mining software will resolve the name again rather than use the resolved IP if it gets the infamous "RPC Server Not Responding"].   The only problem I see with such a setup is that your balancer would have to poll the servers with some frequency, probably not a big problem, but removing a server from the pool seems to require you to restart all the servers push pool services [i.e. a drawback of that software I think].

So, a question, with some ideas, and ... whatever you care to take or leave .  I never have worked on a system that is handling so many requests from multiple servers all over the world and trying to centralized the core pool work [like a massive cluster] in one location, although the hub and spoke scenario (server centric) is an old one in client server development and doesn't apply to your case.  Plenty of distributed computing for retail and health, but nothing with the number of connections you are taking [although the server resources per connection used with enterprise application servers are typically much larger than getworks ... RPC+LP ].

It was setup to do "round robin" load balancing [presumably passing out an address to the least loaded server ... not sure if it had any intelligence to know which servers could handle more load than others].  I remember the message about it pointing to central.  I haven't seen it on the site recently though, so I assumed it was back to doing what it should be.  Either way, Central has always been the best for me anyway.

Im guessing the 500 GHash increase...