Bitcoin Forum
November 23, 2017, 07:06:16 PM *
News: Latest stable version of Bitcoin Core: 0.15.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: [1] 2 »  All
  Print  
Author Topic: Best Security Practicies for a Novice: mySQL/Bitcoin Client  (Read 1531 times)
crazy_rabbit
Legendary
*
Offline Offline

Activity: 1176


RUM AND CARROTS: A PIRATE LIFE FOR ME


View Profile
February 04, 2013, 11:18:23 PM
 #1

So I'm working on a project that will hold bitcoins and of course, security is the most obvious risk/danger.

On advice of the developer we have a specially compiled version of bitcoind (unnecessary RPC calls have been removed, as well as calls that pose a security risk).

Bitcoind runs under a separate user than the php script. SSH/ftp into the server is only possible with keyfiles.

All mysql calls are escaped so injection should (hopefully) be covered.

A cold wallet is being implemented so the majority of funds are off-site.

What other steps should I be keeping in mind? After some advice from a friend I'm worried as well about somehow the database being compromised in some slight way as to affect imperceptible shifts in balances that I would be unable to detect.

I toyed with the idea of every database entry having a hash generated from all the data and the hash being periodically verified against the database to check for manipulation. But is this realistic?

Anyone have any more ideas? Thank you

more or less retired.
1511463976
Hero Member
*
Offline Offline

Posts: 1511463976

View Profile Personal Message (Offline)

Ignore
1511463976
Reply with quote  #2

1511463976
Report to moderator
1511463976
Hero Member
*
Offline Offline

Posts: 1511463976

View Profile Personal Message (Offline)

Ignore
1511463976
Reply with quote  #2

1511463976
Report to moderator
Join ICO Now A blockchain platform for effective freelancing
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1511463976
Hero Member
*
Offline Offline

Posts: 1511463976

View Profile Personal Message (Offline)

Ignore
1511463976
Reply with quote  #2

1511463976
Report to moderator
1511463976
Hero Member
*
Offline Offline

Posts: 1511463976

View Profile Personal Message (Offline)

Ignore
1511463976
Reply with quote  #2

1511463976
Report to moderator
hardcore-fs
Full Member
***
Offline Offline

Activity: 196


View Profile WWW
February 05, 2013, 12:17:06 AM
 #2

With the admin tool you can make any changes you want to the database and it cannot be detected, also corruption
better to encrypt certain fields in the database

BTC:1PCTzvkZUFuUF7DA6aMEVjBUUp35wN5JtF
CIYAM
Legendary
*
Offline Offline

Activity: 1862


Ian Knowles - CIYAM Lead Developer


View Profile WWW
February 05, 2013, 12:32:32 AM
 #3

Agreed that if you are storing information that is sensitive (such as email addresses or other more personal information) then it should be encrypted.

