[mitreid-connect] Storage of Tokens in DB [I]

[Justin Richer]

It’s all possible, but it isn’t something we’ve put a lot of effort into. Why not? Well if the DB tables are stolen, you’ve got some serious issues anyway. Unlike user passwords, where hashing and salting are a very good idea indeed, these are all randomly generated high entropy values that are designed to be rotated relatively easily. Getting a user to pick and use a new password is a huge friction point. Getting a client to configure a new secret or get a new token is almost assumed by the protocols.

Tokens don’t really need to be stored as-is, though it’s simpler that way to do the lookup. And the truth is that if your database is stolen, you’d want to rotate everything anyway even if it’s hashed, for the simple reason that someone got their hands on your DB and you shouldn’t trust that it wasn’t manipulated. The good news here is that because it’s not user passwords, those secrets won’t be usable outside of your AS.

Furthermore, some operations do need the client secret available in its original unhashed form. Namely: dynamic client configuration management (unless you want to rotate the secret on every read/update), and the client_secret_jwt authentication methods and HS* token signing mechanisms. All of those need the client secret as-is to function and won’t work on a hashed value.

 — Justin

> On Dec 13, 2016, at 6:54 AM, Chris Hutton <chris.hutton at callsign.com> wrote:
> 
> Yes,  from your link
> 
> "It sounds like we are generating the client's secret, and that needs to be passed on to the client after it is generated (and this is the ONLY time we need the plaintext). If so, then would it work to just notify the client about the secret (using some secure means) after it's generated, but before it is stored & encoded?"
> 
> Seems to confirm the investigation I was doing.
> 
> Dominik Schmich wrote:
>> Classification: For internal use only
>> 
>> Ahh, got it J
>> 
>> I guess it can be related to https://github.com/mitreid-connect/OpenID-Connect-Java-Spring-Server/issues/55 <https://github.com/mitreid-connect/OpenID-Connect-Java-Spring-Server/issues/55> aswell.
>> 
>> Beste Grüße / Kind regards,
>> Dominik Schmich
>> 
>>  <>From: Chris Hutton [mailto:chris.hutton at callsign.com <mailto:chris.hutton at callsign.com>]
>> Sent: Dienstag, 13. Dezember 2016 12:17
>> To: Dominik Schmich <dominik.schmich at db.com> <mailto:dominik.schmich at db.com>
>> Cc: jricher at mit.edu <mailto:jricher at mit.edu>; mitreid-connect at mit.edu <mailto:mitreid-connect at mit.edu>
>> Subject: Re: [mitreid-connect] Storage of Tokens in DB [I]
>> 
>> Hi Dominik,
>> 
>> It was more of a theoretical solution rather than a branch on GitHub. We have implemented our own OAuth2TokenRepository and this seems to be one level higher up the code calling stack
>> 
>> Dominik Schmich wrote:
>> 
>> Classification: For internal use only
>> 
>> Hi Chris,
>> 
>> can you point me to „your proposed solution“? I didn’t find it J
>> 
>> Beste Grüße / Kind regards,
>> Dominik Schmich
>> 
>> From: Chris Hutton [mailto:chris.hutton at callsign.com <mailto:chris.hutton at callsign.com>]
>> Sent: Dienstag, 13. Dezember 2016 12:04
>> To: Dominik Schmich <dominik.schmich at db.com> <mailto:dominik.schmich at db.com>
>> Cc: jricher at mit.edu <mailto:jricher at mit.edu>; mitreid-connect at mit.edu <mailto:mitreid-connect at mit.edu>
>> Subject: Re: [mitreid-connect] Storage of Tokens in DB [I]
>> 
>> It seems that you could can pass a JTI or hashed value into the DefaultOAuth2ProviderTokenService (OAuth2TokenEntityService) before it calls the JpaOAuth2TokenRepository (OAuth2TokenRepository).
>> 
>> There are a couple of methods to watch out for:
>> - OAuth2TokenRepository#getAccessTokenByValue
>> - OAuth2TokenRepository#getRefreshTokenByValue
>> With both these methods in my proposed solution, the parameter would become the hashed value or JTI.
>> 
>> There are a number of methods in the /tokens api that expose the token object for example TokenAPI#getAccessTokenById using m.put(JsonEntityView.ENTITY, token); however I don't think external API clients use the token value.
>> 
>> --
>> Chris Hutton
>> Head of Development
>> Callsign Inc.
>> [C] chris <https://get.callsign.com/chris>
>> 
>> 
>> --------------------------------------------------------------- This message
>> was pgp signed but couldn't be verified successfully. Typically this is caused
>> because Deutsche Bank hasn't yet trusted the PGP key of the sender.
>> 
>> 
>> ---
>> Die Europäische Kommission hat unter http://ec.europa.eu/consumers/odr/ <http://ec.europa.eu/consumers/odr/> eine Europäische Online-Streitbeilegungsplattform (OS-Plattform) errichtet. Die OS-Plattform kann ein Verbraucher für die außergerichtliche Beilegung einer Streitigkeit aus Online-Verträgen mit einem in der EU niedergelassenen Unternehmen nutzen.
>> 
>> Informationen (einschließlich Pflichtangaben) zu einzelnen, innerhalb der EU tätigen Gesellschaften und Zweigniederlassungen des Konzerns Deutsche Bank finden Sie unter https://www.deutsche-bank.de/Pflichtangaben <https://www.deutsche-bank.de/Pflichtangaben>. Diese E-Mail enthält vertrauliche und/ oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese E-Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser E-Mail ist nicht gestattet.
>> 
>> The European Commission has established a European online dispute resolution platform (OS platform) underhttp://ec.europa.eu/consumers/odr/ <http://ec.europa.eu/consumers/odr/>. The OS platform can be used by a consumer for the extra-judicial settlement of a dispute of online contracts with a provider established in the EU companies.
>> 
>> Please refer to https://www.db.com/disclosures <https://www.db.com/disclosures> for information (including mandatory corporate particulars) on selected Deutsche Bank branches and group companies registered or incorporated in the European Union. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.
>> 
>> --
>> Chris Hutton
>> Head of Development
>> Callsign Inc.
>> [C] chris <https://get.callsign.com/chris>
>> 
>> 
>> --------------------------------------------------------------- This message
>> was pgp signed but couldn't be verified successfully. Typically this is caused
>> because Deutsche Bank hasn't yet trusted the PGP key of the sender.
>> 
>> 
>> ---
>> Die Europäische Kommission hat unter http://ec.europa.eu/consumers/odr/ <http://ec.europa.eu/consumers/odr/> eine Europäische Online-Streitbeilegungsplattform (OS-Plattform) errichtet. Die OS-Plattform kann ein Verbraucher für die außergerichtliche Beilegung einer Streitigkeit aus Online-Verträgen mit einem in der EU niedergelassenen Unternehmen nutzen.
>> 
>> Informationen (einschließlich Pflichtangaben) zu einzelnen, innerhalb der EU tätigen Gesellschaften und Zweigniederlassungen des Konzerns Deutsche Bank finden Sie unter https://www.deutsche-bank.de/Pflichtangaben <https://www.deutsche-bank.de/Pflichtangaben>. Diese E-Mail enthält vertrauliche und/ oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese E-Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser E-Mail ist nicht gestattet.
>> 
>> The European Commission has established a European online dispute resolution platform (OS platform) under http://ec.europa.eu/consumers/odr/ <http://ec.europa.eu/consumers/odr/>. The OS platform can be used by a consumer for the extra-judicial settlement of a dispute of online contracts with a provider established in the EU companies.
>> 
>> Please refer to https://www.db.com/disclosures <https://www.db.com/disclosures> for information (including mandatory corporate particulars) on selected Deutsche Bank branches and group companies registered or incorporated in the European Union. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.
> 
> --
> Chris Hutton
> Head of Development
> Callsign Inc.
> [C] chris <https://get.callsign.com/chris>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/pipermail/mitreid-connect/attachments/20161213/72e16187/attachment-0001.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: Message signed with OpenPGP using GPGMail
Url : http://mailman.mit.edu/pipermail/mitreid-connect/attachments/20161213/72e16187/attachment-0001.bin