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?
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?
You're not missing much. I was a pretty active Twitter developer when Twitter implemented OAuth and then moved to require that all Twitter applications begin using it. Your concern is the same concern that was mentioned by a not-insignificant number of Twitter application developers. Twitter moved ahead with it anyway.
posted by DWRoelands at 6:21 AM on July 3, 2012
posted by DWRoelands at 6:21 AM on July 3, 2012
It might be helpful to think of Oauth's key and secret as alternatives to cookies, rather than alternatives to passwords. Oauth is replacing a status quo where the cookie is sent in the clear on every request, not one where passwords must be salted and hashed to remain secure. Twitter's move to Oauth replaced basic auth, where the user's complete login credentials were included in every request.
You still have to ensure that you're storing passwords securely to protect accounts, while the keys and secrets are stored in plaintext to protect individual requests.
posted by migurski at 6:31 AM on July 3, 2012 [1 favorite]
You still have to ensure that you're storing passwords securely to protect accounts, while the keys and secrets are stored in plaintext to protect individual requests.
posted by migurski at 6:31 AM on July 3, 2012 [1 favorite]
Blake's link has some great information.
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.
If the issue was between end users and service providers, you'd be exactly right. The problem was consumer sites that wanted to act on behalf of users with the service provider. For example, The Draw Free app wanting to access your Facebook data. Note that even with OAuth, you still have to authenticate yourself with the service provider, which in many cases is username/password over TLS. But with OAuth, you can allow Draw Free to have *limited* access to your facebook account, rather than the wide open access that would be allowed by giving Draw Free your Facebook username /password.
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)?
Let's assume a bad guy got their hands on these keys. What is it that they could do? They could authorize other sites access to a user's personal data ... except they don't have the user's personal data (and if they did, then there's a much bigger problem than OAuth security).
However, such a security breach would still be a problem, since the bad guys could try to get users to give them sensitive data by setting up a phishing scam to impersonate the service provider. So it is important to secure the OAuth keys, but access to the keys doesn't mean access to sensitive data.
posted by forforf at 7:24 AM on July 3, 2012
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.
If the issue was between end users and service providers, you'd be exactly right. The problem was consumer sites that wanted to act on behalf of users with the service provider. For example, The Draw Free app wanting to access your Facebook data. Note that even with OAuth, you still have to authenticate yourself with the service provider, which in many cases is username/password over TLS. But with OAuth, you can allow Draw Free to have *limited* access to your facebook account, rather than the wide open access that would be allowed by giving Draw Free your Facebook username /password.
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)?
Let's assume a bad guy got their hands on these keys. What is it that they could do? They could authorize other sites access to a user's personal data ... except they don't have the user's personal data (and if they did, then there's a much bigger problem than OAuth security).
However, such a security breach would still be a problem, since the bad guys could try to get users to give them sensitive data by setting up a phishing scam to impersonate the service provider. So it is important to secure the OAuth keys, but access to the keys doesn't mean access to sensitive data.
posted by forforf at 7:24 AM on July 3, 2012
« Older Scream if the power goes out... | Awkward coworker issue - is it any of my business... Newer »
This thread is closed to new comments.
posted by Blake at 5:44 AM on July 3, 2012 [1 favorite]