How would tempel work with delegated authentication - OpenID Connect and MFA / OTP ?

[ieugen]

Hi @ptaoussanis ,

I watched the demo https://www.youtube.com/watch?v=sULZVFhR848 and I quite like where the project is heading and that it provides a pretty good flow for solving common problems developers are facing when trying to adopt data encryption at rest.

I am curios how would tempel work with (more common IMO scenarios) of third party authentication systems - like OpenID Connect (SSO in general - social login).

I do imagine one option would be for users to setup a dedicated password for the keystore.
Another things that could be addressed in the docs / future demos would be how tempel will handle multi factor authentication and WebAuthn or one time password systems.

The way I think about it right now it that users setup a dedicated password for the keystore that they have to enter after login.
The password could be an OTP code perhaps ( a pin) ?! .

An example flow of using tempel with OTP would be great as I believe it's a common use case.
As a side note I am doing DevOps and working with these ~ daily .
SSO is quite important for auth and I would not go forward without it.

I did not give these too much thought but from the video I believe you have given security and encryption quite some thought.
I hope you can share your ideas / examples around these subjects.

I am happy that I saw your demo now since I am working on a system where I need to store some JWT tokens encrypted at rest with the option of being able to decrypt them by admin.
I hope to get some time to work with tempel on that soon.

p.s. Than you! for writing tempel !

Thanks,
Eugen

[ptaoussanis]

Thanks Eugen, will try reply properly when I'm next doing batched work on Tempel 👍

[ptaoussanis]

Hi Eugen! Short response in the meantime since I'm currently juggling a few priorities-

MFA

You're must check both [given-password, given-mfa-token] during log-in:

• Checking given-password can be done as usual with Tempel (see the docs/demo/etc.).
• Checking given-mfa-token will depend on the particular MFA method you're using.

With a typical TOTP (Time-Based One-Time Password), you'll have: expected-mfa-token = (fn [secret-mfa-key time]).

How to store secret-mfa-key?:

Option A: store secret-mfa-key inside user's encrypted data

So checking [given-password given-mfa-token] will mean:

1. Check given-password by trying to decrypt user's data with Tempel.
2. That'll yield user's secret-mfa-token. Check given-mfa-token against secret-mfa-token.

Log user in iff both checks pass.

Option B: store secret-mfa-key outside user's encrypted data

So checking [given-password given-mfa-token] will mean:

1. Check given-password by trying to decrypt user's data with Tempel.
2. Check given-mfa-token against secret-mfa-token.

Log user in iff both checks pass. You can check these in any order.

Comparison

Option A is safer in that it protects secret-mfa-key at rest, but option B should generally be sufficient and may be easier if you're integrating Tempel into a pre-existing system.

Delegated authentication (OAuth, etc.)

If your goal is to keep the user's application data fully encrypted at rest (and without any keys present on the system), then you'll need either:

• An additional password from the user (used to encrypt/decrypt their application-level data), or
• A authentication provider with the ability to provide a persistent token that can be used for this purpose.

Basically- if you want encryption at rest, then you need a secret from the service/user that you don't store but that the service/user can reliably provide.

I'm not sure off-hand which service/s might currently provide an appropriate (persistent) token, but the additional password choice would always work and provide wide compatibility.

That may be a reasonable choice if it's an opt-in for the user. I.e. user can opt-in to accepting the burden of keeping another password, in exchange for having their data encrypted at rest.

If the user forgets this password, they can use their service-level authentication to trigger an application-level password reset.

---

Hopefully the above makes sense? Please let me know if there's interest in:

1. Adding the above to Tempel's wiki docs.
2. Adding simple HOTP/TOTP utils to Tempel for convenience.

[ieugen]

Thank you for the detailed answer.
I think this should end up in the documentation at some point.

+1 for adding HOTP/TOTP utils for Tempel.
I think most implementations offer SHA1 TOTP by default but for security it should be SHA256 .

A different question (maybe another issue?).
Have you considered the OWASP recommendations for password storage?
Would it make sense to have an opinionated module that users can use and get Tempel with pre-configured options following OWASP recommendations ?

I know some people who do compliance find these certifications / recommendations very important.
I know they change over time so adding the year in the name would make it easy to check and switch: :owasp-2024-xxx .

https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html#maximum-password-lengths

[ptaoussanis]

Thank you for the detailed answer. I think this should end up in the documentation at some point.

You're welcome. And will add in the next doc update before May/June's release 👍

A different question (maybe another issue?).

Yes, please do try to create separate issues for separate topics 👍
I've answered this question here.