Quote from: whitslack on September 23, 2012, 01:39:50 AM

Quote from: shtylman on September 22, 2012, 10:42:04 PM

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.