Feat: allow for setting client secrets to known value?

[bkw]

Some Apps are distributed with hard-coded client secrets, in my case owncloud, who distribute their desktop, android and ios clients with a hard coded client ids (but offer builds with custom ids to customers of their paid offering iirc).

I'm not sure how common this is and if this is something we should even support. Or maybe we could just document how to manually configure such edge cases with manual database updates.

Wdyt?

[sebadob]

Someone else had this question quite some time ago and then I couldn't even believe that they are doing something that stupid. If you use a static secret and expose it to the internet, you could simply not use any secret at all, it's pointless in that case and gives a false sense of security. They are doing it for probably only a very simple reason: Lazyness.

A confidential client in such a case is just straight up the wrong decision for so many reasons. The fix would be very easy though. They would only need to switch these clients from confidential to public and use PKCE. That's it. It would not require publicly known secrets, which are not secrets anymore by definition, because, what's secret about them at that point. public + PKCE is also perfectly safe and exactly the use case for such a situation.

The reason why Rauthy does not support this at all is because people are lazy. I have seen it too many times in the past that even Firewalls in enterprises had a password like Batman123.

There is a way to set such a given secret right now, but it's not straight forward at all and requires some manual work both via shell and on the DB directly. If you are interested in this, I could write a tiny guide on how to do make it work.
Only a manual DB update would not do the trick. Client secrets are stored encrypted. This means you would need to encrypt them beforehand with cryptr + your generated ENC_KEYS / ENC_KEY_ACTIVE and then insert the encrypted value and some other columns.

I could add an optional value to the PUT endpoint for client secrets and use a given value so it requires at least a manual API call. Via UI, this will never be available at all.

---

Usually, Apps will never do something like owncloud did and even MUST never do. Public secrets are not secrets and totally pointless. Apart from this case, I have never seen such silly thing in the real world.

I don't get it why you would design something like this. Total nightmare from a security point of view.

[bkw]

Thanks for your thoughtful answer, I agree that it's not worth the effort of supporting this as a regular feature.

I'd still be interested in how to set this up for my family. Since the keys are already published, making the inserts with the encrypted values available somewhere might save others some time, others have put out similar guides for authelia and authentik, including hashed secrets.

So if you could find the time to supply some more guidance, it would be massively appreciated. But I agree, Owncloud should really switch to PKCE, which would also save them the hassle of building custom clients.

[sebadob]

Rauthy uses cryptr under the hood for all values / files encryption. It has to be possible to show client secrets to an admin, so they are encrypted, not hashed. You must use cryptr to encrypt the value, because it creates values with a super tiny header with some important metadata.

Install cryptr

cryptr is not only a crate, but can be installed as an independent CLI. If you have Rust installed on your machine, it's as easy as

cargo install cryptr --features cli

If not, have a look at the precompile binaries I added to the repo.

Make sure the command works with

❯ cryptr -h
simple encrypted (streaming) values

Usage: cryptr <COMMAND>

Commands:
  encrypt  Encryption Module
  decrypt  Decryption Module
  keys     Encryption Keys Management
  s3       S3 Access Credentials
  help     Print this message or the help of the given subcommand(s)

Options:
  -h, --help     Print help
  -V, --version  Print version

Import ENC_KEYS

In this case, you can't use the import feature to import your key from Rauthy, because the CLI expects keys for import in a sealed, password protected container, so you can store them safely on disk. However, if you

cryptr keys new-random

It will create a new, minimal config in $HOME/.cryptr/config with a random key. You don't care about this new key though.
Open the file

vim $HOME/.cryptr/config

... grab your ENC_KEYS and ENC_KEY_ACTIVE value from your Rauthy instance and paste them - save and exit.
You can check with

❯ cryptr keys list

Active Key ID:       ezvKXmYIhZlm
ezvKXmYIhZlm

... if it lists your key, to make sure formatting is correct.

Encrypt your secret and convert to HEX

Next, you need to encrypt the hardcoded owncloud secret. You don't need any fancy stuff here, just

cryptr encrypt

... and paste your secret. It will then output the encrypted value encoded as base64.
To be able to use it in a SQL query, you need to convert it to hex. You can either use

echo newBase64EncodedSecretHere | base64 -d | od -A n -t x1 | xargs  | sed 's/ *//g'

... or any online tool, if you don't have all the tools available to you.

Update Database

The next steps depend on your database of choice.

Hiqlite

Prerequisites

For Hiqlite, you have 2 options. Either you can easily access the data/state_machine/db/hiqlite.db file directly and use a local sqlite installation, or if it's running inside a container for instance inside K8s, which can get annoying, you need to enable the query dashboard.

Local sqlite interface is self-explanatory I guess. The dashboard, you can activate by setting HQL_PASSWORD_DASHBOARD in your rauthy.cfg. This value expects an argon2id hash encoded as base64. If it's just for quick and dirty updating, you could use

HQL_PASSWORD_DASHBOARD=JGFyZ29uMmlkJHY9MTkkbT0zMix0PTIscD0xJE9FbFZURnAwU0V0bFJ6ZFBlSEZDT0EkTklCN0txTy8vanB4WFE5bUdCaVM2SlhraEpwaWVYOFRUNW5qdG9wcXkzQQ==

... which is the password 123SuperMegaSafe. But remove it afterward again. ;)
Otherwise, use any argon2id hasher tool and convert to b64.

If this value is set, you can restart the container and the dashboard will be available on port 8200 by default (Hiqlite API, not the Raft port). If you changed the default value for HQL_NODES, it will be the 3rd value in each row. It does not matter via which node you access it, if you have a HA deployment.

You should be able to log in to the Hiqlite dashboard with your password and be able to execute queries.

SQL Query

The SQL query for Hiqlite (SQLite) will look the following:

-- hiqlite
UPDATE clients
SET confidential = 1,
    secret_kid = 'your_ENC_KEY_ACTIVE_id_here',
    secret = x'paste_your_hex_string_inside_here'
WHERE id = 'paste_your_owncloud_client_id';

Postgres

Connect in whatever way suits you. I guess you have multiple, if you run Postgres.

SQL Query

The Postgres query should look like this:

-- postgres
UPDATE clients
SET confidential = true,
    secret_kid = 'your_ENC_KEY_ACTIVE_id_here',
    secret = E'\\xpaste_your_hex_string_inside_here'
WHERE id = 'paste_your_owncloud_client_id';

For the Postgres query, make sure you keep the leading E'\\x. Paste the hex value directly after the \\x.

---

This should do the trick.