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

Working... the only thing I was up to do before release the beta was to implement schedule and recurring payouts and admin accounts.
I may re-pick this project later on.

Is it working?  Or close to working?

Replying to this:

1) yes...
2) NO IT DOES NOT
3) yes...
4) NOPE, again
5) NOPE also

What went on here actually:

After that MtGox crap everybody suddenly become a so called "security expert", except that less than 0,00001% of the "opinion givers" are in fact any of such. So they jump in based "on what they read on forums" or other ill informed/hard to interpret source and try to play "the expert"... coming out with such a ridiculous attack surface as "Inside the code" (means changing the code itself - if someone changes the code, he doesn't need to inject anything, as that one can do whatever he wants on whatever project he got people to download his modified code).

For the project however; I'm done with it... anybody can continue if want.

Pre-Alpha was released.

http://www.bcommerce.biz/phpcoin-pre-alpha-release.zip

 

EDIT: Sry for the first to download, I forgot to include the sql dump. If your pack is missing a phpcoin.sql file, just download again.

2. Currently as it is, the snippets as it is, does clean the input and should in theory prevent SQL injection.
3. Only if the somebody modifies the code in a naive way, which unfortunately isn't that uncommon.
4. Dependent on #3

What we're suggesting that is that he adopts a convention that will be less prone to such potential issues. In a closed project where you can be sure of the skill/quality of the involved developers, it's OK to ignore this. However, as an open source project, it's reasonable to expect that somebody else would eventually use and modify it. The use of prepared statements (and why it came about) has been strongly recommended for years.

But ultimately, it is his project, so like I say, he can just disregard our suggestion as pure paranoia

He's properly sanitized his code.  The only way it could potentially be de-sanitized is if an idiot coder added some new variables that weren't sanitized.  While I can see Xephan's point regarding sanitizing the code via prepared statements to protect against people downloading his code and modifying it, I won't hold it against BCEmporium for not implementing it.  As long as you're not a complete moron coder, you'll be sure to sanitize the inputs, so it doesn't matter anyway.  And if someone really does want to protect against the moron coders out there, they can feel free to change the code once it is open sourced.

BCE - keep on coding the project, and forget the naysayers.  They can modify it how they like - you just build it how you like.  I appreciate that you've tackled such a project and plan to release it open source. 

Paranoia isn't "common sense".

MtGox wasn't hacked, wasn't injected... simply put a db dump in the wrong hands. Do not try to circumvent "human errors" with "ultra-paranoia security level" on informatics, computers can't do anything about human errors anyway.

Other than that it was supposed to be "common sense" that if you don't come to realize your db was compromised in the first place, it doesn't quite matter whatever you choose to encrypt whatsoever.
M'Tux hadn't realize what happened, because all of this "sudden security experts" came out from MtGox's attack, he hadn't realize his db was compromised, so whoever was behind the attacks would have all the time in the World to do what he wants. To the "best", he would be slow down, nothing else.

For the "tips" received so far; there's nothing to gain and it generates inconsistent code to follow those sort of "advices". Will "clean up" what? Every time it goes to db already within the code?! It would output:

$user = "my'user";
first (AND ONLY - that's the way to do it) clean up:
$user = "my\'user";
select...where user like '$user'...

Now... supposing I would go for a second clean up, as the data will hit the db again:
$user = "my\\\'user";
see anything wrong here?

the potential attack surface is inside the code. If the code is compromised (means you download it from somewhere you shouldn't anyway) it can be compromised on several ways without the need for "SQLi". Why bother if the attacker can simply mysql_query("whatever he wants here");?!

Today I didn't code, was around that Cinfu VPS (tip: don't go to vps 1, 2+).


BOTTOM LINE:

Help needed
A way to figure out network fees before the transaction
Graphics/CSS

Help NOT needed (or welcome)
Your paranoia level - yeah, it's open source, you can put all your paranoia into it as soon as you get the code.

And suddenly all became affected by security paranoia...

Actually for someone do that, he needs to temper the code; means whoever download it download it tempered, and unless can check it is pretty much f***ed anyway no matter what I do or don't.

not "guys" just "guy", the rest of us are just trying to tell him the same thing: that it's better to go prepared statements

That is what an attacker might want to do.

However, a naive coder (and sadly I've seen quite a few), may not realize you are doing data sanitization/cleansing in an earlier part. He goes and make the mistake of looking at code only in the areas he thinks is needed. Such as in adding some new data field to his customized version, say some kind of numeric flag or details during registration simply by inserting the relevant db fields and $variable into the query string and populating it from $_POST. Some attacker seeing a new thing on this site decides to just test it out for fun and there it goes.

While you might think it's unlikely, or that the noob deserves it, it's part of the responsibility of an open source coder to ensure his code is robust to begin with, especially if more than one person immediately flag it as a potential problem.

Are you serious? You guys are still using direct query statements? That's wayyyyy 2008.

If you just want to get the mess of sanitizing every fucking thing, prepared statements are the way to go.

All your points are needless actually.
If some one get to be dumb enough to do something like:

$user .= "'; DROP users";

then such person isn't a coder (is an attacker at best) and therefore has no reason to touch the code at all.

Like I said, while you would likely take note of these because of familiarity with the code, somebody else subsequently might make the mistake. Unless I'm mistaken about this going to be an opensource project? So the safest approach is always to assume that the data is unclean and cleanse it immediately before sending it to the db. Of course you could consider me being paranoid, as long as you don't mind the possibility of a "I told you so" in the future



As a general rule, I'd recommend always putting a "limit 1" behind such queries. So that even if somebody manages somehow to get passed the variable cleansing, the operation he might be attempting may in this way possibly be limited to one, or become an invalid query and so get stopped. Again, you may consider me paranoid


Unfortunately not, I haven't looked into the code yet.

Xephan,

That's senseless! You're implying I may "inject myself" along the code. The vars must be clean up on entry, as they will go to mysql more than once.

Eg. upon register:

query 1: select * from users where user like '$user'
to check whether there's already one account registered with that username
later
select * from users where email like '$email'
to ensure unique emails... etc

There're no more changes in the var that may get it injected along the way until the inserts. Passwords doesn't require cleaning up because they always hit the db hashed.

Now... for the question I put above. Any answer?
BTW, I bough a VPS with cinfu.com and will put the project and demo there.

I did but found no good reason for it, that's why I asked. It certainly isn't related to PECL or PDO (which I don't use since like you I also think it's a mess). While you have the function that you called, but it's a potential weakness since variables may come from different parts of the code or be altered along the way. The value may had been "safe" after your function call but may no longer be just before sql insertion.

While you're the only one working on it, your due diligence may ensure something like that doesn't happen. But once released, this could end up being a trap for less careful coders who are modifying unfamiliar code.

Hence I believe it's better to ensure that cleansing is done just before insertion. Along with the added strength of numeric typing using bind_params, ensures that even if somehow code slips past, it would still get rejected for not being a number where one is expected.

This is designed to:

Your own box
Your own Virtual Machine
A VPS/VDS/Dedicated Server

As you need to install software, such as bitcoind, this is not suitable for shared hosting.

Now a doubt

Anyone knows how to make bitcoind check whether a transfer fee will be paid before it does anything?
I can't figure that one out, so I'll code this way:

Total available amount = balance - 0.0005
Check the transaction after, if a fee was paid remove the 0.0005 from the user's account, if not leave it there.

Just use pbkdf2 with 10000-20000 iterations. Use sha512 as the hash algorithm. Here is a good example of implementation. Its a pretty damn good way to store your passwords.

Store output binary key lengths (below 255 char) in a tinyblob field.

I think the best way for passwords to remain secure is to use hashing methods that are computationally intense with respect to brute-forcing, but computationally inexpensive for a server to process once for a user to log in.  If you create a sequence of hashes that takes the server 0.5 seconds to compute, then it would be nigh impossible for any single person to crack even one user's password, unless we're talking about using hardware in the far future.

@AnnihilaT I keep saying the most important feature of password security is you to *know* your db was compromised, encryption will only make you gain some time to do something about... but they don't believe it.

Now... while waiting another deposit to get 6 blocks, to test deposit forwarding, here're some screens of what has been made so far:








Database "config" table look:



Roadmap to PreAlpha: Withdraw functions - once done I'll pre-release it by my website. Alpha will be at SourceForge or GitHUB