Quote from: shtylman on September 22, 2012, 08:23:53 PM

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

Quote from: shtylman on September 22, 2012, 08:23:53 PM

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):

Quote from: eldentyrell on September 22, 2012, 05:14:24 PM

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.