Securely storing OAuth credentials as a provider?
July 3, 2012 4:56 AM Subscribe
How do you securely store OAuth credentials as a provider? (1.0a, 2-legged)
Am I correct in my understanding of 2-legged authentication using OAuth 1.0a? Each consumer gets a key and a shared secret. When it makes a request, it sends the key and signs the message using the secret, but doesn't actually send the secret with the request. Great, I see the advantage of that.
The server then checks the signature using its own copy of the shared secret associated with that consumer, and that's where I get tripped up. Doesn't that mean the server has to store all the consumer keys and secrets in plaintext (or in a way that can be converted to plaintext)? This seems like a huge security problem; if the server has a security breach, every single client is compromised, and the only way to recover is to revoke each one's credentials (which means every client has to be updated with the new ones, no small feat for something like an iOS application). This seems a lot worse than usernames/passwords, where attackers can't really do anything useful with the credential data as long as you're properly salting and hashing the passwords. Yes, there's the disadvantage that username/password authentication requires the full credentials to be sent over the wire, but that's not such a big deal as long as you're using HTTPS or other TLS.
So many of the Big Guys are using OAuth that I feel like I must be missing something obvious here. Most of my research has come up with handwavy advice like "be sure to secure your credential store as you would any sensitive data", but that can't be right, right? Breaches do happen, whether it's the database server being physically compromised or just an unscrupulous sysadmin with the production DB login.
Can anyone tell me what I'm missing?