Quote from: danda on May 14, 2019, 05:24:52 PM

If I understand correctly, the 1BTC private key is stored encrypted inside a SQL database and the encryption key is held by a user on their own device (not on the server).

As such, if an attacker is able to get into the server, even root access, full database dump, etc, they still will not be able to access the private key.

That's a good design, imho. I wish all companies would do it.

So as far as this competition/bounty goes, I doubt anyone will obtain the 1BTC.

That said, the present scenario does not accurately reflect conditions in a production environment.

In production, you would have user records being created and updated.

In this scenario, if an attacker is able to get into your web server, they should be able to modify javascript sent to the client in such a way that the client sends data unencrypted to server (or another server controlled by attacker) when creating or updating a record.

As such, I would propose that for this test/bounty to actually be useful and meaningful, you should modify the test conditions with simulated users that are regularly creating/updating records that contain valid private keys. This would probably require splitting the 1BTC into many smaller pieces.

A patient attacker with server access could sit and wait until they have collected some or all of it.

First, thanks!

You understand correctly. Mostly. With few minor gaps that will probably change everything Grin

That's totally our fault, btw. I don't want to keep you waiting for the release of our tech whitepaper - so here's the full explanation:
The BTC is held encrypted in the SQL database - that's correct. The key is held with the user on their device - that's also correct, but incomplete.
Not on the server - well... that's partially correct. Not on the server but on servers.

Let me explain:
The ultimate goal is for the user to be the only one with his key, on his device, being the only one able to encrypt/decrypt and sign.
It would be so easy if we could assume users set up their devices so we can store the key there - but we found we can't. On mass scale, users find wallets (hardware or software) usability to be too complex and restrictive. They don't understand the process of securing private keys or mnemonic phrases and they want to be able to set up the same wallet on multiple devices (desktop, tablet, phone, etc) easily. Using QR codes is great - but still light-years more complicated to the average user than the ease of a username and password or even 2FA.

The Tide Protocol defines 4 kinds of client-side wallets - with a secure device or software wallet being 2 of those options, however for the widest mainstream audience, Tide defines a new type of wallet.
With the Tide Protocol's ubiquitous client, we reconstruct the wallet, with all its preferences and private keys - on the fly, in the desktop browser, all from just the user web authentication. We reconstruct it from a set of decentralized array of nodes (ORKs) that as a collective, have enough information to cater for that process - so you can say that the information required to get the key is on those servers. When you log in using the dummy credentials, that's exactly what's happening.
I know that reconstructing private keys in javascript, in the browser, from publicly accessible servers sounds like a terrible security nightmare - but we've been working on it for quite some time to make it fullrproof* and we believe we have. Or close to it.

You mentioned modifying the javascript on the server side as a likely attack vector for data-in-transit scenario - which may be true, and the Tide Protocol has countermeasures for that too, but that's not the focus of this exercise just yet. We plan to add it later on (I can't wait for it!).

Currently, we look at a data-at-rest scenario with all possible attack vectors on the servers (web, database, ORKs, blockchain, etc) which suggests that if there's any vulnerability on any of the servers in this architecture, someone can definitely exploit it to get the BTC. Possible vectors would be:

Break the database, get the encrypted records and brute force it
Break the ORKs - get the user key (CVK)
Brute force / dictionary attack the username/password

Quote from: danda on May 14, 2019, 05:24:52 PM

edit: or every user record modification could contain the private key for full 1BTC. Then a single breach would result in full bounty.

This sounds very interesting. Can you elaborate on that? What did you mean by "every user record modification could contain the private key"?