In quale caso si dovrebbe cifrare i cookie?

Se contengono informazioni sensibili e non hai altra soluzione che inviarle in un cookie (molto probabilmente non lo fai). Il modello pub / priv key non funzionerebbe facilmente all'interno di un browser e molto probabilmente non raggiungerebbe quello che stai cercando di fare.

In realtà non dovresti includere alcuna informazione sensibile in un cookie, e quelli che contengono dati di stato che non vuoi modificare dovrebbero essere firmati usando qualcosa come HMAC usando un segreto noto solo al server.

Dovresti crittografare i cookie rendendoli sicuri (inviati solo tramite HTTPS). Non c'è davvero alcun motivo per crittografare manualmente i dati con lato server RSA / AES o simile lato browser o RSA / AES. Se ci provi, probabilmente lascerai aperte vulnerabilità nel tuo protocollo di implementazione, identificazione e scambio di chiavi.

I cookie dovrebbero contenere solo informazioni a cui non interessa se il browser dall'altra parte vede o manomette. Utilizza TLS (Transport Layer Security) per garantire che gli intercettatori della rete non possano vedere i tuoi cookie o manometterli.

Se hai dei segreti che devono essere associati all'utente, dovresti archiviare questi segreti sul lato server e associarli all'utente attraverso uno dei due:

1. token di sessione casuale che è abbastanza lungo da essere impossibile da indovinare (ad es. 128 bit),
2. token di sessione generato tramite un HMAC generato lato server all'accesso con un segreto sul lato server che identifica l'utente . Questa sessione è controllata lato server ogni volta che è necessario utilizzare un segreto. Qualcosa come HMAC(username+login_timestamp, key = server_side_secret) dove essenzialmente hai una combinazione delle informazioni degli utenti con la chiave segreta lato server. Quindi è possibile associare i segreti con il nome utente e prima di utilizzare i segreti, verificare che il token di sessione sia valido controllando che l'HMAC sia valido. Quindi un utente malintenzionato che modifica il proprio nome utente (di qualcun altro) o modifica la data di accesso (per evitare il logout automatico) non può fingere di essere un utente con accesso valido.

Ah biscotti. Piccoli morsi di informazioni deliziose da un server web. Questa tecnologia è in circolazione da molto tempo, è provata e vera e funziona molto bene se implementata correttamente.

Ora dico che se implementato correttamente, e c'è una ragione per questo. I cookie contengono informazioni. Mantenere segrete le informazioni segrete è una priorità assoluta. Se quelle informazioni non sono più segrete, può succedere qualcosa di brutto. Questo porta al modo più semplice per decidere se un cookie deve essere crittografato:

Does this cookie contain sensitive information?
Yes: ENCRYPT
No: Whatever

Quindi come si cripta il cookie? Beh, questo dipende dal tipo di cookie:

Session/Server Side Only: Never let the user modify it(private, done on server only)
Private user data: symmetric, secure encryption so that the user can use the information inside of it

Dopodiché si tratta di controllare per assicurarsi di utilizzare gli algoritmi corretti per crittografare i dati in modo sicuro e disporre di controlli e contrappesi sufficienti per assicurarsi che non vengano manomessi (si pensi a JWT)