Scelta di un algoritmo di crittografia per token di autenticazione passati tramite AJAX

1

Sto cercando un algoritmo di crittografia a bassa CPU per passare i token di autenticazione di sessione.

Ad esempio:

  • L'utente eseguirà l'accesso al sito Web (tramite OAuth, sia dal sito come provider o da un fornitore esterno)
  • Indipendentemente dal modo in cui sono stati originariamente autenticati, un nuovo token di sessione prodotto in modo casuale (in questo caso una stringa di 64 caratteri) è associato al proprio account ed è memorizzato in un cookie.
  • Su ogni nuova richiesta di pagina, il token di sessione è tratto dal cookie, crittografato con un nonce basato sul tempo (per evitare la riproduzione) e collocata nelle intestazioni come un meta tag e resa.
  • L'utente fa qualcosa che spara una richiesta AJAX javascript all'API del sito. Il javascript preleva il token crittografato dal meta tag.
  • L'API riceve i parametri, estrae le informazioni crittografate e la decrittografa.
  • Le cose accadono ...

Ovviamente, questo potrebbe finire con un sacco di crittografia. Certo, i dati saranno solo piccoli, ma è il volume che mi preoccupa. A tal fine, sto cercando un algoritmo di crittografia che:

  • L'utilizzo della CPU è basso
  • Ampiamente disponibile sarebbe bello.
  • Facile da usare sarebbe bello.

Ho dato un'occhiata in giro, ma il dettaglio di alcuni dei confronti che ho visto è al di là delle mie conoscenze per essere completamente d'aiuto. Se qualcuno potesse dare un suggerimento, sarebbe utile. Inoltre, se qualcuno vede una falla abbagliante con la sicurezza nell'esempio precedente, ti preghiamo di farmelo sapere.

Informazioni extra a causa dei commenti:

  • SSL verrebbe utilizzato per tutte le comunicazioni.
  • Il cookie (intero) viene crittografato utilizzando AES. Le coppie di valori chiave specifici non sono.
  • Non desidero modificare il valore utilizzando il browser, voglio che il valore già crittografato sia inviato tramite AJAX e quindi decifrato lato server nell'API dati.
  • Non desidero che l'utente abbia accesso a un token di sessione non crittografato.
  • La maggior parte dello stato è conservata nel database, il token di sessione è lì solo per far sapere all'API chi sta facendo richieste. A malapena qualsiasi altra cosa viene mantenuta dal lato client.

La ragione principale di questo tipo di set up è quello di consentire a molti clienti diversi di accedere all'API tramite HTTPS, che si tratti di web o mobile o qualsiasi altra cosa, in modo che il server di dati API non possono risiedere sulla stessa macchina come il sito web, e il sito web non ha accesso diretto al database.

    
posta Iain 04.02.2013 - 14:16
fonte

1 risposta

2

Il tuo caso d'uso è un po 'strano. Come regola di base, hai bisogno di SSL se i dati scambiati tra il server e il client Ajax sono sensibili in alcun modo; ne hai bisogno sia per la riservatezza che per l'integrità. E se hai SSL, allora hai tutto ciò di cui hai bisogno; in particolare, sconfiggi gli attacchi di replay (questa è una funzionalità di SSL).

Dovresti armeggiare con la crittografia solo se vuoi scaricare parte del tuo spazio di archiviazione sul client; ovvero, si mantiene uno stato specifico dell'utente ma non si vuole pagare per il database corrispondente. Invece, si invia quello stato al client stesso, per essere memorizzato in un cookie o nelle viscere degli oggetti RAM gestiti dal codice Ajax. In questo specifico scenario, il client è un potenziale aggressore e si desidera proteggere lo storage con crittografia e integrità e con un timestamp o un contatore aggiuntivo. Questo è ancora un caso piuttosto marginale ed è difficile raggirare; è molto più semplice memorizzare semplicemente lo stato dell'utente nel database del server.

    
risposta data 04.02.2013 - 14:50
fonte

Leggi altre domande sui tag