Keeping the secret safe

Post date: Oct 21, 2011 5:36:32 AM

This is the problem I've had all along with understanding OAuth and OpenID and even Amazon EC2 or whatever all those S2.amazon.com.blahblah files that are everywhere. This is a good, quite old post with follow-on that addresses these issues.

Via OAuth Signature Methods from gnegg.ch, October 2008.

"In the end, HMAC-SHA1 is just repeating history. At first, we stored passwords in the clear, then we've learned to hash them, then we even salted them and now we're exchanging them for tokens stored in the clear. No. What I need is something that keeps the secret on the client. The secret should never ever need to be transmitted to the server. The server should have no knowledge at all of the secret. Thankfully, OAuth contains a solution for this problem: RSA-SHA1 as defined in section 9.3 of the specification. Unfortunately, it leaves a lot to be desired though. Whereas the rest of the specification is a pleasure to read and very, well, specific, 9.3 contains the following phrase:

It is assumed that the Consumer has provided its RSA public key in a verified way to the Service Provider, in a manner which is beyond the scope of this specification.

Just specify the (IMHO) useless way using shared secrets and leave out the interesting and IMHO only functional method. Sure. Transmitting a Public Key is a piece of cake (it's public after all), but this puts another burden on the writer of the provider documentation and as it's unspecified, implementors will be forced to amend the existing libraries with custom code to transmit the key.

“safe” place? For this to work, the server must be able to decrypt the store and thus, needs the key readily available – unless you want someone typing the key in manually every time it needs to be decrypted :p And if it’s available for the server, it’s available for the malware that compromised the machine. And once that key store is accessible, all accounts are compromised and you (as a service provider) would never notice:

"... but like all other OAuth-RSA-implementations it assumes the public key to be on the server for it to work. So this still leaves the problem of how the public key gets there. In my case, it’ll be a simple web-form: The user logs in using username and password and pastes the public key into a text area. Transmitting the public key programmatically in a secure way without ever using the password is very hard and an interesting problem, which is probably why it wasn’t specified in the OAuth spec ..."

Here is the OAuth for php spec on Google Code. No getting around SSL apparently.

Then there's this, just to step through and back again for PHP encrypt-decrypt PHP Encrypt and decrypt data with RSA public keys. And a recently updated Using Secure DNS to Associate Certificates with Domain Names For TLS from IETF.

I'm still so confused....

DEFCON19 (2011) Secrets

For further details and hints, see 1o57 on WikiSpaces dot com:

"You've come to the page dedicated to the Badge related puzzle from Defcon 19. The puzzles were created by Ryan "1o57" Clark, creator of the Defcon Mystery Challenge. Here you will find all the information gathered with respect to the badge puzzles from the weekend."

Get additional insights from the Hints From Lost Page if l057 WikiSpaces.com is inadequate.