[security-dev] input on bearer tokens and cookies

[Bill Burke]

Anil.............I know WTF PKI and symetric keys are......

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.

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
>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com