Crypto asimmetrico per archiviare le credenziali in HTML LocalStorage

Question

Crypto asimmetrico per archiviare le credenziali in HTML LocalStorage

#1 da (2 voti)

1

Stiamo sviluppando un'app Web mobile in cui gli utenti desiderano (ed è un requisito non rilassabile) essere registrati per un tempo molto lungo.

La soluzione che stiamo sviluppando ha una parte client web in HTML + JS e un middleware in Java. Memorizzare le credenziali degli utenti nel middleware non è un'opzione perché non vogliamo avere un singolo punto in cui un amministratore può ottenere TUTTE le credenziali degli utenti. Quindi per essere brevi questi sono i requisiti:

Ricordami per un tempo molto lungo
Il middleware non può memorizzare le credenziali degli utenti
I sistemi di autenticazione nel backend del middleware non possono produrre un token di sessione a lungo tempo
Vogliamo proteggere le credenziali degli utenti più dell'accesso alle applicazioni

Sappiamo molto bene che l'archiviazione delle credenziali in HTML LocalStorage o Cookies è una pessima pratica di sicurezza, ma:

1) Gli utenti sanno che hanno un tempo molto lungo "ricordami" ed è loro responsabilità disconnettersi (Sicurezza vs Usabilità)

Ovviamente l'archiviazione delle credenziali in testo semplice in HTML LocalStorage non è un'opzione perché l'attacco XSS può rubare le credenziali, quindi abbiamo progettato una soluzione e vogliamo discutere della sua sicurezza qui. Un piccolo avviso: vorremmo discuterne sotto un vero punto di vista non una visione accademica;)

a) gli utenti mettono le loro credenziali in un modulo web b) una lib di JS crittografa le credenziali con una chiave pubblica RSA (1024) e inserisce il carico utile crittografato (EP) in LocalStorage c) l'EP viene inviato al middleware che lo decrittografa con la chiave privata e autentica gli utenti ai sistemi di back-end (potrebbe esserci un gran numero di sistemi di back-end con SSO) - c'è un id di sessione per evitare la decifrazione su ogni chiamata (quando la sessione scade il client invia nuovamente l'EP) d) se EP esiste sul lato client, il client lo invia e autentica di nuovo l'utente e) se l'utente desidera disconnettersi, il client cancella l'EP e fornisce il modulo di accesso all'utente

I punti di sicurezza sono:

a) sul lato client c'è solo un materiale crittografato con un algoritmo asimmetrico == > nessuno può decodificarlo b) consideriamo molto più difficile per un amministratore inserire nel middleware che rubare credenziali sul disco c) Ogni N mesi rinnoviamo le chiavi RSA e tutti gli utenti devono eseguire la riautenticazione

Gli unici attacchi che riesco a immaginare sono:

a) un plug-in del browser che ruba le credenziali prima la crittografia == > questo è vero per TUTTI i moduli di autenticazione Web b) un attacco di replay: rubare il carico utile di enc consente di autenticare impersonando gli utenti reali == > questo è un problema, ma le credenziali degli utenti sono sicure e questo bilanciamento del ricordo molto lungo (lo stesso problema della sessione molto lunga)

Non riesco a immaginare altri tipi di attacchi.

Sono molto aperto a tutti per migliorare la sicurezza della nostra soluzione (ma l'usabilità è molto importante ...)

authentication asymmetric

posta robob 30.01.2013 - 08:40

fonte

1 risposta

Leggi altre domande sui tag authentication asymmetric

Protezione dei dati su un dispositivo mobile (anche da parte dell'utente / proprietario)? Antivirus / Wireless PCI v2 Controls Scope

score 2 · Answer 1

Sembra che tu stia rendendo questo più difficile di quanto debba essere.

Chiaramente una chiave casuale, emessa dal server che corrisponde a un elemento dati lato server è di gran lunga la soluzione migliore, e in pratica la unica soluzione che qualsiasi organizzazione rispettabile impiega . Ma dal momento che vuoi qualcosa di diverso, ecco qua:

Al momento dell'accesso, crittografate le informazioni di accesso lato server, con sale e alcuni HMAC (e possibilmente un timestamp), base64 codifica il risultato e c'è il vostro token persistente che inviate al client. Idealmente dovresti anche legare l'accesso al dispositivo in qualche modo; forse una sorta di ID dispositivo statico che viene inviato al server e codificato in esso.

Quindi, quando è necessario eseguire nuovamente l'autenticazione, il client trasmette questo token al server, che il server decodifica, autentica e quindi emette l'app come normale.

Non è una soluzione tanto buona quanto un token di autenticazione opaco casuale (che è prezioso solo in quanto corrisponde ad alcuni datastore sul lato server), ma hai detto che questo è impossibile per qualche motivo sconosciuto. Direi che se qualcosa di così semplice e utile come questo è impossibile, allora stai usando il software sbagliato.

Per quanto riguarda l'utilizzo di crittografia asimmetrica e crittografia basata su browser per archiviare i token di autenticazione, non riesco a creare nemmeno uno scenario in cui ciò sia appropriato. Ma a volte la complessità per motivi di complessità ha il suo fascino.