El ataque de extensión de longitud del que habla @Tinned_Tuna te hubiera permitido generar tokens falsificados con un "texto público" de su propia elección (dentro de algunas restricciones de formato debido al relleno SHA-256, sin embargo), pero solo si el secreto fue lo primero en la función hash. Al ingresar el último secreto, se evita esta debilidad específica.
Otra debilidad menos grave relacionada con la entrada del "texto público" primero es que, potencialmente , como atacante, podría intentar crear una colisión SHA-256, tener un mensaje de el sistema de propietario de la clave autentica el par en conflicto y el valor de hash será válido para ambos mensajes. En otras palabras, el uso de SHA-256 (público + secreto) hace que el algoritmo sea tan fuerte como la resistencia de colisión de la función hash, en lugar de la resistencia de preimagen. Este no es un problema grave porque SHA-256 tiene una salida de 256 bits, lo que lo hace inmune (en la práctica) a las colisiones; eso es más un problema teórico en el que no vale la pena el dinero (tiene que usar una salida de 256 bits para obtener una seguridad de 128 bits).
Una forma manual de expresar las cosas es que, en tales construcciones, debe ingresar la clave secreta al menos dos veces, al principio y al final del cálculo. Pero, en realidad, desea un MAC ; de eso se tratan tus "tokens". Entonces, hazte un favor, no intentes inventar tu propio algoritmo; en su lugar, use algo que ha sido cuidadosamente diseñado y estudiado durante años, incluso décadas, y le proporciona el tipo de seguridad que desea. Esto se llama HMAC . HMAC usa una función de hash subyacente (por ejemplo, SHA-256) pero lo hace bien , con la clave secreta insertada en el lugar correcto para evitar las trampas complicadas que implica el uso de una función de hash real, como opuesto a la bestia mítica conocida como un "oráculo aleatorio". Si estudias HMAC, verás dos invocaciones anidadas de la función hash, con la clave secreta utilizada dos veces .