Bitcoin Forum
October 14, 2019, 09:43:15 AM *
News: If you like a topic and you see an orange "bump" link, click it. More info.
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: New bitfloor API: silly security?  (Read 2090 times)
eldentyrell
Donator
Legendary
*
Offline Offline

Activity: 980
Merit: 1001


felonious vagrancy, personified


View Profile WWW
September 22, 2012, 05:14:24 PM
 #1

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.

The printing press heralded the end of the Dark Ages and made the Enlightenment possible, but it took another three centuries before any country managed to put freedom of the press beyond the reach of legislators.  So it may take a while before cryptocurrencies are free of the AML-NSA-KYC surveillance plague.
1571046195
Hero Member
*
Offline Offline

Posts: 1571046195

View Profile Personal Message (Offline)

Ignore
1571046195
Reply with quote  #2

1571046195
Report to moderator
1571046195
Hero Member
*
Offline Offline

Posts: 1571046195

View Profile Personal Message (Offline)

Ignore
1571046195
Reply with quote  #2

1571046195
Report to moderator
1571046195
Hero Member
*
Offline Offline

Posts: 1571046195

View Profile Personal Message (Offline)

Ignore
1571046195
Reply with quote  #2

1571046195
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1571046195
Hero Member
*
Offline Offline

Posts: 1571046195

View Profile Personal Message (Offline)

Ignore
1571046195
Reply with quote  #2

1571046195
Report to moderator
1571046195
Hero Member
*
Offline Offline

Posts: 1571046195

View Profile Personal Message (Offline)

Ignore
1571046195
Reply with quote  #2

1571046195
Report to moderator
isis
Full Member
***
Offline Offline

Activity: 154
Merit: 100


View Profile
September 22, 2012, 06:00:35 PM
 #2

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.

That's strange, where did you see that?

Interested in OpenPay?
https://github.com/openpay
Donate to show your appreciation and support the effort!

1LMDCSAwjhT2Vp1sSf62dybEYW3MYpsoZj

Pyramining Links - Help OpenPay and get a 10% bonus on your funds.
http://pyramining.com/referral/zre9ysgqt
http://pyramining.com/referral/ans9km72g
http://pyramining.com/referral/f3k4xebzp
http://pyramining.com/referral/nc3ag2sdb
eldentyrell
Donator
Legendary
*
Offline Offline

Activity: 980
Merit: 1001


felonious vagrancy, personified


View Profile WWW
September 22, 2012, 07:46:58 PM
 #3

That's strange, where did you see that?

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.

The printing press heralded the end of the Dark Ages and made the Enlightenment possible, but it took another three centuries before any country managed to put freedom of the press beyond the reach of legislators.  So it may take a while before cryptocurrencies are free of the AML-NSA-KYC surveillance plague.
shtylman
Sr. Member
****
Offline Offline

Activity: 243
Merit: 250



View Profile
September 22, 2012, 08:23:53 PM
 #4

The only difference I can see is that the passphrase is chosen by the user rather than being randomly generated by bitfloor.

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.
isis
Full Member
***
Offline Offline

Activity: 154
Merit: 100


View Profile
September 22, 2012, 10:15:00 PM
 #5

The only difference I can see is that the passphrase is chosen by the user rather than being randomly generated by bitfloor.

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.

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.

Interested in OpenPay?
https://github.com/openpay
Donate to show your appreciation and support the effort!

1LMDCSAwjhT2Vp1sSf62dybEYW3MYpsoZj

Pyramining Links - Help OpenPay and get a 10% bonus on your funds.
http://pyramining.com/referral/zre9ysgqt
http://pyramining.com/referral/ans9km72g
http://pyramining.com/referral/f3k4xebzp
http://pyramining.com/referral/nc3ag2sdb
qxzn
Hero Member
*****
Offline Offline

Activity: 609
Merit: 505



View Profile
September 22, 2012, 10:22:30 PM
 #6

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.

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.
shtylman
Sr. Member
****
Offline Offline

Activity: 243
Merit: 250



View Profile
September 22, 2012, 10:25:49 PM
 #7

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.

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.

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.
qxzn
Hero Member
*****
Offline Offline

Activity: 609
Merit: 505



View Profile
September 22, 2012, 10:26:53 PM
 #8

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.

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

Activity: 980
Merit: 1001


felonious vagrancy, personified


View Profile WWW
September 22, 2012, 10:27:56 PM
 #9

This is precisely the difference. By having a passphrase which is selected by the user,

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".


having access to the api key and secret key (database dump or otherwise), will not allow the attacker to create phony API requests.

...

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.

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

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

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.

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.

The printing press heralded the end of the Dark Ages and made the Enlightenment possible, but it took another three centuries before any country managed to put freedom of the press beyond the reach of legislators.  So it may take a while before cryptocurrencies are free of the AML-NSA-KYC surveillance plague.
shtylman
Sr. Member
****
Offline Offline

Activity: 243
Merit: 250



View Profile
September 22, 2012, 10:42:04 PM
 #10

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

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.

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 support@bitfloor.com and I will be happy to go over the details. It will help me in understanding how the documentation can be clarified.
whitslack
Full Member
***
Offline Offline

Activity: 120
Merit: 104



View Profile
September 23, 2012, 01:39:50 AM
 #11

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.
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.
freewil
Member
**
Offline Offline

Activity: 92
Merit: 10



View Profile
September 23, 2012, 07:39:37 AM
 #12

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.
whitslack
Full Member
***
Offline Offline

Activity: 120
Merit: 104



View Profile
September 23, 2012, 02:51:27 PM
 #13

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.
Common doesn't imply good. The Keynesian model of economics is common, but that doesn't make it good.

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.
This whole "security model" looks like something designed by someone with no education in cryptographic protocols.
MPOE-PR
Hero Member
*****
Offline Offline

Activity: 756
Merit: 500



View Profile
September 24, 2012, 08:58:10 PM
 #14

Indeed this doesn't look all too good.

My Credentials  | THE BTC Stock Exchange | I have my very own anthology! | Use bitcointa.lk, it's like this one but better.
BCB
CTG
VIP
Legendary
*
Offline Offline

Activity: 1064
Merit: 1000


BCJ


View Profile
September 24, 2012, 09:19:33 PM
 #15

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.
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 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. 
BlackHeartFund
Full Member
***
Offline Offline

Activity: 126
Merit: 100



View Profile
September 28, 2012, 03:10:32 AM
 #16

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.
weex
Legendary
*
Offline Offline

Activity: 1104
Merit: 1000



View Profile
September 28, 2012, 03:35:02 AM
 #17

Does this new passphrase have a complexity requirement? Seems like another password to brute-force for the undiscovered attacker.
Pages: [1]
  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!