Hello list, I am testing a mobile app, and I need some advice regarding a token used for authentication.... In a previous version of the application, there was a HTTP header called Authentication-Token like: Authentication-Token: 3300009516 where the numerical version was the userid. The application stores this token locally, and it`s generated the first time user connects with an OTP password and a PIN. Next time when the user logs in, will enter only the PIN, withouth OTP Now, in a more secure approach, the developpers changed the userid with a token, like: Authentication-Token: OKQCEYCPKCCBL61LGO18T2QFCMO3MWA0 I have captured some token values for the userid 3300009516 9UV0FTRB108O6Z2FE0I8XOU62Q730ATT 1FQBPBK2NZTIYXCH06QC3Z503AH9AELP OKQCEYCPKCCBL61LGO18T2QFCMO3MWA0 59JT53DBRDV0HVE9T9NBXUYG6K29HCFP What is interesting is that these tokens can be reused, so the algorithm should be reversible (not hashing), to a static value (like userid: 3300009516). My questions is: do you have any ideas if/how this tokens can be broken? Like computing new ones :) Thanks, Teo

> What is interesting is that these tokens can be reused, so the algorithm should be reversible (not hashing), to a static value (like userid: 3300009516). Don't know why you think this. For instance, the token could be created by any algorithm, including hash, and saved into a temp table for a certain time, which allows reuse only during its life time. But when you are testing the app for them, why do you not just ask the devs about their code? Than you can make a code review, which is always better than black box testing. Frank Heyne

******************************** I have captured some token values for the userid 3300009516* * * *9UV0FTRB108O6Z2FE0I8XOU62Q730A**TT* *1FQBPBK2NZTIYXCH06QC3Z503AH9AE**LP* *OKQCEYCPKCCBL61LGO18T2QFCMO3MW**A0* *59JT53DBRDV0HVE9T9NBXUYG6K29HC**FP* * * *What is interesting is that these tokens can be reused, so the algorithm should be reversible (not hashing), to a static value (like userid: 3300009516). * * ******************************** I agree with Frank, all the values are of same length (32), most probably MD5 Hash. *Reason for re-usability:* The hashes might be getting saved in the database and application is not programmed to delete the used hashes from the table. -- .. Regards, Praful Agawral Information Security Consultant Sandrock eSecurities Pvt. Ltd. New Delhi, India *Mobile:* +91-98185-59358 *Skype: praful.agarwal8** Gmail: praful.aga@gmail.com Hotmail: praful.agarwal@hotmail.com Linked In: **in.linkedin.com/in/prafulagarwal Facebook: facebook.com/praful.agarwal** *

Well, that`s what we agreed, black box testing.... I can bet they are not saving all the hashes/tokens serverside, because I have generated many of them and all work in couple of days, no programer (imho) will save hundreds of tokens wich simultaneously work for a user, but of course there is a possibility that I am wrong.... and my second reason for this is that they have previously used the userid as a token (!!!), and now I think they are somehow tokenizing it.... On Fri, Nov 23, 2012 at 1:25 PM, Praful Agarwal <praful.agarwal@sandrock.in>wrote: > ******************************** > > I have captured some token values for the userid 3300009516 > * > * > * > *9UV0FTRB108O6Z2FE0I8XOU62Q730A**TT* > *1FQBPBK2NZTIYXCH06QC3Z503AH9AE**LP* > *OKQCEYCPKCCBL61LGO18T2QFCMO3MW**A0* > *59JT53DBRDV0HVE9T9NBXUYG6K29HC**FP* > * > * > *What is interesting is that these tokens can be reused, so the algorithm > should be reversible (not hashing), to a static value (like > userid: 3300009516). > * > * > ******************************** > > I agree with Frank, all the values are of same length (32), most probably > MD5 Hash. > > *Reason for re-usability:* The hashes might be getting saved in the > database and application is not programmed to delete the used hashes from > the table. > > -- > .. > Regards, > Praful Agawral > Information Security Consultant > Sandrock eSecurities Pvt. Ltd. > New Delhi, India > > *Mobile:* +91-98185-59358 > *Skype: praful.agarwal8** > Gmail: praful.aga@gmail.com > Hotmail: praful.agarwal@hotmail.com > Linked In: **in.linkedin.com/in/prafulagarwal > Facebook: facebook.com/praful.agarwal** > * > > _______________________________________________ > The Web Security Mailing List > > WebSecurity RSS Feed > http://www.webappsec.org/rss/websecurity.rss > > Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA > > WASC on Twitter > http://twitter.com/wascupdates > > websecurity@lists.webappsec.org > http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org > >

