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

[Dominik Schmich]

Classification: For internal use only
I can agree with you on most points. The only problem I still see is the point between the illegal access to the database and the discovery of this. In this timeframe access & refresh tokens can be heavily misused. The reduction of this risk is only by the timeout of each token which can be very long for refresh tokens.

I don't really see why the lookup is easier by value than by id? The even bigger question is: why the need to look them up anyways, since their JWTs? Only to verify if they got revoked? The JIT should be enough here, right?

I can see that secrets can't be stored as hash with symmetric functions.

I understood the following:

-          the change from token value in the database to only use JIT should work for ID, Access & Refresh Tokens

-          the secret needs to be available unhashed but can be encrypted

-          the auth code has anyways only a hard coded timeout of 5 mins and is only an OTP therefore could stay at is, but it should be OK has hash aswell

Beste Grüße / Kind regards,
Dominik Schmich

From: Justin Richer [mailto:jricher at mit.edu]
Sent: Mittwoch, 14. Dezember 2016 02:47
To: Chris Hutton <chris.hutton at callsign.com>
Cc: Dominik Schmich <dominik.schmich at db.com>; mitreid-connect at mit.edu
Subject: Re: [mitreid-connect] Storage of Tokens in DB [I]

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



---
Die Europäische Kommission hat unter 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. 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/. 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 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/pipermail/mitreid-connect/attachments/20161214/75920f1c/attachment-0001.html