You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shindig.apache.org by Chris Chabot <ch...@xs4all.nl> on 2008/04/13 13:20:13 UTC
Security tokens & crypto (was: OAuth broke socialdata interface)
One other thing, would it be possible to use a public / private key
pair for this, preferably something generated by openssl ?
I've heard of some people that they might be interested in a mix of
the java and php versions of shindig, where they would use the shindig
java server for rendering the gadgets through the RPC service, but
would like to use the php social data part so they can add their data
code there.
To be able to do that, they'd have to be able to continue to
understand each other and have exactly the same wire format, including
security tokens and encryption, using an [openssl or compatible] type
of encryption would guarantee both sides of the fence are able to
produce and consume the tokens seamlessly, well that would be the
ideal situation for me anyhow.
I've done a quick test, generating some keys and encrypting the token
with it, and the end result is a 128 byte long (binary) string,
urlencode it and you end up having security token weighing in at 324
bytes my this test case... So i have some doubts if we can pass that
through the url's without any problems? (i forgot what the arbitrary
length restriction imposed by various browsers is now-a-days, but i
know you can't put to much data on the url without some of them
truncating it at their leisure)
So I'm not a 100% sure yet about what the ideal, working solution
would be.. but it would be nice if the java and php versions
understood each other's tokens, and it would be nice as well if this
default implementation was cryptographically sound; Plus if the token
generation used a public/private key pair, it could well use the same
key's as the signing / oath code, which need to be generated anyhow
for anyone who will use shindig right?
The quick-test consisted out of:
# openssl genrsa -out private-key.pem 1024
# openssl req -new -key private-key.pem -x509 -days 365 -out public-
key.pem
en-decrypt.php:
#!/usr/bin/php -Cq
<?php
// encrypt token
$input = "john.doe:john.doe:appid:synd:url:0";
$fp=fopen ("private-key.pem", "r");
$priv_key=fread ($fp, 8192);
fclose($fp);
openssl_get_privatekey ($priv_key);
openssl_private_encrypt($input, $crypted, $priv_key);
echo "Crypted len: ".strlen($crypted).". urlencoded len:
".strlen(urlencode($crypted))."\n";
// decrypt again to validate operations
$fp = fopen("public-key.pem","r");
$pub_key = fread($fp,8192);
fclose($fp);
openssl_get_publickey ($pub_key);
openssl_public_decrypt ($crypted, $decrypted, $pub_key);
echo "decrypted: $decrypted\n";
?>
output:
Crypted len: 128. urlencoded len: 324
decrypted: john.doe:john.doe:appid:synd:url:0
On Apr 12, 2008, at 9:50 PM, Chris Chabot wrote:
> Well the problem I could see with this (the container creating 'some'
> security token), is that other parts of shindig (such as the
> socialdata
> part) will use the standard blob decrypter to decrypt it, and expect
> a valid
> array with viewer / owner / module id / app id / domain information
>
> So take the situation where someone is using the RPC service to
> create a
> iframe url, you would probably do this because your not writing java
> servlets right, but would rather use shindig as a 'black box'.
>
> In that scenario you would have no way to generate a security token
> that
> would work with the other parts of shindig (i.a.w. socialdata) , and
> you
> would be forced to write some java code anyhow ... which departs
> from the
> black box concept.
>
> Disclaimer 1: I'm just going by the current java code, where the
> gadget data
> servlet takes the st param, decrypts it using the basic blob crypter
> logic,
> and uses the owner and viewer data from it to generate the isViewer /
> isOwner and friend list information.
>
> Disclaimer 2: I'm assuming that the RPC service is still meant to
> allow
> shindig to be used in a 'black box' type scenario, where shindig
> creates
> your iframe url's, renders the gadgets and provides a gateway to an
> external
> social data source. Based on this assumption this scenario -should-
> work
> with a security token that is created, consumed and meaningful inside
> shindig.
>
> -- Chris
>
> -----Original Message-----
> From: Kevin Brown [mailto:etnu@google.com]
> Sent: Saturday, April 12, 2008 21:29
> To: shindig-dev@incubator.apache.org
> Subject: Re: OAuth broke socialdata interface
>
> Er -- one additional thing. If we *do* allow the metadata servlet to
> generate security tokens, we must then layer another protection
> mechanism on
> top of it. I honestly have no idea what would be appropriate here.
> Normally
> you'd use cookies, but that's not really viable here.
>
> With that in mind, having the consuming container generate the
> security
> tokens and attaching them to the metadata-produced iframes is
> probably still
> the best option.
>
> On Sat, Apr 12, 2008 at 12:26 PM, Kevin Brown <et...@google.com> wrote:
>
>> On Sat, Apr 12, 2008 at 3:11 AM, Chris Chabot <ch...@xs4all.nl>
>> wrote:
>>
>>> What i imagine should happen is that:
>>>
>>> 1) The PRC service (see RpcServlet and jsonRpcHandler, etc) which
>>> generates a iframe url, is modified to include the proper st=
>>> security
> token
>>> in that url. We should be able to tell the the rpc service who our
>>> viewer/owner/domain is, is this already in place? (haven't written
>>> that
> yet
>>> on the php side so my knowledge is lacking there)
>>
>>
>> I'm still not sure which way is the right way to go on this one.
>> Putting
>> this into the metadata handler would make sense (and the wiring is
>> mostly
>> there), but on the other hand I think it might be more natural for
>> the
>> metadata handler to return the "raw" url, and allow consumers of the
>> metadata handler to append the security token. This makes it much
>> easier
> to
>> isolate ownership of encryption keys.
>>
>> Of course, this makes using the metadata handlers directly from
>> client
>> side javascript (via XHR) harder. I wonder if many people will
>> actually be
>> using this in the "real world" though -- I certainly didn't build
>> it with
>> that in mind. I assumed most people would hit the metadata servlet
>> from
>> their existing site.
>>
>> I'm more than happy to support both if there's enough demand from
>> users.
>> We'd simply not generate st if the appropriate inputs are missing.
>>
>> 2) We rewrite the examples / sample container to use this RPC
>> service (see
>>> javascript/container and javascript/samplecontainer). We should be
>>> able
> to
>>> tell it the owner, viewer and module id, plus the domain (which we
>>> can
>>> easily retrieve in javascript in the examples). In the examples this
> would
>>> be john.doe x2, the incremental module id it generates, and the
>>> domain
> from
>>> the current document; But any container-to-be would just modify this
> code
>>> and put the (site) authenticated owner and viewer here instead,
>>> and be
> done
>>> with it :)
>>
>>
>> Agreed that this should be done (I could have sworn that I opened a
>> JIRA
>> ticket to do this).
>>
>>
>>> This way it should just work out of the box for anyone trying out
>>> the
>>> examples & sample container, and more importantly, if they use
>>> this as a
>>> basis of their own container they will actually have a somewhat
>>> working
> and
>>> secure setup that wouldn't allow their users to spoof identities and
> 'hack'
>>> the gadgets.
>>>
>>> My concern for this was inspired by some of the apache guys at the
>>> ApacheCon, who in our meet-up mentioned "With <this other project>
>>> we
> supply
>>> a basic example that people take and build upon and expand to make
>>> their
> own
>>> site", and i think that is how people will probably end up using
>>> shindig
> too
>>> in the long run. Right now it is a pretty 'controller' environment
>>> still
> and
>>> we can afford some basic assumptions about what people should and
>>> will
> do
>>> but that won't always be the case .. So it's probably worth it to
>>> create
> a
>>> valid enough 'sample' foundation that people can build upon for
>>> their
> own
>>> sites?
>>>
>>> -- Chris
>>>
>>>
>>> On Apr 11, 2008, at 8:25 PM, Brian Eaton wrote:
>>>
>>> On Fri, Apr 11, 2008 at 10:57 AM, Kevin Brown <et...@google.com>
>>> wrote:
>>>>
>>>>> more inputs would need to be provided.
>>>>> javascript/container/sample-metadata
>>>>> wires this up. There's an outstanding ticket to wire the metadata
>>>>> servlet up
>>>>> to the sample pages, but it hasn't happened yet.
>>>>>
>>>>
>>>> OK. I'm not confident I can do that in the way the Shindig team
>>>> would
>>>> like it done, so I'm not going to grab that ticket.
>>>>
>>>> Revised patch that should fix the immediate problem is attached.
>>>> <faketoken.patch>
>>>>
>>>
>>>
>>
>>
>> --
>> ~Kevin
>
>
>
>
> --
> ~Kevin
UserPref not working
Posted by Sanjay Shende <Sa...@symphonysv.com>.
Hi All,
I am unable to get the Preferences settings window. I have added
3-4 preferences using "UserPref" tag, but when I click on "Settings"
link, nothing is being displayed. Can someone let me know how to make
these preferences working, Because I need them urgently in my gadget. I
am using java version of Shindig.
Regards,
Sanjay
"This email and any files transmitted with it contain confidential, proprietary,
privileged information of Symphony Services Corp (India) Pvt. Ltd. and are intended
solely for the use of the recipient/s to whom it is addressed. Any unauthorized
notifying, copying or distributing of this e-mail, directly or indirectly, and the
contents therein in full or part is prohibited by any entity who is not a recipient.
Any email received inadvertently or by mistake should be deleted by the entity who
is not a recipient thereof. You may be pleased to notify the sender immediately by
email and the email should be deleted from your system".
Re: Security tokens & crypto (was: OAuth broke socialdata interface)
Posted by Chris Chabot <ch...@xs4all.nl>.
Thanks that explained a few things, i'll get right on this then :)
On Apr 13, 2008, at 7:02 PM, Brian Eaton wrote:
>
> +1. If you port the BlobCrypter code to PHP, we're most of the way
> there.
>
>
Re: Security tokens & crypto (was: OAuth broke socialdata interface)
Posted by Brian Eaton <be...@google.com>.
A few comments inline.
On Sun, Apr 13, 2008 at 4:20 AM, Chris Chabot <ch...@xs4all.nl> wrote:
> One other thing, would it be possible to use a public / private key pair for
> this, preferably something generated by openssl ?
Asymmetric might be useful for this, but bear in mind it is about
1000x slower than symmetric crypto. Unless you have a pressing reason
for wanting the gadget server to be able to verify tokens, but not
generate them, don't use public key.
If you do use public key, you probably want a mix of public and
symmetric key crypto. The first time the gadget server sees a public
key signed token, it should replace the public key key signature with
a symmetric version using a key known only to the gadget server. That
way subsequent uses of the same token can be verified quickly.
Also consider whether you want just integrity, or integrity +
confidentiality. (Should the gadget be able to peek at the gadget
security token and see exactly what's inside?) The BlobCrypter code
provides both.
> To be able to do that, they'd have to be able to continue to understand
> each other and have exactly the same wire format, including security tokens
> and encryption, using an [openssl or compatible] type of encryption would
> guarantee both sides of the fence are able to produce and consume the tokens
> seamlessly, well that would be the ideal situation for me anyhow.
+1. I wrote the BlobCrypter code using a very simple wire format
(x-www-form-urlencoded, pretty much) and common algorithms for exactly
this reason.
> I've done a quick test, generating some keys and encrypting the token with
> it, and the end result is a 128 byte long (binary) string, urlencode it and
> you end up having security token weighing in at 324 bytes my this test
> case...
Base64 encoding is much more efficent than URL encoding for binary
data. Overhead for BlobCrypter should be
+16 bytes for initial vector
+20 bytes for HMAC
+0-16 bytes for padding (uggh, might be wrong on that)
x1.33 for base64 encoding
> So I'm not a 100% sure yet about what the ideal, working solution would
> be.. but it would be nice if the java and php versions understood each
> other's tokens, and it would be nice as well if this default implementation
> was cryptographically sound;
+1. If you port the BlobCrypter code to PHP, we're most of the way there.
> Plus if the token generation used a
> public/private key pair, it could well use the same key's as the signing /
> oath code, which need to be generated anyhow for anyone who will use shindig
> right?
Reusing keys for different purposes tends to be a bad idea. We should
have distinct keys for signed fetch vs gadget security token because:
a) we will sign arbitrary messages with the signed fetch key. If
someone can make us sign a message that looks like a gadget security
token, they can replay the message as if it actually were a gadget
security token.
b) the signed fetch key can change very rarely. The gadget
security token key is free to change much more often because it is
only used within a single organization.
c) signed fetch will always be RSA signing. The gadget security
token can use any algorithm we please, to optimize for speed, or size,
or security, or all of the above.
Cheers,
Brian