Topic: [Pre Alpha] PHPCoin - page 2. (Read 11031 times)

These are easy things to fix.

Thanks for pointing them out.
I'll be sure my site get's updated with these fixes by tomorrow.

Ok, lets state some facts that i found:

1) Entire system is exploitable with XSS.
2) Entire system lacks CSRF protection.
3) Messy structure, mixed frontend/backend could lead to mistakes and issues.
4) Stupid not to filter _ALL_ inputs, not just the ones that does SQL-queries. (It's easier and safer)
6) Never ever trust ANYTHING a user enters. That includes amounts(!) and lengths of all inputs.
6.1) I've seen DDoS attacks with users entering huge amount of data to make the server do 50000 hashes on a string thats a couple of MBs.

For fuck sake, cannot SOMEONE learn to develop correctly structured PHP?
It's not _THAT_ hard. Implement a MVC structure or base the project on some open source frameword (CI, Symfony, Zend or whatever)
This will also take care of 90% of the security you guys are talking about.

CI have a neat implementation of prepared statments (that's really easy to use) and Symfony/Zend have similar ORM's.

Advices from someone that have actually developed PHP for the past.... many years.

of course just assuming that isn't security. It's what you do based on the assumption. It does not mean you neglect physical security of the systems, but to make getting hold of it not as profitable as it would otherwise be.



If somebody gets the db, doing a shutdown doesn't help. Depending on how he/she got access, they could very well steal your application code and load it up on their own server to do whatever.

Which is why the other consideration is to encrypt/protect other key information in the system and design it in such a way to maximize the cost and reduce the benefit to anybody who gains unauthorized access. The whole point of the game is to make the other person go "Screw it, this isn't worth the trouble!"

Ah, yes...my bad.

No, that line means:

If no account is selected, then select __

if you do this, and taken $account_id isn't set, will mean PC_1_

Attached to that "theoretical" exploit, would be good to have auto-forwarding on.
Also, thanks for pushing to github.


[Edit]: Just looked at the index.php and noticed something that could be changed.


Instead of _1, have it do _".$accout_id;

Just created a GitHub repo: https://github.com/BCEmporium/PHPCoin

@Xephan;
Fair enough, I'm not up to waste time in those sort of discussions. But to the end, if one gets your db, other than a dump:

mysql_query("UPDATE users SET `password` = '$mynewHash' WHERE uid = $target_id");

or, moving with money:

mysql_query("UPDATE users SET `balance` = 10000000 WHERE uid = $my_id");

Bottom line, "assuming that someone can get the database" isn't security. If someone gets the db is already too late... only solution probably: sudo /etc/init.d/mysql stop && shutdown -hP now

Sorry but cryptography defines broken very strictly. A hash function is considered broken if it is possible to generate a collision in less time than brute force. It might still be hard or difficult for the average person but since it's possible, it is defined as broken.  If it's possible to solve the hash function easily (by cryptographic standards) then it's considered completely broken.

For MD5, it has been demonstrated by researchers in 2004 how to create different files with the same md5 hash. In 2008, a successful attack was made on SSL and in 2009, an attack was published that is allegedly doable within minutes on a normal computer. MD5 is considered completely broken cryptographically.


You believed wrongly again. Let me put it into a timeline so it's clear what I was referring to

1. Original weak hash passwords with plain unsalted md5
2. mtgox realizes it's bad, changes hash to a slightly better but cryptographically just as weak BSD md5crypt
3. you signed up for an account or changed your password so your data in the database along with many others are using the salted md5crypt
4. hacker obtains database
5. easily cracks passwords from #1 and from released files, cracked the newer hashes from #2 too.

If #2 was a change to a more secured hash such as SHA256, then #4 would had only practically only affect the old/idle accounts from #1.
If mtgox did something between 2 and 4 to notify/force users to change their password, then the loss to #4 would had been further reduced, but only if a more secure hash was used.

I'll drop you a PM with my updates and you can choose whether or not to use them.

Sorry... damn! Changing OS is a pain 
Tried with VirtualBox to fire my Debian VM, but it was eating 100% CPU, means this was slower than a turtle with a broken leg. Then software; 1st try: Geany, now trying Aptana Studio. Coding the Admin block now.

Arg, I forgot to add the command for adding a new account in the bitcoind environment when making a new account.

So, what's your updates looking like?

The correct term is "Deprecated", not "Broken".

This is a wrong statement, MD5 wasn't ever broken nor is. The only way it would be considered as so if you or someone can actually reverse it and that, so far, is impossible.
Being open to Brutte-forcing doesn't make anything "broken" as no known algorithm is resistant to it. All you can make is it slower to bf, not prevent it.
MD5 is just "fastest to brutte-forced than others", along with those "rainbow tables" (which is just a database with pre-computed hashes, btw).

About that "old/new", it refers to: old -> Jed time / new -> some time after M'Tux bough that, not as "old before the attack/new after", as I believe you were assuming.

md5 was considered broken before GPU cracking became commonly available. So increase in hash speed due to GPU cracking is not an excuse for mtgox using a broken hash in the first place.



That's pretty much what I said so I'm not sure what you thought I said or maybe I am misunderstanding what you are saying now
To rephrase it, mtgox said only older accounts were still hashed with the plain md5 hashes. So newer accounts or those who changed their passwords after mtgox updated their code, would have the salted hash like yours. The db dump file contained both the older and newer hashes.

Actually you'd people starting to complaint out of accounts being ripped more than 2 weeks before the attack. And yes, cryptography on hashing, has improved A LOT since Bitcoin came around. The same methods to "mine more coins", as GPU mining, are the ones used now to reverse hashes. Whereas MD5 would sound safe under 1~2 Ghz CPU hashing, they're now "pieces of cake" for most GPU based crackers.

And that my pass wasn't of "they see THEN they changed", it was actually as it was in that db dump file.

They did mention that it was older accounts that were affected. i.e. they realized the security weakness and changed the hash algo/procedure before you sign up or last changed your password. That was one of the other mistakes, having discovered this weakness and implemented a better system, they failed to notify potentially vulnerable users to update their password to force a new hash. In some projects, once a breach appears probable, they notify and force everybody to change their passwords to be safe. An organisation dealing with money should be even more paranoid


Possible but based on available information, the somebody may only had the mtgox data for a few days prior to the scam. In any case, it is ALSO assumed that given sufficient time, any hash can be broken due to cryptographic advances or computational advances. Which is why there is the recommendation for users to change their passwords at least once every now and then. Once a year should be relatively safe since most hash algo are chosen to take at least years to break and an annual change is not particularly inconvenient for users as well.

Actually my account's password there was hashed with md5 salted crypt algorithm ($3$salt$hash)... which makes me believe also, someone had that db for quite a while. The added difficulty would represent one thing; the attack may not happen when it happened, but somewhere in the future... thus the attack would come to place either way.

Going to fire the VM now and will work on it a while.

It's really hard for me to sit around waiting for updates...
http://api.phpco.in/get/

I've added AJAX (auto-refresh) to the blockcount & connections ( when logged in @ https://www.phpco.in/ ).

[Edit]:
Added the "Add Account."
Currently, there is no Deleted accounts. You can always modify accounts.


I've yet to add a setting for the "main" account to show up.

Proper security assumes that the server WILL be compromised and databases stolen. Password hashing is precisely intended to minimize the damage from such an event.

So while letting his database fall into the wrong hand was one of his many mistakes definitely, it wasn't the key. The most damning was using plain unsalted un-iterated md5 to hash his passwords. That meant one single run of md5 would be sufficient to brute force the entire database. For those who already have existing rainbow tables, it will take seconds to crack weak passwords. For those who don't, it takes only minutes to few hours to generate the rainbow tables for weak passwords (up to say 8~9 characters) making it very profitable to do so.

If he had employed commonly available password encryption libraries using better hash algorithm like SHA256 and blowfish, with password stretching to strengthen weak passwords, it would had made the attack unworthwhile because of the cost of even cracking one user's password.

The real irony here is that this computational cost is what protects the bitcoin blockchain yet the largest bitcoin exchange was not making use of it.

While the specific lesson from the mtgox fiasco was related to weak hash algorithm, his sensitivity towards all forms of possible compromise should be heightened due to that. So I don't think it's fair to say he learnt the wrong lessons but rather he likely learnt more lessons than just the one he got hit with.

Real life comes first.

Anyways, I was meaning an updated version of the source.
I'm going on vacation, and I'll only have 4GB of bandwidth for 5 days.
Meaning, I'll be Internet Suffocation and that's when I get many of my projects done.

I've got one project that allows someone to resell our gameservers (I work for a GSP).
I can assume that anyone who'd like to...could buy a reseller from us and re-sell under Bitcoins.