3 ms·

I am the second responder in that thread. I personally saw an oAuth bearer token for a user of Fitbit. It was there clear as day. Maybe I saw the only one tha

I am the second responder in that thread. I personally saw an oAuth bearer token for a user of Fitbit. It was there clear as day. Maybe I saw the only one that leaked, but that seems...unlikely.

dunham 10y ago
OAuth2 does indeed send a secret bearer as an "Authorization: Bearer" header, but OAuth1 does not. The FitBit stuff I recall seeing other day was OAuth1. It would look like oauth_token=XXX and oauth_consumer_key=YYY, along with oauth_signature=ZZZ. If that's what you're seeing, it's not a bearer token and that data isn't secret. Those values are essentially record locators. OAuth1 has an undisclosed "consumer secret" (embedded in the app) and "token secret" (acquired at login) that are used to sign the request. So these requests don't leak any usable tokens. If you also see oauth_nonce and oauth_timestamp values, then the signature is also protected from a replay attack. The response body of the request that originally acquired the token/secret would leak these secrets. I'm sure there are bearer tokens out there for other services, but if fitbit is using OAuth1, you'd have to snag that original token acquisition to call the api as that user. Edit - I hope this doesn't come off as argumentative. I just want to point out the good design choices made by the guys that weren't actually compromised by this. OAuth2 is really easy to implement, but it kinda feels like a step backwards security-wise.
- PuffinBlue 10y ago
  > The FitBit stuff I recall seeing other day was OAuth1. Fitbit uses oAuth 2 https://dev.fitbit.com/docs/oauth2/ https://dev.fitbit.com/docs/oauth2/
- lightedman 10y ago
  "OAuth2 is really easy to implement, but it kinda feels like a step backwards security-wise." No, no it isn't. There are about three proper ways to implement it. Almost nobody whose site I've come across that uses OAuth2 has it properly implemented. Token revocation and authentication is hard, folks.

I am the second responder in that thread. I personally saw an oAuth bearer token for a user of Fitbit. It was there clear as day. Maybe I saw the only one that leaked, but that seems...unlikely.

dunham 10y ago

OAuth2 does indeed send a secret bearer as an "Authorization: Bearer" header, but OAuth1 does not. The FitBit stuff I recall seeing other day was OAuth1. It would look like oauth_token=XXX and oauth_consumer_key=YYY, along with oauth_signature=ZZZ. If that's what you're seeing, it's not a bearer token and that data isn't secret. Those values are essentially record locators. OAuth1 has an undisclosed "consumer secret" (embedded in the app) and "token secret" (acquired at login) that are used to sign the request. So these requests don't leak any usable tokens. If you also see oauth_nonce and oauth_timestamp values, then the signature is also protected from a replay attack. The response body of the request that originally acquired the token/secret would leak these secrets. I'm sure there are bearer tokens out there for other services, but if fitbit is using OAuth1, you'd have to snag that original token acquisition to call the api as that user. Edit - I hope this doesn't come off as argumentative. I just want to point out the good design choices made by the guys that weren't actually compromised by this. OAuth2 is really easy to implement, but it kinda feels like a step backwards security-wise.

PuffinBlue 10y ago
> The FitBit stuff I recall seeing other day was OAuth1. Fitbit uses oAuth 2 https://dev.fitbit.com/docs/oauth2/ https://dev.fitbit.com/docs/oauth2/
lightedman 10y ago
"OAuth2 is really easy to implement, but it kinda feels like a step backwards security-wise." No, no it isn't. There are about three proper ways to implement it. Almost nobody whose site I've come across that uses OAuth2 has it properly implemented. Token revocation and authentication is hard, folks.