The flaw may be assuming everything else can be equal in the real world. Obscuring the algorithm has downstream consequences that may/will reduce overall security.
For example, hiding the algorithm from whitehats may prevent/discourage them from hunting/reporting bugs.
We measure password and cryptographic key security based on their entropy (keyspace) and speed (key tests / second). Given current attacks (GNFS), a 2048-bit RSA key has ~112 bits of security^1 and would take ~20,000 years to brute force using every computer ever made^2. Passwords and cryptographic keys are selected as the single point of obscurity in these systems so that many eyes may secure the other components. If the system is otherwise secure, then it is as weak as the passwords/keys which are (hopefully) picked to be very strong.
Most individuals defending algorithmic security through obscurity believe that hiding the algorithm improves security. That may be true in an extremely technical sense (the attacker must recover the algorithm first), but it is very misleading and unprofessional commentary. Algorithmic security through obscurity is at best calculated in difficulty-to-reverse-engineer (or difficulty-to-steal), which doesn't provide per-use(r) specificity (per-user password) nor scale in complexity (a 256-bit key is generally 2^128 times stronger than a 128-bit key, but doubling the algorithm length increases reversing time by slightly less than a factor of 2).
Algorithmic security through obscurity provides negligible security, but what's the harm? Why should we care? Attempting to hide the algorithm provides a false sense of security, limits review to "approved" parties, and induces legal/social efforts to "protect" the secret. The limited review is particularly noteworthy since it promotes bugs in both the algorithm and the implementation. The end result is a facade of security, some very unhappy whitehats, some very happy blackhats, and more users betrayed through poor security practices.
> "In return for the hollow credits, ConocoPhillips paid Green Diesel $18 million, according to court documents. Shell got stung for $14.4 million, BP for $13.6 million, Marathon Oil for $12.4 million, Exxon $1.2 million. All these companies also were forced to buy new RINs to replace Rivkin’s phony ones."
> Federal agents were watching, as was Houston attorney David Fettner. He’d been appointed by a court to find and seize Rivkin’s property on behalf of commodities trader VicNRG, which had sued Green Diesel and other Rivkin companies for selling it $3.8 million in bogus RINs. “Rivkin left a trail of unhappy people behind him,” he says.
Doesn't seem like everyone else was happy
> Well, given that the buyers bought just the numbers and not did not go to the authorities immediately it would seem that everybody in the deal was happy except for the EPA.
You'd be happy buying $1000 from someone for only $100, until you discovered the money was essentially worthless (counterfeit)
> > but without the battle-tested implementations.
> "I don't know what's wrong but I'm kinda afraid to try".
Battle-tested implementations have dealt with (at least some of) these threats previously. New approaches often miss the lessons of past efforts, leaving themselves vulnerable to old attacks.
Salt is random data used to cryptographically sign or encrypt data. It sounds like your JWT consists of a userID and a sessionID (stored in Redis).
Why not just store your sessionID in a cryptographically signed HttpOnly cookie? In most use cases, it'd be less ambiguous, better protected from JS attacks, and equal-or-less vulnerable to CSRF.