hotsh / rstat.us

Simple microblogging network based on the ostatus protocol.
http://rstat.us/
Other
722 stars 215 forks source link

Use basic auth to get an oauth token #694

Open carols10cents opened 11 years ago

carols10cents commented 11 years ago

From discussion in #692:

@steveklabnik:

One neat thing that we might want to think about in the future is echoing GitHub's authorization API: you can use basic auth to request an oauth token, so you don't have to go through the full oauth dance. :)

@wilkie:

You can use basic auth to acquire an application token. However, the reason this is secure is that the random handshaking oauth uses to ensure no replay attacks can occur is superseded by ssl. So, if you do this, ensure that you check that the credentials are correct AND that the request was made over ssl. This cannot be used on any nodes that elect not to have an ssl cert. :)

@steveklabnik:

Link for the uninformed: http://developer.github.com/v3/oauth/#non-web-application-flow

OAuth would also require ssl, and therefore shouldn't be on any nodes that elect not to have it.

@wilkie:

OAuth is equivalent basically to basic auth + ssl in terms of attack area. You attack the initial handshake for OAuth, or you attack the initial handshake for ssl, and you could see the information passed on subsequent requests. shrug If people elect not to have SSL, OAuth is severely better than nothing, and due to using a random number and an HMAC can be used without SSL. Pessimistically speaking, both approaches are rather broken on a security level, but do obscure passwords in the common case. Also, the government probably has every SSL private key. :) :) :C

@steveklabnik:

I'm pretty sure that the spec says to reject requests that aren't over SSL, and so it won't even work, not 'it's not secure.'

I should really double-check that, though.

@wilkie:

Yeah, totally. It will be insecure if the eavesdropper witnesses the handshake. SSL is broken if the eavesdropper can inject a cert or knows the private key. shrug :) But SSL would solve the problem of witnessing the key exchange at the OAuth layer by pushing the problem down a layer. It is theoretically impossible to solve the key exchange problem, so OAuth placed it out-of-scope and gives responsibility to SSL, which solves it poorly. :D :D :D

OAuth says that SSL MUST be used to get the token_secret, which makes sense, so you'd be correct that it should reject requests not over SSL regardless. Hmm, in that case, is OAuth nothing more than a glorified redirect? I now have newfound lulz over that spec.