Questo sistema di login RESTful sarebbe sicuro?

3

Quindi ho pensato a un modo per rendere un'API riposante e sicura per gli accessi alle applicazioni.

Questo è ciò che il mio insegnante e io abbiamo escogitato:

  1. Il client (programma rapido) inizializza la connessione con server.
  2. Il server restituisce un "segreto condiviso" (es. +40) e un hash di a stringa casuale di lettere e numeri.
  3. Il client quindi esegue il hashing del nome utente e della password (separati) e lo rimanda con l'hash di: hash + "il segreto condiviso".
  4. Dopo che il server invia i dati (passaggio 2) il server esegue l'hash [hash + "shared secret"] e quindi lo aggiorna nel db
  5. Il server riceve quindi il valore hash dal client e controlla il db per vedere se corrisponde a
  6. Il db avrà anche un timestamp che, se non aggiornato frequentemente abbastanza ci sarà una funzione che attraversa il db e scende gli articoli che non sono più utilizzati.
  7. Per ogni richiesta successiva al login viene inviato il token al portatore.

Il token al portatore seguirà questa formula:
Request verification token = hash [ (original hash) + (shared secret) * (# of requests) ]

È sufficiente per proteggersi dagli attacchi Man in the Middle e dallo spoofing del client, o fondamentalmente da qualsiasi cosa che possa consentire all'aggressore di impersonare un utente?

    
posta Reid Pritchard 09.05.2016 - 16:54
fonte

1 risposta

7

No, stai danneggiando attivamente l'usabilità senza alcun vantaggio per la sicurezza.

Sembra un brutto caso di Security Theater * !

Dico questo perché ciò che stai facendo in questo momento è altrettanto sicuro che mandare il nome utente e la password su HTTPS comunque! Tutto ciò che aggiungi è un paio di comunicazioni di installazione aggiuntive. Le vulnerabilità di questa implementazione e le vulnerabilità di invio HTTPS di password e nome utente sono esattamente le stesse .

Analizziamo l'esempio:

Impostazione e utilizzo del segreto

  1. Stabilisci una connessione sicura
  2. Invia il carico utile da memorizzare
  3. Conferma il payload e, se confermato, accedi

Impostazione e utilizzo di una password

  1. Stabilisci una connessione sicura
  2. Invia il carico utile da memorizzare
  3. Conferma il payload e, se confermato, accedi

Questi passaggi sono esattamente gli stessi e non forniscono ulteriore sicurezza. Se avviene un takeover completo (MITM / livello di sistema), la stessa cosa che accadrà con un nome utente e una password avverrà nel sistema. L'autore dell'attacco vedrà comunque tutti i dati mentre vengono trasferiti e consultati tra il tuo sistema e il server. Questo è il motivo per cui le acquisizioni complete sono così pericolose. In pratica, niente puoi fare per proteggere l'utente. L'utente utilizza un sistema di comunicazione che non è più loro, ma gli aggressori e quell'attaccante possono vedere e utilizzare tutto nella comunicazione.

In realtà tutto ciò che stai facendo è generare un segreto (comunemente chiamato una password) da memorizzare, e alcuni metadati (comunemente chiamato un nome utente) per identificarlo. Se i meta dati e il segreto corrispondono a una voce, recuperi tali informazioni. L'unico vantaggio che stai guadagnando è che l'utente ottiene una password extra lunga. Ma a quale fine? Bcrypt ha una lunghezza massima del carattere, quindi stai limitando il numero di caratteri che può avere la singola password. Ora hai anche quel segreto condiviso da preoccuparti di ottenere lo stesso ogni volta o il tuo utente o non possono mai accedere.

Le password e i nomi utente su HTTPS sono stati utilizzati così spesso perché dopo un certo punto (la connessione HTTPS) non c'è nulla che tu possa fare per aumentare la sicurezza. Se qualcuno ottiene l'accesso a tutte le comunicazioni, o allo spazio di memoria, tutte le tue tecniche sono state appena sconfitte poiché devono solo ricreare i tuoi passi e potresti persino non saperlo fino a quando non eseguono il loro attacco.

*: A partire dalla scorsa settimana questa frase è ora maculata sulla mia tastiera ...
*: Il teatro della sicurezza è l'atto di mettere in pratica le pratiche che non fanno nulla per migliorare la sicurezza e potrebbero addirittura danneggiarlo!

    
risposta data 10.05.2016 - 00:08
fonte

Leggi altre domande sui tag