Autenticazione personalizzata in un'API RESTful - Funzionerà?

4

Mi stavo chiedendo se questo sarebbe un modo ragionevole per scrivere un metodo di autenticazione personalizzato per un'API RESTful. Sembra moderatamente sicuro, ma forse ho torto qui.

1) Email e password vengono inviate tramite HTTPS al mio server.

2) Il server memorizza l'e-mail e esegue la password tramite un hash SHA512 con un valore casuale di 256 bit. La password hash e salata è memorizzata nel database.

Quindi ora abbiamo:

email = [email protected]

password = OHqhuewQclakufEjUbZMbowJKEGcvEBz,51c6a3cb58e10754f76e334de064a9dede7875141e1ce0233e3ff14fd7be98a4d5b8fc1c5ab871cb3b1d6b0c9f8073bc3558308511fc4fd6bd049aed5e58a9a4

3) Genera un token casuale con una durata (molto casuale e grande), memorizzalo nel database e collega quel token casuale a quello specifico utente autenticato.

4) Invio il token al client tramite HTTPS (web, Android o iOS), in base al quale è memorizzato in cookie o SharedPrefs o che cosa hai.

5) Ora, il client invia il token con ogni richiesta. Il server può quindi controllare il valore del token memorizzato nella cache con quello che riceve ogni volta per assicurarsi che il server sappia sempre chi sta effettuando richieste.

Questo sembra ragionevole e sicuro? Il problema che penso si presenti qui è se il database dei token viene mai compromesso. C'è forse comunque per indurire quella parte?

    
posta Kris 14.12.2015 - 18:23
fonte

3 risposte

4

Sembra ragionevole se anche il passaggio 5 venga eseguito tramite HTTPS. Per quanto riguarda cosa fare se si sospetta che i token siano stati compromessi, è possibile memorizzare un ExpirationDate per ciascun token e costringere gli utenti a eseguire nuovamente l'autenticazione dopo che il token è scaduto. Sospettando una violazione, espira immediatamente tutti i token immediatamente.

    
risposta data 14.12.2015 - 19:22
fonte
2

La tua idea di token è soddisfacente, ma l'hashing della password è orribile. Stai usando un hash veloce, il sale aiuta un po 'ma questo è insicuro; dovresti usare una lenta funzione di hashing pensata appositamente per password come bcrypt.

La maggior parte dei framework web fornisce funzioni di autenticazione pronte all'uso che utilizzano i metodi più sicuri disponibili, quindi non reinventare la ruota e affidarsi invece a un codice collaudato ampiamente utilizzato. Non stai ancora utilizzando una struttura? Pensa di usarne uno, ti farà risparmiare parecchio tempo.

    
risposta data 14.12.2015 - 22:12
fonte
0
  1. Come già affermato da André Borie: si prega di utilizzare un algoritmo di hash progettato per le password. Tieni presente che le password che stai memorizzando non sono tue. Sono informazioni molto sensibili fornite dall'utente. Puoi avvisare l'utente di non riutilizzare la password, ma è sbagliato presumere che si adegueranno a questo. Inoltre ti biasimeranno se il tuo servizio viene compromesso e le password vengono incrinate.

  2. Considera l'incapsulamento dell'autenticazione in un servizio aggiuntivo separato dalla tua API. Questo può aiutare a ridurre la superficie di attacco.

  3. È possibile incapsulare la memoria di sale in un altro sistema che non è raggiungibile da altri host. Lì si crea un servizio che emette un salt per un dato ID utente o qualsiasi altra informazione che è univoca per un account. Se il tuo database viene scaricato, i sali non ne fanno parte, il che rende il cracking quasi impossibile. Per poter accedere a Salt, un utente malintenzionato dovrebbe disporre dei privilegi di esecuzione del codice e delle informazioni di autenticazione per il servizio. (Supponendo che l'attaccante sappia già che stai usando i sali esterni)

risposta data 15.12.2015 - 11:02
fonte

Leggi altre domande sui tag