Sure Teo. Probably talking to the programmer will give a good insight to the situation. Regards, Praful Agarwal On Fri, Nov 23, 2012 at 5:40 PM, Teodor Lupan <theologu@gmail.com> wrote: > Well, that`s what we agreed, black box testing.... > I can bet they are not saving all the hashes/tokens serverside, because I > have generated many of them and all work in couple of days, no programer > (imho) will save hundreds of tokens wich simultaneously work for a user, > but of course there is a possibility that I am wrong.... and my second > reason for this is that they have previously used the userid as a token > (!!!), and now I think they are somehow tokenizing it.... > > On Fri, Nov 23, 2012 at 1:25 PM, Praful Agarwal < > praful.agarwal@sandrock.in> wrote: > >> ******************************** >> >> I have captured some token values for the userid 3300009516 >> * >> * >> * >> *9UV0FTRB108O6Z2FE0I8XOU62Q730A**TT* >> *1FQBPBK2NZTIYXCH06QC3Z503AH9AE**LP* >> *OKQCEYCPKCCBL61LGO18T2QFCMO3MW**A0* >> *59JT53DBRDV0HVE9T9NBXUYG6K29HC**FP* >> * >> * >> *What is interesting is that these tokens can be reused, so the >> algorithm should be reversible (not hashing), to a static value (like >> userid: 3300009516). >> * >> * >> ******************************** >> >> I agree with Frank, all the values are of same length (32), most probably >> MD5 Hash. >> >> *Reason for re-usability:* The hashes might be getting saved in the >> database and application is not programmed to delete the used hashes from >> the table. >> >> -- >> .. >> Regards, >> Praful Agawral >> Information Security Consultant >> Sandrock eSecurities Pvt. Ltd. >> New Delhi, India >> >> *Mobile:* +91-98185-59358 >> *Skype: praful.agarwal8** >> Gmail: praful.aga@gmail.com >> Hotmail: praful.agarwal@hotmail.com >> Linked In: **in.linkedin.com/in/prafulagarwal >> Facebook: facebook.com/praful.agarwal** >> * >> >> _______________________________________________ >> The Web Security Mailing List >> >> WebSecurity RSS Feed >> http://www.webappsec.org/rss/websecurity.rss >> >> Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA >> >> WASC on Twitter >> http://twitter.com/wascupdates >> >> websecurity@lists.webappsec.org >> >> http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org >> >>

Thanks guys for your thougts! On Fri, Nov 23, 2012 at 2:40 PM, Praful Agarwal <praful.agarwal@sandrock.in>wrote: > Sure Teo. > > Probably talking to the programmer will give a good insight to the > situation. > > Regards, > Praful Agarwal > > On Fri, Nov 23, 2012 at 5:40 PM, Teodor Lupan <theologu@gmail.com> wrote: > >> Well, that`s what we agreed, black box testing.... >> I can bet they are not saving all the hashes/tokens serverside, because I >> have generated many of them and all work in couple of days, no programer >> (imho) will save hundreds of tokens wich simultaneously work for a user, >> but of course there is a possibility that I am wrong.... and my second >> reason for this is that they have previously used the userid as a token >> (!!!), and now I think they are somehow tokenizing it.... >> >> On Fri, Nov 23, 2012 at 1:25 PM, Praful Agarwal < >> praful.agarwal@sandrock.in> wrote: >> >>> ******************************** >>> >>> I have captured some token values for the userid 3300009516 >>> * >>> * >>> * >>> *9UV0FTRB108O6Z2FE0I8XOU62Q730A**TT* >>> *1FQBPBK2NZTIYXCH06QC3Z503AH9AE**LP* >>> *OKQCEYCPKCCBL61LGO18T2QFCMO3MW**A0* >>> *59JT53DBRDV0HVE9T9NBXUYG6K29HC**FP* >>> * >>> * >>> *What is interesting is that these tokens can be reused, so the >>> algorithm should be reversible (not hashing), to a static value (like >>> userid: 3300009516). >>> * >>> * >>> ******************************** >>> >>> I agree with Frank, all the values are of same length (32), most >>> probably MD5 Hash. >>> >>> *Reason for re-usability:* The hashes might be getting saved in the >>> database and application is not programmed to delete the used hashes from >>> the table. >>> >>> -- >>> .. >>> Regards, >>> Praful Agawral >>> Information Security Consultant >>> Sandrock eSecurities Pvt. Ltd. >>> New Delhi, India >>> >>> *Mobile:* +91-98185-59358 >>> *Skype: praful.agarwal8** >>> Gmail: praful.aga@gmail.com >>> Hotmail: praful.agarwal@hotmail.com >>> Linked In: **in.linkedin.com/in/prafulagarwal >>> Facebook: facebook.com/praful.agarwal** >>> * >>> >>> _______________________________________________ >>> The Web Security Mailing List >>> >>> WebSecurity RSS Feed >>> http://www.webappsec.org/rss/websecurity.rss >>> >>> Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA >>> >>> WASC on Twitter >>> http://twitter.com/wascupdates >>> >>> websecurity@lists.webappsec.org >>> >>> http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org >>> >>>