[security-dev] input on bearer tokens and cookies

[Anil Saldhana]

On 12/12/2012 05:31 PM, Bill Burke wrote:
> Anil.............I know WTF PKI and symetric keys are......
Bill, the links on sym and pki were for others. Not you. :) Remember 
there are others who are reading
the emails silently without answering. ;)
>
> My question was, why would a browser Javascript app need to use private
> keys?  Do we have a specific protocol in mind?  OAuth2 has a jsonp
> mechanism to obtain access tokens that doesn't require PKI.  Regular
> Java EE web-apps can use standard servlet mechanisms.  Access tokens
> could also be stored in a dynamic script that is accessible after
> standard web logins.
My question to Bruno was for JSON Encryption alone and not OAuth. To 
counter limitations of JS apps
in doing PKI, OAuth has been suggested as an alternative.

My question is mainly for the following usecase:
JS app (such as JQuery app) makes ajax calls to a REST server and wants 
to secure the payload (message level security) and uses JSON as the
message structure.  It will need a Private Key at the client side to do 
JSON Encryption (JWE) unless there is the first step of syncing the app  
to download the secret encryption
key from the server, for subsequent communication.

Maybe this use case is bogus.  I am just thinking aloud.

>
> On 12/12/2012 6:23 PM, Anil Saldhana wrote:
>> https://github.com/picketbox/picketbox/blob/master/json/src/test/java/org/picketbox/test/json/JSONWebEncryptionTestCase.java
>>
>> When encryption is involved, you use a symmetric key (such as AES) to
>> encrypt/decrypt data.  But to transport the encrypted data between two
>> endpoints, you use PKI (Public/Private keys) such as RSA 15.  This is
>> key exchange. [http://en.wikipedia.org/wiki/Public-key_cryptography]
>>
>> It is done in XML Encryption also.
>>
>> So if JS app is dealing with a server and uses JSON as the message
>> structure. If it uses encryption, then either ends have to use PKI to
>> protect the secret key.  Just sending secret key over SSL may not be
>> sufficient for users.
>>
>>
>> On 12/12/2012 05:15 PM, Bill Burke wrote:
>>> Are you sure javascript appliations should store private keys?
>>> Where/why would you need private keys in browser javascript apps?
>>>
>>> On 12/12/2012 5:47 PM, Anil Saldhana wrote:
>>>> Bruno - I have been thinking of the possible ways by which Private Keys
>>>> are stored securely by the JavaScript applications for use in JSON
>>>> Encryption (for example).
>>>>
>>>> Do you know how JS libraries such as DOMCrypt and Crypto.js  deal with
>>>> storage of private keys?
>>>>
>>>> On 12/12/2012 08:30 AM, Bruno Oliveira wrote:
>>>>> Sorry Anil, but on HTML5 local storage is not an option, because can be easily hacked. Maybe session storage, but on AeroGear we don't have plans to store sensitive date on local storage.
>>>>>
>>>>> I'd rather to go with Bill's approach.
>>>>>
>>>>>
>>>>> -- "The measure of a man is what he does with power" - Plato -
>>>>> @abstractj - Volenti Nihil Difficile On Tuesday, December 11, 2012 at
>>>>> 5:33 PM, Anil Saldhana wrote:
>>>>>>> The cookies may be the easiest for you. An option with HTML5 is
>>>>>>> the localstorage. In this case, the JS calls from the browser have
>>>>>>> to save/restore the token that identifies session token/bearer token
>>>>>>> and send it as part of the call.
>>>>>>>
>>>>>>> On 12/11/2012 11:16 AM, Bill Burke wrote:
>>>>>>>>> I'm looking for some input.
>>>>>>>>>
>>>>>>>>> For the OAuth SSO protocol I'm working on, I'm thinking of storing the
>>>>>>>>> bearer token within a "secure" cookie and verifying the bearer token
>>>>>>>>> each HTTP request (for browser-based apps only). The upside to this is
>>>>>>>>> that you can establish a stateless SSO between a set of load-balanced
>>>>>>>>> servers. Downside is it takes about 1-2ms on my box to both parse and
>>>>>>>>> verify the cookie. TO much overhead? Should I store the unmarshaled
>>>>>>>>> token in the HTTP session instead?
>>>>>>>>>
>>>>>>>>> Any other thoughts on bearer tokens stored in cookies?
>>>>>>>>>
>>>>>>>>> Thanks
>>>>>>>>>
>>>>>>>>> Bill
>>>>>>> _______________________________________________
>>>>>>> security-dev mailing list
>>>>>>> security-dev at lists.jboss.org  (mailto:security-dev at lists.jboss.org)
>>>>>>> https://lists.jboss.org/mailman/listinfo/security-dev
>>>>
>>>> _______________________________________________
>>>> security-dev mailing list
>>>> security-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/security-dev
>>>>
>> _______________________________________________
>> security-dev mailing list
>> security-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/security-dev
>>