Rischi per la sicurezza su una data infrastruttura di sessione

Question

Rischi per la sicurezza su una data infrastruttura di sessione

#1 da (1 voti)
#2 da (0 voti)

1

Voglio sapere se questo è uno schema adatto per la gestione delle sessioni. Una volta che l'utente si è autenticato con user / pass, il server restituisce session = MD5(SECRET + user_id) (insieme ad altri campi) dove SECRET è una stringa casuale (ad esempio 256 bit).

Quindi il client invia semplicemente l'hash session ricevuto con ogni richiesta e il server lo convalida controllando che MD5(SECRET + user_id) sia uguale all'hash ricevuto.

Quali sono i potenziali rischi qui? Suppongo che se l'utente è in grado di inviare user_id vuote, è un passo avanti verso SECRET , ma è facilmente evitabile. Inoltre, SECRET potrebbe resistere ogni settimana circa.

(Nota: sto utilizzando Node come back-end per un'app mobile, quindi non ci sono browser e cookie).

session-management

posta Carlos Navarro Astiasarán 14.08.2016 - 10:16

fonte

2 risposte

Leggi altre domande sui tag session-management

Questo malware è Android? CMP - Ottieni semplicemente un certificato, conoscendo alcune informazioni

score 1 · Answer 1

Attacco estensione lunghezza

Quello che hai è fondamentalmente un MAC per verificare il tuo valore user_id . Il problema è che un MAC primitivo come MAC = md5(KEY | MESSAGE) è vulnerabile agli attacchi di estensione della lunghezza .

Ciò significa che un utente malintenzionato con l'id utente 1 potrebbe ad esempio rappresentare un utente con l'id 10 semplicemente aggiungendo un 0 .

Come minimo, dovresti utilizzare un HMAC appropriato o utilizzare una funzione hash non vulnerabile come come sha3.

Scadenza token

Se non si memorizza nessuno stato sul server, si ha il problema di non essere in grado di revocare un token.

Quindi, se un utente, ad esempio, modifica la propria password perché sospetta un compromesso, un utente malintenzionato che ha acquisito un token in precedenza può ancora utilizzarlo. Non hai modo di invalidarlo e devi aspettare che scada in modo naturale.

Soluzioni

Ciò che sembra essere sessioni lato client . Potresti considerare l'utilizzo di soluzioni esistenti come JWT o qualche altro libreria esistente .

Ulteriori problemi

Come detto @ 0x23212f, il tuo schema ovviamente non sostituisce TLS e non ti proteggerà dagli attacchi man in the middle.

A parte questo, dovresti considerare se hai effettivamente bisogno di sessioni lato client. Se, come suggerito nei commenti, l'unico motivo è di evitare una query del database, probabilmente non vale la pena di implementarla o l'overhead di rete aggiuntivo.

score 0 · Answer 2

Intendi a parte gli attacchi MiTM (Man in the Middle)?

Perché quello sarebbe il più ovvio da vedere qui. Se invii lo stesso hash ad ogni richiesta, significa che esiste la possibilità che un utente malintenzionato possa intercettare la richiesta e utilizzarla per spoof l'utente.

Se vuoi evitare anche questo, potresti dare un'occhiata a DUKPT (Derivato Chiave Unica per Transazione). Le banche usano una versione proprietaria di DUKPT per quanto ne so.

Ma poi di nuovo, non andrei davvero così lontano. Un canale di comunicazione sicuro potrebbe aiutare a prevenire il problema summenzionato.