Longueur de la clé privée HMAC sha256 digest donnée donnée

Question

Nous avons construit un module javascript qui peut être intégré dans des pages Web tierces. Lorsque ce module client est initialisé, il exécute une transaction au sein de notre application Web via une requête intersite.

La transaction consiste en un uuid externe, un e-mail et quelques propriétés méta supplémentaires. Ce message est signé avec un condensé HMAC sha256, en utilisant la clé API privée de notre partenaire.

exemple Ruby:

data = { 
    uuid: "ABCAFAFDS", 
    email: "email@gmail.com", 
    meta: {} 
} 

private_key = "Qd9fe0y2ezqfae4Qj6At" 
signature = OpenSSL::HMAC.hexdigest(
    OpenSSL::Digest.new("sha256"), 
    private_key, 
    data.to_json 
) 

la page web tiers, le client javascript est alors initialisé avec la signature et les données:

new Client(signature, data).execute(); Initialement, notre plan était de permettre au client de créer une transaction partielle/incomplète au sein de notre système, puis de demander une demande dorsale ultérieure via notre API REST pour confirmer/finaliser la transaction. En supposant que nous puissions sécuriser le frontal, il serait préférable de supprimer l'exigence de confirmation dorsale. Pouvons-nous raisonnablement sécuriser le code client en utilisant des messages signés de cette manière? Si les données et le message signé sont disponibles dans le client, est-il difficile pour un mauvais acteur de forcer la longueur de la clé privée de l'API, étant donné la longueur ci-dessus?

Answer 1

la plupart du trafic Internet a signé des jetons sur le client ces jours-ci. Toutes vos connexions Gmail, les connexions Facebook, etc font cela donc c'est assez standard. Je vous recommande d'utiliser une norme existante (et une bibliothèque tierce) plutôt que de lancer votre propre jeton. Cela vous permettra de tirer parti de l'expertise des autres dans ce domaine. JWT (json web token) est couramment utilisé et il existe de nombreuses bibliothèques pour travailler avec JWT. Voir https://jwt.io pour plus d'informations.