Autenticazione basata su token - Protezione del token

Il "token di autenticazione" funziona con il modo in cui il server lo ricorda.

Un token generico è una stringa casuale; il server conserva nel suo database una mappatura da token emessi a nomi utente autenticati. I token meno recenti possono essere rimossi automaticamente per impedire che il database del server aumenti indefinitamente. Tale token è abbastanza buono per la sicurezza finché un utente malintenzionato non può creare un token valido con probabilità non trascurabile, un "token valido" è "un token che si trova nel database dei token emessi". È sufficiente che i valori dei token hanno una lunghezza di almeno 16 byte e sono prodotti con un PRNG crittograficamente strong (ad esempio /dev/urandom , CryptGenRandom() , java.security.SecureRandom ... a seconda della piattaforma).

È possibile scaricare i requisiti di archiviazione sui client stessi. Nel paragrafo precedente, quale "memoria" dovrebbe avere il server di un token? Vale a dire il nome utente e la data di produzione del token. Quindi, crea i tuoi token in questo modo:

• Il server ha una chiave segreta K (una sequenza di, ad esempio, 128 bit, prodotta da un PRNG crittograficamente sicuro).
• Un token contiene il nome utente ( U ), il momento dell'emissione ( T ) e un controllo di integrità con chiave calcolato su U e T (insieme), con chiave K (per impostazione predefinita , utilizza HMAC con SHA-256 o SHA-1).

Grazie alla sua conoscenza di K , il server può verificare che un determinato token, restituito dall'utente, sia uno dei suoi o meno; ma l'attaccante non può creare tali segnalini.

La risposta a cui fai il link sembra un po 'così, tranne che parla di crittografia invece di MAC, e cioè:

1. confuso;
2. confondendo;
3. potenzialmente insicuri;

perché la crittografia non è MAC.

In breve, dovresti usare un token casuale one-time di forza crittografica e cancellarlo nel database.

Il token

• deve essere autorizzato a essere usato una sola volta,
• deve essere utilizzabile solo per l'utente per il quale è stato creato,
• deve essere inviato solo tramite HTTPS,
• dovrebbe avere una data di scadenza (ad esempio 7 giorni).

Una volta che l'utente ha effettuato l'accesso con il token, non è valido e deve essere creato e assegnato un nuovo token all'utente. Nel caso di un token scaduto, l'utente deve essere fatto per accedere nuovamente, utilizzando le proprie credenziali reali.

Una descrizione più definitiva e più lunga di queste regole può essere trovata nella parte 2 di La Guida definitiva all'autenticazione del sito Web basata su moduli :

Persistent Login Cookies ("remember me" functionality) are a danger zone; on the one hand, they are entirely as safe as conventional logins when users understand how to handle them; and on the other hand, they are an enormous security risk in the hands of most users, who use them on public computers, forget to log out, don't know what cookies are or how to delete them, etc.

[...]

Follow Charles Miller's 'Best Practices' article. Do not get tempted to follow the 'Improved' Best Practices linked at the end of his article. Sadly, the 'improvements' to the scheme are easily thwarted (all an attacker has to do when stealing the 'improved' cookie is remember to delete the old one. This will require the legitimate user to re-login, creating a new series identifier and leaving the stolen one valid).

And DO NOT STORE THE PERSISTENT LOGIN COOKIE (TOKEN) IN YOUR DATABASE, ONLY A HASH OF IT! The login token is Password Equivalent, so if an attacker got his hands on your database, he could use the tokens to log in to any account, just as if they were cleartext login-password combinations. Therefore, use strong salted hashing (bcrypt / phpass) when storing persistent login tokens.

Aggiornamento: Mi dispiace, ho frainteso la domanda. Il metodo che hai collegato sembra ragionevole, ma non ti proteggerà da attacchi replay o man-in-the-middle. Dovresti usare SSL al suo fianco.

Un puro servizio web API RESTful dovrebbe utilizzare le funzionalità standard del protocollo sottostante:

1. Per HTTP, l'API RESTful dovrebbe abbracciare e rispettare le intestazioni standard HTTP, i codici di stato e i metodi esistenti. L'aggiunta di una nuova intestazione HTTP viola i principi REST.

2. I servizi RESTful DEVONO essere INDICE. Qualsiasi trucchetto, come l'autenticazione basata su token che tenta di ricordare lo stato delle precedenti richieste REST sul server viola i principi REST.

In conclusione: per scopi di autenticazione / autorizzazione, è necessario utilizzare l'intestazione di autorizzazione HTTP. E dovresti aggiungere l'intestazione specifica dello schema di autorizzazione HTTP in ogni richiesta successiva che deve essere autenticata.

Ho sviluppato un servizio web RESTful per l'applicazione Cisco Prime Performance Manager. Cerca in Google il documento dell'API REST Cisco Prime Performance Manager che ho scritto per l'applicazione per ulteriori dettagli sulla conformità dell'API RESTFul - vedi sotto. Per questa applicazione, abbiamo scelto di utilizzare lo schema di autorizzazione "Basic" HTTP per autenticare e autorizzare le richieste. Ovviamente, stiamo utilizzando HTTP per crittografare tutti i dati in transito dal client al server quando si utilizza l'autorizzazione HTTP.

link