If you need to *index* any such columns then this will make things trickier (although you could create another column for indexing purposes that contains the first x characters provided that isn't going to be a problem application-wise).

With CIYAM anyone can create 100% generated C++ web applications in literally minutes.

GPG Public Key | 1ciyam3htJit1feGa26p2wQ4aw6KFTejU
crazy_rabbit
Legendary
*
Offline Offline

Activity: 1176


RUM AND CARROTS: A PIRATE LIFE FOR ME


View Profile
February 05, 2013, 09:14:28 AM
 #4

Sensitive information, like email is encrypted and salted. The admin tools are locked to IP addresses as well, although their powers are limited in scope. Users can choose to use Google Authenticator as well.

Anything else? I'm sure there must be lots of things I'm overlooking!

more or less retired.
K1773R
Legendary
*
Offline Offline

Activity: 1680


/dev/null


View Profile
February 05, 2013, 09:18:58 AM
 #5

Sensitive information, like email is encrypted and salted. The admin tools are locked to IP addresses as well, although their powers are limited in scope. Users can choose to use Google Authenticator as well.

Anything else? I'm sure there must be lots of things I'm overlooking!
encrypted + salted = ?
need more input Wink

just a basic rule: dont use fancy librarys, or libs who have/had alot of vulnerabilitys

[GPG Public Key]  [Devcoin Builds]  [BBQCoin Builds]  [Multichain Blockexplorer]  [Multichain Blockexplorer - PoS Coins]  [Ufasoft Miner Linux Builds]
BTC/DVC/TRC/FRC: 1K1773RbXRZVRQSSXe9N6N2MUFERvrdu6y ANC/XPM AK1773RTmRKtvbKBCrUu95UQg5iegrqyeA NMC: NK1773Rzv8b4ugmCgX789PbjewA9fL9Dy1 LTC: LKi773RBuPepQH8E6Zb1ponoCvgbU7hHmd EMC: EK1773RxUes1HX1YAGMZ1xVYBBRUCqfDoF BQC: bK1773R1APJz4yTgRkmdKQhjhiMyQpJgfN
davout
Legendary
*
Offline Offline

Activity: 1372


1davout


View Profile WWW
February 05, 2013, 09:36:10 AM
 #6

So I'm working on a project that will hold bitcoins and of course, security is the most obvious risk/danger.

On advice of the developer we have a specially compiled version of bitcoind (unnecessary RPC calls have been removed, as well as calls that pose a security risk).
That's actually terrible advice, that means you need to maintain your separate fork of bitcoin which will make it much less straightforward to apply patches and security fixes as they come. Choose a strong password for the RPC calls, listen only on the local interface and add some iptables rules on top of it just to be sure. MUCH more secure. If you keep the "send" calls disabling other calls is pointless. If you don't keep them you might as well run a wallet such as armory.

Bitcoind runs under a separate user than the php script. SSH/ftp into the server is only possible with keyfiles.
If you have proper passphrases on the private keys it is a good idea.

All mysql calls are escaped so injection should (hopefully) be covered.
Don't reinvent the wheel, use a framework or a lib that does that for you.

A cold wallet is being implemented so the majority of funds are off-site.
Good.

I toyed with the idea of every database entry having a hash generated from all the data and the hash being periodically verified against the database to check for manipulation. But is this realistic?
No, because if someone can mess with the DB they can mess with the hash.
If you really want to go down that road keep backups and run periodic data comparisons to see if historical data has been altered.

Sensitive information, like email is encrypted and salted. The admin tools are locked to IP addresses as well, although their powers are limited in scope. Users can choose to use Google Authenticator as well.
Encryption is absolutely pointless if you keep the decryption keys on the server.

Agreed that if you are storing information that is sensitive (such as email addresses or other more personal information) then it should be encrypted.

If you need to *index* any such columns then this will make things trickier (although you could create another column for indexing purposes that contains the first x characters provided that isn't going to be a problem application-wise).
That doesn't make sense at all, if you need to query on a column chances are the application needs to be able to decrypt it at will for display or other purposes, meaning you'd have to have the keys on the server which defeats the whole thing.

CIYAM
Legendary
*
Offline Offline

Activity: 1862


Ian Knowles - CIYAM Lead Developer


View Profile WWW
February 05, 2013, 11:25:01 AM
 #7

That doesn't make sense at all, if you need to query on a column chances are the application needs to be able to decrypt it at will for display or other purposes, meaning you'd have to have the keys on the server which defeats the whole thing.

Wrong - you may not have even heard of a thing called a "transient" being a Rails user (so don't make corrections about stuff that you don't understand).

And - yes good luck in finding the keys in my compiled code (which only *part* is - something script kiddies just can't do now is it).

With CIYAM anyone can create 100% generated C++ web applications in literally minutes.

GPG Public Key | 1ciyam3htJit1feGa26p2wQ4aw6KFTejU
davout
Legendary
*
Offline Offline

Activity: 1372


1davout


View Profile WWW
February 05, 2013, 11:42:20 AM
 #8

Wrong - you may not have even heard of a thing called a "transient" being a Rails user (so don't make corrections about stuff that you don't understand).
What about transient objects ? (that exist in Rails, and in any framework that uses an ORM for the matter).
What makes you think I don't know anything else than Rails ?

And - yes good luck in finding the keys in my compiled code (which only *part* is - something script kiddies just can't do now is it).
Assuming OP is using a compiled language.

Assuming it's not trivial to decompile any kind of language to extract constants or do a memory dump for anyone who has the slightest clue about what they are doing.

Your security protects you against script-kiddies? Great! Now let's go back to real security that works with everyone.

Making it slightly harder to get the keys doesn't make a flawed security model less flawed.

CIYAM
Legendary
*
Offline Offline

Activity: 1862


Ian Knowles - CIYAM Lead Developer


View Profile WWW
February 05, 2013, 11:49:41 AM
 #9

Your security protects you against script-kiddies? Great! Now let's go back to real security that works with everyone.

Making it slightly harder to get the keys doesn't make a flawed security model less flawed.

Please Davout - go get someone to hack my site and then we can talk about security models.

There is *nothing* flawed apart from your (once again) bad behaviour in this forum (I suggest *growing up* and stop trying to be such a smart ass for starters).

With CIYAM anyone can create 100% generated C++ web applications in literally minutes.

GPG Public Key | 1ciyam3htJit1feGa26p2wQ4aw6KFTejU
davout
Legendary
*
Offline Offline

Activity: 1372


1davout


View Profile WWW
February 05, 2013, 12:03:04 PM
 #10

Please Davout - go get someone to hack my site and then we can talk about security models.
Keeping a decryption key on the same server that holds encrypted data is a bad security model.
This is factual, you can't have your cake and eat it too, security is about tradeoffs, if you want security you have to give up some convenience.
If someone tells you you can get a 7% weekly interest on your deposit he's probably a scammer.
If someone tells you you can encrypt data in the DB but automatically decrypt it at will he doesn't understand security. Slam dunk case of security-by-obscurity.

The is *nothing* flawed apart from your (once again) bad behaviour in this forum (I suggest *growing up* and stop trying to be such a smart ass for starters).
This is not about your little ego, it's about facts.

CIYAM
Legendary
*
Offline Offline

Activity: 1862


Ian Knowles - CIYAM Lead Developer


View Profile WWW
February 05, 2013, 12:10:11 PM
 #11

This is not about your little ego, it's about facts.

Hmm... my little ego - well let's just leave it at that (as yours is clearly *bigger*).

I was doing security since before you were even born but of course you *must* be better than I.

Cheesy

With CIYAM anyone can create 100% generated C++ web applications in literally minutes.

GPG Public Key | 1ciyam3htJit1feGa26p2wQ4aw6KFTejU
davout
Legendary
*
Offline Offline

Activity: 1372


1davout


View Profile WWW
February 05, 2013, 12:16:03 PM
 #12

I was doing security since before you were even born but of course you *must* be better than I.
Maybe it's time to brush up grandpa.

CIYAM
Legendary
*
Offline Offline

Activity: 1862


Ian Knowles - CIYAM Lead Developer


View Profile WWW
February 05, 2013, 12:20:00 PM
 #13

I was doing security since before you were even born but of course you *must* be better than I.
Maybe it's time to brush up grandpa.

Quoted for the sake of it (this is how a *professional* business guys show their stuff these days).

Also will use the *ignore* feature for the very first time (congrats - couldn't have used it on a more deserving member).

With CIYAM anyone can create 100% generated C++ web applications in literally minutes.

GPG Public Key | 1ciyam3htJit1feGa26p2wQ4aw6KFTejU
crazy_rabbit
Legendary
*
Offline Offline

Activity: 1176


RUM AND CARROTS: A PIRATE LIFE FOR ME


View Profile
February 05, 2013, 02:39:50 PM
 #14

Hey guys! Break it up!  Shocked

Honestly both of you are giving me really good advice to think about. Any practical ideas to keep the sever where the code is hosted safe? I presumably could get a server running that hosted the bitcoind dameon and listened only to the ip of the main server. But how to ensure someone can't get into my server where the app code is hosted?


more or less retired.
davout
Legendary
*
Offline Offline

Activity: 1372


1davout


View Profile WWW
February 05, 2013, 04:11:24 PM
 #15

Hey guys! Break it up!  Shocked

Honestly both of you are giving me really good advice to think about. Any practical ideas to keep the sever where the code is hosted safe? I presumably could get a server running that hosted the bitcoind dameon and listened only to the ip of the main server. But how to ensure someone can't get into my server where the app code is hosted?
You know, people write books about this subject. I suggest buying one.

DannyHamilton
Legendary
*
Offline Offline

Activity: 1988



View Profile
February 05, 2013, 04:45:30 PM
 #16

You know, people write books about this subject. I suggest buying one.
I thought the internet was created so that we wouldn't need books any longer?

davout
Legendary
*
Offline Offline

Activity: 1372


1davout


View Profile WWW
February 05, 2013, 04:53:29 PM
 #17

I thought the internet was created so that we wouldn't need books any longer?
Well, e-books would qualify as books in my view.
I guess what I'm trying to say is that if the OP is asking such general questions on an internet forum, it can mean that he simply is not ready to undertake the task of thoroughly securing his server.
So my general advice would be that he document himself about the general principles, the different security layers, understand all the trade-offs and design choices that impact security and come back with a solid plan.

The OP seems to have interesting ideas (on which I already commented) but a serious lack of experience. Lacking experience is allright as long as you know it and have the brains to think for yourself.

Two general security principles :
 - You can't have your cake and eat it too, there is *always* a trade-off between security and convenience, no exceptions.
 - Don't code security-related stuff yourself, someone has probably already done it, and done it better than you. Use libraries as much as possible, not fancy ones, but mature ones. Don't hand-escape SQL, don't hash passwords yourself, etc. You get the idea.

crazy_rabbit
Legendary
*
Offline Offline

Activity: 1176


RUM AND CARROTS: A PIRATE LIFE FOR ME


View Profile
February 05, 2013, 11:22:05 PM
 #18

I thought the internet was created so that we wouldn't need books any longer?
Well, e-books would qualify as books in my view.
I guess what I'm trying to say is that if the OP is asking such general questions on an internet forum, it can mean that he simply is not ready to undertake the task of thoroughly securing his server.
So my general advice would be that he document himself about the general principles, the different security layers, understand all the trade-offs and design choices that impact security and come back with a solid plan.

The OP seems to have interesting ideas (on which I already commented) but a serious lack of experience. Lacking experience is allright as long as you know it and have the brains to think for yourself.

Two general security principles :
 - You can't have your cake and eat it too, there is *always* a trade-off between security and convenience, no exceptions.
 - Don't code security-related stuff yourself, someone has probably already done it, and done it better than you. Use libraries as much as possible, not fancy ones, but mature ones. Don't hand-escape SQL, don't hash passwords yourself, etc. You get the idea.

A book is a very good idea. That said- there are tons of them. Any you could recommend in particular? If not, I'm sure amazon will help, but that said- I was thinking there might be others here who went through the same growing pains. :-)

more or less retired.
davout
Legendary
*
Offline Offline

Activity: 1372


1davout


View Profile WWW
February 05, 2013, 11:31:31 PM
 #19

A book is a very good idea. That said- there are tons of them. Any you could recommend in particular? If not, I'm sure amazon will help, but that said- I was thinking there might be others here who went through the same growing pains. :-)

I don't really have a specific book in mind, but if I see one I'll be sure to update this thread.
Part of the "growing pains" you mention is "growing", and growing takes time and patience Smiley

I wish you luck !

BCB
CTG
VIP
Legendary
*
Offline Offline

Activity: 1036


BCJ


View Profile
February 05, 2013, 11:57:43 PM
 #20

Close all unnecessary ports.

Only open ssh to admin's ip.

Don't run a mail server, irc bouncer or chat client on the same server.

If you can or if you can plan to scale run  Bitcoind, Web Server and mysql on separate servers.

Replicate mysql to a 4th server. 

Run Hourly encrypted backup on the Rep Server
Run Daily Encrypted back upon on the Main Mysql server
Save encrypted backup off-site daily.
Use an HSM to store and manage all private keys.

Plan for complete failure and run monthly complete restore runs only from back up.

implement fail over  in co-located data centers.

Pages: [1] 2 »  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!