Why is the JWT secret hardcoded by default?

[Samuelodan]

Hi there,
as the title suggests, I'd like to know the reason behind the decision to hardcode the JWT secret in app/misc/rodauth_main.rb instead of using Rails secret_key_base.
I was considering creating a separate JWT secret in Rails credentials and using it for JWT signing, then I realized I'd seen secret_key_base used as JWT secret quite a number of times in the past. Could this be a security measure for in case Rails secret_key_base is compromised?

[janko]

Honestly, I just used a separate JWT secret because I saw it recommended in the devise-jwt README:

Important: You are encouraged to use a secret different than your application secret_key_base. It is quite possible that some other component of your system is already using it. If several components share the same secret key, chances that a vulnerability in one of them has a wider impact increase. In rails, generating new secrets is as easy as bundle exec rake secret. Also, never share your secrets pushing it to a remote repository, you are better off using an environment variable like in the example.

I don't know what are the security implications of reusing secret_key_base. I suppose people could be using secret_key_base in places where it's easier to leak out, but I would argue that then your whole app is compromised, because the attacker could then generate valid session cookies and other things. Also, Rodauth has recently added support for JWT secret rotation.

I will probably push a change to the generator to use secret_key_base by default, for easier getting started.

[janko]

But do you know if the :active_sessions feature revokes an active JWT on logout?

Yes, active_sessions provides a whitelist-based approach for JWT revocation. The session data stored in the token includes a session ID that is matched against a record in the account_active_session_keys table on every request. The DB record is automatically deleted on logout, so the JWT token becomes invalid. It works exactly the same way as with Rails session.

[Samuelodan]

Nice! Thank you so much, man. I appreciate it.

[Samuelodan]

Hi Janko, I just had a thought regarding the use of secret_key_base as JWT secret. If secret_key_base is compromised in a Rails API app that uses JWT without cookies or other session stores, would the attacker be able to sign sessions if JWT uses a separate secret and is somehow uncompromised?
Would the separation of the keys have any advantage in this scenario?

I'm struggling to think of how the secret_key_base, if used properly, might get leaked without affecting all other secrets (separate JWT secret included), especially if they're stored in Rails encrypted credentials. But we can assume that it somehow did, I think.

[janko]

Yes, if secret_key_base is compromised, then the attacker can generate valid JWT tokens in this case. If JWT secret was different than secret_key_base, then JWTs would still work. But if secret_key_base is compromised, then other parts of the application would be compromised. For example, if Active Storage is used, the attacker could generate valid variant URLs and thus DoS the server. So, I think it makes sense to prefer convenience here.

[Samuelodan]

I see. So there's little value in having "secure" sessions if the rest of the application is compromised.
Alright. I'll stick with the more convenient solution.
Thank you.