IIS offre molte tecnologie di autenticazione diverse. Uno di questi è l'integrazione dell'autenticazione di Windows. L'autenticazione integrata di Windows sfrutta la negoziazione Kerberos o NTLM per autenticare gli utenti basandosi su messaggi di ticket criptati passati tra browser e server.
Lo scenario applicativo più comune dell'autenticazione NTLM è probabilmente l'autenticazione utilizzata nei browser (protocollo http). Ma in realtà, NTLM specifica solo il processo di autenticazione e il formato del messaggio di autenticazione. Non è collegata a accordi specifici. Quindi non c'è necessariamente una connessione con http. Il browser trasporta solo il messaggio NTLM nell'intestazione del protocollo http e supera l'autenticazione. Sappiamo che http è solitamente in testo chiaro, quindi se la trasmissione diretta delle password è molto insicura, NTLM di fatto previene questo problema.
Processo di certificazione
L'autenticazione NTLM richiede tre fasi per essere completata, e puoi visualizzare il processo dettagliato di richiesta tramite la cassetta degli attrezzi Fiddler.
Passo 1
L'utente accede all'host client inserendo il numero di account e la password di Windows. Prima di effettuare l'accesso, il client memorizza nella cache l'hash della password inserita e la password originale viene scartata ("la password originale non può essere memorizzata nella cache in nessun caso", questa è una linea guida di sicurezza di base). Un utente che riesce ad accedere con successo al client Windows deve inviare una richiesta all'altra parte se tenta di accedere alle risorse del server. La richiesta contiene un nome utente in testo chiaro.
Passo 2
Quando il server riceve la richiesta, genera un numero casuale a 16 bit. Questo numero casuale si chiama challenge o nonce. La sfida viene salvata prima che il server la invii al client. Le sfide vengono inviate in testo semplice.
Passo 3
Dopo aver ricevuto la sfida inviata indietro dal server, il client la cripta con l'hash della password salvata nel passo 1, e poi invia la sfida criptata al server.
Passo 4
Dopo aver ricevuto la sfida criptata inviata indietro dal client, il server invia una richiesta di autenticazione al client al DC (Dominio). La richiesta include principalmente i seguenti tre contenuti: nome utente client; Sfida e sfida originale con hash password client criptato.
Passaggi 5 e 6
DC cripta la sfida originale ottenendo l'hash della password dell'account in base al nome utente. Se la sfida criptata è la stessa di quella inviata dal server, significa che l'utente ha la password corretta e la verifica passa, altrimenti la verifica fallisce. Il DC invia i risultati della verifica al server e infine invia il feedback al client.
Articoli di riferimento:
Il login del link ipertestuale è visibile.
Il login del link ipertestuale è visibile.
Il login del link ipertestuale è visibile.
|
Pubblicato il 5-9-2020 13:28:14
|
|
|
|
