btc project security: Encryption of php files + db entry hashes = more security?

[winnetou]

Hi,

Recently I thought about how you can make Bitcoin web projects more secure.

I came up with the following idea:
- Encrypt your php files (e.g. with http://www.sourceguardian.com/)
- Create a hash of every financial sensible db entry (transactions, account balances etc.) and check the hash on every access

Benefits:
If a hacker gets access to the database he can not add new transactions or change existing ones because he does not know the algorithm of your hash. Even if he gets access to the entire server he can not get (at least not easily I think) the hash algorithm because the php files are encrypted.

Furthermore you can add an alarm when one hash is invalid that causes a stop to your bitcoin transaction handler or something like that.

What do you think and has somebody experience with encryption of php files? (In a trice I found no good open source tool for doing that)

[1713439454]

1713439454

[1713439454]

1713439454

[1713439454]

1713439454

[1713439454]

1713439454

[Pieter Wuille]

If an attacker gets access to you system, he can just run the code to update the hashes as well...

[winnetou]

But he does not know the code / hash algo. because the php files are encrypted

[Pieter Wuille]

He doesn't need to understand them - he can just execute them.

[DeathAndTaxes]

The server runs the encrypted code "somehow".
If the attacker gains admin access he can do anything the server can.

[hamdi]

php encryptions are all not safe.
they can all be reversed.

you could compile a custom hashing executable and call that from within php

[Pieter Wuille]

And the attacker will just run the custom hashing executable.

[btctree]

let's say if a hacker get access of your sql and file system(like he got your root password)

so he can:
1: call ./bitcoind send command in ssh to send your bitcoins to his address.
2: upload a php (for example,JSON-RPC), to control your bitcoind with same command in 1
3: decrypt your php encode, then get the algo of hash of your sql data, won't be too hard if he has skill to hack your server
4: or just leave some small scripts in your payment process code which allows him to receive bitcoins when you pay/receive bitcoins, he can also set many conditions for this "steal program" so you can't find out there is problem only after long time or huge damage.
5: many others, predictable and unpredictable...

there is no 100%(not even 99%) secure at this moment for hosting a bitcoin in/out project. once your system get cracked, your bitcoins are gone. but i know there is a new thing called "multi-sig transactions" coming out on bitcoin's application which can stop unauthorized payments be processed even your system has been cracked.

[rjk]

In order to run code in an autonomous manner, a server must store the decryption key somewhere, and a hacker can usually find it, rendering the encryption useless. Limited exceptions can be made for keys that are required on boot and not stored, but when that happens they are stored in memory and can possibly still be had by a smart hacker.

[btctree]

In order to run code in an autonomous manner, a server must store the decryption key somewhere, and a hacker can usually find it, rendering the encryption useless. Limited exceptions can be made for keys that are required on boot and not stored, but when that happens they are stored in memory and can possibly still be had by a smart hacker.

walletpassphrase won't help, because the hacker can either:
scan your memory cache
or
just use the same session you are already using. for example, use your own JSON-RPC to send bitcoins.

[rjk]

In order to run code in an autonomous manner, a server must store the decryption key somewhere, and a hacker can usually find it, rendering the encryption useless. Limited exceptions can be made for keys that are required on boot and not stored, but when that happens they are stored in memory and can possibly still be had by a smart hacker.

walletpassphrase won't help, because the hacker can either:
scan your memory cache
or
just use the same session you are already using. for example, use your own JSON-RPC to send bitcoins.

Exactly, and the type of attack depends on how much access the hacker has, and how he got in. If he was able to reset the root password through a control panel for instance (like bitcoinica), he would have root access to plant a keylogger or pick up the passphrase if it were stored on disk. If he broke in through a SQL vulnerability, he could grab the passphrase from memory, even if it were not stored on disk. It's a difficult kind of situation, but HSMs such as what DeathAndTaxes is looking into can mitigate the risk somewhat.

[DeathAndTaxes]

there is no 100%(not even 99%) secure at this moment for hosting a bitcoin in/out project. once your system get cracked, your bitcoins are gone.

 

Yet.  
If the host knows the private keys then an attacker who seizes controls of host seizes control of the private keys.

So what if the host never knows the private keys?

Code:

BSM
Host: v0.0.1.1238
Module: v0.0.1.608
Runtime: v4.0.30319

Initializing BSM with root key to form deterministic seed.
Host: 'Initialize(ZOpK/CiAP/aU1HlNOiJxeyCD8MUI/Zf1xCDFtOJPpGU=)'
Module: 'OK'

Verifying root key (module should return SHA256 hash of Root Key)
Host: 'RootHash()'
Module: 'E9o5VWDsusAWOTf5lVPHWI13YeMCXJ85S+SYqFfW6Lc='

Requesting a new address
Host: 'GetAddress(1)'
Module: '112ypupfk6upHCL65NhqNhtv9RBwW1jR1w'

Even storing private keys (and fund control rules) into hardware device isn't 100% secure but it should raise the bar substantially.  All major robberies to date have been "smash and grabs".  Once attacker gained access to the server he simply copied the private keys to a client he controlled and transferred the funds.