Firma i cookie di sessione

Question

Firma i cookie di sessione

#1 da (6 voti)

5

Play Framework per Scala supporta i cookie di sessione firmati. Nel file di configurazione dell'applicazione è presente un "segreto dell'applicazione" che viene impostato come numero casuale sicuro quando il codice sorgente dell'applicazione viene inizializzato. Questo segreto viene condiviso tra più copie dell'applicazione in esecuzione in una server farm Web in modo che tutte le firme dei cookie possano essere verificate su qualsiasi server.

Quando viene creata una sessione in Play, la sessione viene firmata automaticamente utilizzando l'applicazione secret e HMAC-SHA1.

Sono preoccupato che venga utilizzato lo stesso segreto dell'applicazione per la vita dell'applicazione. Questa preoccupazione è valida?

Stavo cercando un modo migliore per firmare i cookie, ma conosco il motto contro l'inventare le tue tecniche crittografiche.

Esiste un modo accettato per condividere tutti i server con un segreto che cambia?

Ho pensato a quanto segue (nota che tutti i cookie di sessione sono solo in memoria e scadono quando il browser è chiuso):

Incorpora la data della firma (UTC) in ciascun cookie.
La chiave di firma viene generata in modo casuale dalla prima firma del giorno (dopo la mezzanotte) e archiviata nel database per tutti i server da condividere.
Quando un server deve firmare un cookie, controlla la propria chiave di firma e la data in cui è stato generato e confronta quella data con la data corrente.
- Se la data della firma è la stessa della data corrente, la chiave viene utilizzata per firmare il cookie.
- Se la data della firma è precedente alla data corrente, il server controlla il database per una nuova chiave di firma con la data corrente.
  - Se esiste una chiave con la data corrente nel database, viene utilizzata per firmare il nuovo cookie. Le vecchie chiavi di firma vengono conservate (per un certo numero di giorni) per verificare i cookie meno recenti.
  - Se non è presente alcuna chiave per la data corrente, ne viene generata una nuova (come faccio a gestire più server facendo ciò contemporaneamente in un database NoSQL?).

Come algoritmo alternativo, posso generare un nuovo segreto ogni giorno usando HMAC (segreto dell'applicazione, data corrente). Con questo, non ho bisogno di memorizzare le chiavi segrete giornaliere nel database, dal momento che tutti i server possono generare la stessa sequenza giornaliera di chiavi. Non sono sicuro se questo è più (o meno) sicuro di memorizzare la chiave giornaliera nel database. Ho bisogno di proteggere l'applicazione segreta, ma non più di quanto ho bisogno di proteggere il database. Si consiglia di non archiviare il segreto dell'applicazione nel controllo del codice sorgente, ma di caricarlo da una variabile di ambiente impostata su ciascun server di produzione.

cookies digital-signature session-management

posta Ralph 27.12.2013 - 15:14

fonte

1 risposta

Leggi altre domande sui tag cookies digital-signature session-management

Guardando per applicazioni come WireShark e altre gronde che cadono sulla rete aziendale TrueCrypt contro la crittografia "nativa" dell'intero disco su Linux?

score 6 · Accepted Answer

L'insistenza sul rinnovo frequente delle chiavi è una vecchia tradizione ma non è obbligatoria. Nei tempi più antichi, quando la crittografia era qualcosa per gli eserciti e le spie, le chiavi dovevano essere rinnovate perché le spie venivano spiate ei soldati venivano fatti prigionieri nel corso delle loro operazioni quotidiane; era quindi irragionevole credere che un valore segreto noto agli agenti sul campo potesse rimanere indefinitamente segreto. Così è nata l'abitudine a rinnovamenti regolari (e frequenti) delle chiavi. Questo non si adatta bene ai server Internet, per i seguenti motivi:

Le intrusioni effettive sui tuoi server sono eventi rari. La situazione normale è che non si verifica nessuno. Desideri comunque utilizzare i meccanismi di rilevamento, ma puoi aspettarti che, in media, non si verifichi alcuna intrusione per mesi alla volta.
Quando si verifica un'intrusione, l'attaccante mette in atto il suo principale danno immediatamente . Questo è un mondo informatico; entro i 10 secondi successivi all'intrusione, l'utente malintenzionato ha installato il suo rootkit, scaricato tutti i dati a cui è interessato, modificato alcuni record e lasciato. Un rinnovo quotidiano delle chiavi lo "butta fuori" (cioè rende obsoleti tutti i cookie falsi che l'utente malintenzionato potrebbe inventare usando la chiave rubata) solo molto tempo dopo che il danno è stato fatto. Il dogma del rinnovo chiave è stato sancito in un momento in cui l'elaborazione media dei dati era questione di giorni o settimane, non di secondi. La scala temporale è molto cambiata da questi giorni.

Quindi direi che un tasto MAC di lunga durata non è un problema cruciale. Ovviamente, dovresti occuparti di tutti i dettagli su come tale chiave viene generata, memorizzata e condivisa tra i tuoi server; è un importante elemento segreto con un valore elevato per l'attaccante. Tuttavia, il rinnovo è per lo più inutile e può essere pericoloso, poiché influisce sul modo in cui la chiave viene archiviata e condivisa. Con una chiave fissa e statica, è possibile memorizzare la chiave come file protetto dal sistema operativo su ciascun server e condivisa con una procedura manuale una tantum in condizioni controllate (ad esempio prima i server vengono effettivamente messi online ). Se si desidera rinnovare le chiavi automaticamente su base giornaliera, è necessario disporre di un archivio condiviso o di un protocollo di rete, che aumenta intrinsecamente l'esposizione di quel valore segreto. Ad esempio, se si utilizza uno schema di database per generare e condividere la chiave del giorno, la chiave può diventare una facile preda a un attacco di SQL injection, mentre un semplice file sarebbe rimasto riservato.

Per questi motivi, ti consiglio di astenermi dal rinnovo della chiave. Rende il problema molto più complesso da analizzare, con una maggiore esposizione, per un guadagno che, nel migliore dei casi, è altamente discutibile.

(Nota: questa "firma" è più correttamente denominata MAC . Il termine "firma" è, in crittografia , riservato ad algoritmi di persuasione asimmetrica, ad es. RSA, mentre HMAC fa parte della "crittografia simmetrica", nel senso che la stessa chiave viene utilizzata per generare il valore MAC e verificarlo.