Secure handling, access and storage of tokens and other sensitive information

[jzuniga-tdmcs]

What I would like to discuss is, should the project team(s) adopt a more secure data and service security posture in the future, especially as the volume and sensitivity of access token and API Key data continues to grow. One of the primary concerns came about after looking over several of the various schema data types and structures for storing security-related information, such as access tokens, subscription id and other API keys. It seems that for every project right now, Open AI API keys and others alike, are being shared across numerous projects with very little focus on security or long term secure storage.

What I am proposing would be, in order to adopt a more secure data security and service security posture in the future should we consider stepping away from using strings for the security related data types and instead move towards byte arrays or encoded strings or some other solution possibly?

As an example:
Within the prisma/schema.prisma there are several sensitive data fields, such as refresh_token, access_token, id_token, subscriptionId, and customerId, that could be changed to the Bytes data type instead of String. This would also allow for storing encrypted binary data more securely in the future without data bloat.

[awtkns]

Hi @jzuniga-tdmcs thanks for bringing this up as I do think security is an important issue. Completely about shifting towards encrypted strings in the future. For now we are just using the default Prisma Adapter that come with next auth.

With regards to external API keys (eg: users OPENAI keys) we are not currently planning on storing them in the db. However if we did they would definitely be encrypted. cc @asim-shrestha