Topic: New bitfloor API: silly security? (Read 2186 times)

Does this new passphrase have a complexity requirement? Seems like another password to brute-force for the undiscovered attacker.

Have you recovered the ~20,000BTC, absorbed the loss yourself, or handed the loss the your customers? I apologize if i have missed something... busy day and far to many threads to follow.

The mint chip challenge used a client cert to authenticate with its test servers.  It was trivial to install a browser cert and then only that browser could access the server or your account.  You were also required to authentic the mint chip server cert before you could make any transactions.  Seemed to me a very secure means of authentication for a financial service.  And as certificate authentication have been around years I'm surprised that it still has not been more widely implemented for financial web services. 

Indeed this doesn't look all too good.

Common doesn't imply good. The Keynesian model of economics is common, but that doesn't make it good.

This whole "security model" looks like something designed by someone with no education in cryptographic protocols.

Using an API key and a shared secret (known to both client and server) with HMAC-based authentication is a pretty common model for REST services. This is the same model used by MtGox, BitMe, and Amazon S3 along with Bitfloor.

The extra passphrase field is another layer of security so it isn't useless. It protects against very bad scenarios such as a user obtaining a list of the API keys and shared secrets. Assuming the passphrase is stored by Bitfloor as a salted hash, the usefulness of the list is quickly degraded.

Neither the secret key nor the passphrase nor the signature are actually needed to ensure the security and authenticity of customers' API requests. The API key is already sufficiently large (128 bits) to avoid a brute force attack, and it's never transmitted except over an encrypted (SSL) connection, and the client won't send it if the server's certificate doesn't validate, so neither a MITM nor an eavesdrop are possible. Also, SSL does already include nonces, so a replay attack is not possible, and thus the nonce field is unneeded, too.

Of course, there is still the possibility of a database dump, which would reveal all API keys to the attacker. Really, you should be requiring client-certificate authentication on the SSL connections to the API server, and your database should contain certificates for all of your API users. Then it wouldn't matter if an attacker obtained a dump of your database; they still couldn't pretend to be any of your users because they wouldn't have the private keys associated with those certificates.

Basically, all of these extra HTTP header fields are clumsy attempts to solve a problem that is already solved in SSL. And by the way, you're supposed to prefix non-standard header field names with "X-" so they don't conflict with any future standards.

The secret key is used to check your message signature and as such we must use it to calculate the signature and check it for validity. The signature ensures that your message was not tampered with by a MITM.

If you would like any clarification about the relevance of the fields please contact [email protected] and I will be happy to go over the details. It will help me in understanding how the documentation can be clarified.

Who selects it is totally irrelevant, since the user has to type it in to your website when they create it.  This is no more secure than if you randomly generated the "passphrase" and told the user "here is the passphrase I have picked for you".



So what's the point of the secret-key then?

As I wrote earlier (and you did not respond to):


Sounds like you guys just discovered that you should have been storing the secret-key as a salted hash instead of cleartext.  But instead of simply fixing that, you bolted on a whole new secondary password system that makes the original one redundant.  

This does not instill confidence.

Cool. I guess in theory I could have done this before by encrypting my API key with a passphrase, but this is much easier.

Correct. How you choose to handle passphrase storage and usage is completely up to you. If your programs operate in such a way that you can enter the passphrase only during startup then you will further prevent tampering or use of your trading programs without your authorization.

Doesn't this also mean that if we want, users can require typing in the passphrase whenever starting up our custom apps? That way the "keys to the kingdom" are not simply laying around on my computer's hard drive.

That would only work if the data were stored not just in different domains but in physically separate locations.
A database dump would be a complete compromise.  Salted hash password or otherwise.

If I were designing an API where this threat was a real possibility I would use a totally different approach.

I would use a public/private key signing system.  Similar to how bitcoin itself functions.  If someone got their private key compromised that's their own personal problem.  However you're only storing the public key so a compromise is completely irrelevant.

This is precisely the difference. By having a passphrase which is selected by the user, having access to the api key and secret key (database dump or otherwise), will not allow the attacker to create phony API requests. The API still generates a strong secret key for signatures which is not user selected.

Previously (and with many current exchange APIs), if an attacker is able to get a list of api keys and secrets, and the exchange does not detect or react quickly enough, then the attacker can simply use the keys to make API calls as if they were you (no intercepting or other complex action required on the server by the attacker). Using a passphrase which is stored using a one way salted hash ensures that even with key access the attacker will not be able to make requests without knowing your user selected passphrase. The use of a passphrase sets up a shared responsibility to secure secrets between the client and the server without all of the required data being stored by our server to make the API request.

Here: https://bitfloor.com/docs/api/order-entry/rest.

I've implemented it and I'm using it right now -- it does indeed function as described above.

That's strange, where did you see that?

Bitfloor is back, and they have changed their API.  Now you have to pick an extra "passphrase" (which isn't your password or your api key or your secret key but something different) and send that as an SSL-protected-but-otherwise-cleartext header with each API call (i.e. even their frontend HTTP servers can see your passphrase).

How, exactly, does this improve security?  The "passphrase" is just another secret, like the secret-key.  Why is two passwords more secure than one password?  Especially when the existing password is already a random 64-byte string.

The only difference I can see is that the passphrase is chosen by the user rather than being randomly generated by bitfloor.  But if anything that reduces security: instead of bitfloor being sure the password is suitably random, users can choose weak passwords.

None of this makes any sense.

If a hacker compromises bitfloor's servers -- even the internet-facing frontend servers which are always the weakest point -- they can watch the "passphrases" stream across the wire.  No extra security there.

Maybe they're hoping that if they're hacked, the hacker will only gain the passphrases of users who happen to make API calls during the hack period.  But they could have achieved that with the old API: simply store only the SHA hash of the "secret key" on disk and forget the actual secret key immediately after it is generated.  Exactly the same level of security, no API change.

This worries me.  Unless I've missed something major, this indicates that somebody at Bitfloor does not understand security.  I hope I'm wrong about that.