title: OAuth 1.0a, 2-legged: how do you securely store clients' credentials (keys/secrets)?
body: <p>Am I correct that OAuth 1.0a credentials need to be stored in plaintext (or in a way that can be retrieved as plaintext) on the server, at least when doing 2-legged authentication?  Isn't this much less secure than using a username and salted+hashed password, assuming you're using HTTPS or other TLS?  Is there a way to store those credentials in such a way that a security breach doesn't require every single one to be revoked?</p>
  
  <hr>
  
  <p>In more detail: I'm implementing an API and want to secure it with OAuth 1.0a.  There will possibly be many different API clients in the future, but the only one so far has no need for sensitive user data, so I'm planning to use "2-legged" OAuth.</p>
  
  <p>As I understand it, this means I generate a consumer key and a shared secret for each API client.  On every API request, the client provides both the consumer key, and a signature generated with the shared secret.  The secret itself is not sent over the wire, and I definitely understand why this is better than sending a username and password directly.</p>
  
  <p>However, as I understand it, both the consumer and the provider must explicitly store both the consumer key and the shared secret (correct me if I'm wrong), and this seems like a major security risk.  If an attacker breached the provider's data store containing the consumer keys and shared secrets, every single API client would be compromised and the only way to re-secure the system would be to revoke <em>every single key</em>.  This is in contrast to passwords, which are (ideally) never stored in a reversible fashion on the server.  If you're salting and hashing your passwords, then an attacker would not be able to break into any accounts just by compromising your database.</p>
  
  <p>All the research I've done seems to just gloss over this problem by saying "secure the credentials as you would with any sensitive data", but that seems ridiculous.  Breaches do occur, and while they may expose sensitive data they shouldn't allow the attacker to <em>impersonate</em> the user, right?</p>