+1 for this I too noticed that tokens are stored in pain text in db. Also tokens can be easily intercepted if using http..
Thanks. -- Supun Malinga Sent from my phone. On 30 Jul 2013 12:18, "Lalaji Sureshika" <[email protected]> wrote: > Hi, > > On Mon, Jul 29, 2013 at 11:31 PM, Rajeev Sampath <[email protected]> wrote: > >> Hi Prabath, >> >> In addition to these tokens, AM has application tokens which are handled >> in a separate path. Unlike access tokens, they need to decryptable to >> original format since they need to be shown in a UI to the user. >> > > Here what Rajeev mentioned is the generation and showing of > 'Application Access Tokens' from APIStore UI. If we are going to hash the > Application Tokens stored in database with each token generation time,then > there will be an issue on showing the *original* application access token > back from UI in each web page refresh time as we are directly querying the > token from database..So we may need to keep a two way encryption mechanism > for 'application access tokens'. > >> >> What would be the best way to handle application tokens in this case? Is >> it okay to use one way hashing for access/refresh tokens and a two way >> encryption algorithm here for application tokens? >> > > Thanks; > >> >> >> Thanks >> Rajeev >> >> >> On Fri, Jul 26, 2013 at 7:07 PM, Prabath Siriwardena <[email protected]>wrote: >> >>> AFAIK tokens are stored only in one place.. >>> >>> Thanks & regards, >>> -Prabath >>> >>> >>> On Fri, Jul 26, 2013 at 7:01 PM, Rajeev Sampath <[email protected]>wrote: >>> >>>> Hi Ratha, >>>> >>>> >>>> On Fri, Jul 26, 2013 at 6:32 PM, Vijayaratha Vijayasingam < >>>> [email protected]> wrote: >>>> >>>>> >>>>> >>>>> On 26 July 2013 17:50, Rajeev Sampath <[email protected]> wrote: >>>>> >>>>>> Hi Prabath, >>>>>> >>>>>> >>>>>> On Fri, Jul 26, 2013 at 3:35 PM, Prabath Siriwardena < >>>>>> [email protected]> wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> On Fri, Jul 26, 2013 at 3:24 PM, Prabath Siriwardena < >>>>>>> [email protected]> wrote: >>>>>>> >>>>>>>> There three aspects.. >>>>>>>> >>>>>>>> 1. Protect the confidentiality of the token at rest (in storage) >>>>>>>> 2. Protect the confidentiality of the token in transit. >>>>>>>> 3. Protect the confidentiality of the token from the client. >>>>>>>> >>>>>>>> [2] is achieved through TLS. >>>>>>>> >>>>>>>> [3] this is the one which mentioned in the spec. This is needed if >>>>>>>> we have to include certain information in to the token that should not >>>>>>>> be >>>>>>>> visible to the client. >>>>>>>> >>>>>>>> Doing [3] is very costly. What client gets there is an encrypted >>>>>>>> token. So - its the same encrypted token that it will send to access >>>>>>>> resources. So - for each request we need to decrypt it. >>>>>>>> >>>>>>>> Also the issue in [3] is - if you store the encrypted token in the >>>>>>>> database - somebody having access to the database - can take the >>>>>>>> encrypted >>>>>>>> token and use it to access the API (he does not need to decrypt it). >>>>>>>> >>>>>>>> What I would suggest is this. >>>>>>>> >>>>>>>> In the access token we issues we have some information parts and a >>>>>>>> secret part. >>>>>>>> >>>>>>>> Information part is something like domain name.. like wise. Secret >>>>>>>> part is the randomly generated string. >>>>>>>> >>>>>>>> Access Token = INFORMATION_PART + SECRET_KEY >>>>>>>> >>>>>>>> This is what I suggest.. >>>>>>>> >>>>>>>> Access Token = Base64Encode(INFORMATION_PART + ":" + SECRET_KEY) >>>>>>>> >>>>>>>> Client will get the Access Token and we store *Hash(SECRET_KEY)*in the >>>>>>>> database (no encryption) >>>>>>>> >>>>>>> >>>>>>> >>>>>>> Correction --> we store *Hash(Access Token)* >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> Now - when accessing the API client will send the Access Token >>>>>>>> >>>>>>>> Decoded Access Token = Base64Decode(Access Token) >>>>>>>> = INFORMATION_PART + ":" + >>>>>>>> SECRET_KEY >>>>>>>> >>>>>>>> Now to validate the token we check, *Hash(SECRET_KEY{from >>>>>>>> request}) = **Hashed Secret Key from database* >>>>>>>> >>>>>>> >>>>>>> Correction --> *Hash(Access Token{from request}) = **Hashed Access >>>>>>> Token from database* >>>>>>> * >>>>>>> * >>>>>>> >>>>>> >>>>>> In addition to these at IS level, access tokens are stored in AM as >>>>>> well. So IMO for those, we'll have to use a symmetric algorithm that can >>>>>> also decrypt and get the original key from an encrypted key. >>>>>> >>>>>> >>>>> Why do we need decryption if we use hashing? And where will we need >>>>> the original key, if we issue the encoded token to client? >>>>> >>>>> >>>>>> >>>>>> >>>> My concern was on a scenario where AM having to use a stored token in >>>> non hashed form (such as sending it to OAuth). In that case, OAuth will be >>>> expecting an encoded but not hashed key (which I referred to as original >>>> key here). So if the keys can't be converted back to the original state at >>>> AM level won't that be a problem? >>>> Or else won't there be such scenarios? >>>> >>>> >>>> Thanks >>>> Rajeev >>>> >>>> >>>> >>>>> Thanks >>>>>> Rajeev >>>>>> >>>>>> >>>>>> >>>>>>> ** >>>>>>> Thanks & regards, >>>>>>> -Prabath >>>>>>> * >>>>>>> * >>>>>>> >>>>>>>> >>>>>>>> This way we do not want to worry about encryption - and we also do >>>>>>>> not store access token in clear text in the database. >>>>>>>> >>>>>>>> Refresh token can be just stored as a hash. >>>>>>>> >>>>>>>> Thanks & regards, >>>>>>>> -Prabath >>>>>>>> >>>>>>>> On Fri, Jul 26, 2013 at 2:59 PM, Sumedha Rubasinghe < >>>>>>>> [email protected]> wrote: >>>>>>>> >>>>>>>>> We need to attend to $subject. >>>>>>>>> >>>>>>>>> OAuth2 spec also recommends this in it's Threat Mitigation section. >>>>>>>>> >>>>>>>>> >>>>>>>>> http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-16#section-4.2 >>>>>>>>> "For those cases where the client is prevented from observing the >>>>>>>>> contents of the token, token encryption MUST be applied in addition >>>>>>>>> to the >>>>>>>>> usage of TLS protection." >>>>>>>>> >>>>>>>>> Some design considerations. >>>>>>>>> 1. Should be configurable (default off), configured via >>>>>>>>> identity.xml >>>>>>>>> 2. Need to consider token validation flow as well (hash should be >>>>>>>>> generated of incoming token & compared) >>>>>>>>> 3. Should we also store encrypting algorithm as well? (for >>>>>>>>> backward compatibility if it changes after sometime) - Is this a real >>>>>>>>> scenario? >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> /sumedha >>>>>>>>> b : bit.ly/sumedha >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Thanks & Regards, >>>>>>>> Prabath >>>>>>>> >>>>>>>> Mobile : +94 71 809 6732 >>>>>>>> >>>>>>>> http://blog.facilelogin.com >>>>>>>> http://RampartFAQ.com >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Thanks & Regards, >>>>>>> Prabath >>>>>>> >>>>>>> Mobile : +94 71 809 6732 >>>>>>> >>>>>>> http://blog.facilelogin.com >>>>>>> http://RampartFAQ.com >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Rajeev Sampath >>>>>> Senior Software Engineer >>>>>> WSO2, Inc.; http://www.wso2.com. >>>>>> >>>>>> Mobile:* +94716265766 >>>>>> * >>>>>> >>>>>> _______________________________________________ >>>>>> Architecture mailing list >>>>>> [email protected] >>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> -Ratha >>>>> mobile: (+94)755906608 >>>>> >>>>> _______________________________________________ >>>>> Architecture mailing list >>>>> [email protected] >>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>> >>>>> >>>> >>>> >>>> -- >>>> Rajeev Sampath >>>> Senior Software Engineer >>>> WSO2, Inc.; http://www.wso2.com. >>>> >>>> Mobile:* +94716265766 >>>> * >>>> >>> >>> >>> >>> -- >>> Thanks & Regards, >>> Prabath >>> >>> Mobile : +94 71 809 6732 >>> >>> http://blog.facilelogin.com >>> http://RampartFAQ.com >>> >> >> >> >> -- >> Rajeev Sampath >> Senior Software Engineer >> WSO2, Inc.; http://www.wso2.com. >> >> Mobile:* +94716265766 >> * >> > > > > -- > Lalaji Sureshika > WSO2, Inc.; http://wso2.com/ > email: [email protected]; cell: +94 71 608 6811 > blog: http://lalajisureshika.blogspot.com > > > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > >
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
