Come viene rubata la password su una connessione non SSL?

Question

Come viene rubata la password su una connessione non SSL?

#1 da (28 voti)

20

Sono semi-imbarazzato a fare questa domanda avendo lavorato sul campo per 20 anni, ma qualcuno può descrivermi perché dovrei eseguire SSL su qualsiasi sito web che usa l'autenticazione? Capisco i "perché" problemi più grandi (le persone usano la stessa password su blog e banca) e presumo che le password siano archiviate crittografate nel database del sito, ma voglio davvero, semplicemente, spiegare il rischio tecnico di trasmettere non SSL le password in un modo che è basato su un'applicazione pratica.

Esempio: ho un blog wordpress che sto ospitando su bluehost. Vado alla pagina di accesso e inserisco il mio nome utente e password e premo invio. Queste informazioni vengono inviate al server web in un POST HTTP non criptato.

Ora, se qualcuno è sulla mia rete o su qualsiasi rete in cui i pacchetti sono trasmessi, con uno sniffer, possono leggere i pacchetti e scrivere il codice per analizzare parole interessanti come "login" o "password". È così che funziona?

Come funzionerebbe nel mio esempio? Supponiamo che non ci sia nessuno sulla mia rete domestica, che altrimenti ho preso misure di sicurezza appropriate per dispositivi che sono sotto il mio controllo. Come si intromette l'hacker tra me e il mio sito web? Accederà al proprio account bluehost e sarà in grado di monitorare tutto il traffico sulla sottorete? Oppure potrebbero essere IN QUALSIASI LUOGO; per esempio. Sono su Verizon FIOS, quindi forse entrano (installano un processo automatizzato) un server da qualche parte all'interno della rete Verizon. O potrebbero essere letteralmente ovunque?

La mia conoscenza della rete è che il mio dispositivo trasmette pacchetti con un IP di destinazione che è il server bluehost. Questi pacchetti vengono "notati" e inviati dal router a router e switch upstream che fanno parte della rete Verizon. Quando attraversano ciascuna sottorete, esiste la possibilità che qualsiasi dispositivo seduto su quella rete osservi il pacchetto mentre viene trasmesso localmente. Buone pratiche avrebbero creato quelle reti con sicurezza che non avrebbero permesso alle persone di essere in grado di mettersi in mezzo ... ma una volta che le informazioni arrivano a bluehost, allora siamo alla loro mercè in termini di pacchetti di trasmissione. Una volta che il server http "ascolta" le informazioni POST, viene crittografato e confrontato con la password crittografata localmente.

È un modo accurato per pensarci e spiegare agli altri?

tls

posta DaveA 10.04.2014 - 18:30

fonte

1 risposta

Leggi altre domande sui tag tls

Quale accesso ha attualmente la polizia del Regno Unito nei log dell'ISP e quali informazioni possono fornire i registri? Il file ".htaccess" può essere scaricato. Perché? Come risolvere?

score 28 · Answer 1

Quando i dati vengono scambiati su Internet, salta da router a router, iniziando dalla sorgente (il computer desktop) e terminando con la destinazione (il server di autenticazione a cui si sta inviando la password). Tutti i router, per definizione, "vedono" i dati. Inoltre, tutte le macchine direttamente collegate al collegamento tra due router possono visualizzare i dati.

In pratica, per gli attaccanti di basso livello, lo sniffing della password avviene principalmente attraverso tre meccanismi:

Vicino all'utente (tu). Per esempio. stai usando il tuo laptop e ti connetti attraverso un punto di accesso WiFi; altre macchine collegate allo stesso punto di accesso vedono tutto il tuo traffico. Nota che "prendere provvedimenti" per prevenire tali attaccanti locali può essere abbastanza difficile (ad esempio, dimentica che è coinvolto il WiFi).
Vicino al server. In genere, i server sono ospitati in serie in alcune strutture condivise e indelicate i proprietari dei server possono spiare i loro vicini. Se questo è possibile o anche semplice dipende molto dalla competenza degli amministratori di rete sul sito di hosting.
Attraverso il reindirizzamento attivo. Quando si desidera connettersi a un server , si digita effettivamente un nome e quindi il DNS trova l'indirizzo IP che corrisponde a quel nome. La tua macchina invierà i pacchetti a quell'indirizzo IP. Tuttavia, il DNS, nel suo insieme, è scarsamente protetto e può essere modificato da un individuo malintenzionato. Un cattivo può quindi reindirizzare in modo trasparente i pacchetti alle proprie macchine; può persino ispezionare i dati ma inoltrarli alla loro vera destinazione, il che lo rende un Man-in-the -Middle. A quel punto, l'utente malintenzionato vede tutti i dati, inclusa la password e qualsiasi cosa protegga la password, e può dirottare la connessione in qualsiasi momento.

Tutti e tre i tipi di sniffing possono essere messi in pratica, e vengono effettivamente applicati, da studenti con poche centinaia di dollari di budget e una mancanza di moralità. I criminali più avanzati possono utilizzare altri metodi attivi, ad es. cercando di disturbare i meccanismi dinamici di routing . O semplicemente corrompendo i dipendenti presso le strutture di rete (in particolare i fornitori di servizi Internet).

SSL (ora noto come "TLS") corregge le cose in diversi modi:

Cripta tutti i dati con una chiave che solo i due endpoint (la tua macchina e il server) conoscono, evitando efficacemente intercettazioni passive.
Utilizza il certificato del server, in modo che il cliente possa acquisire una certa sicurezza sul fatto che stia effettivamente parlando con il vero server previsto, non con un falso controllato da un aggressore. Questo è il punto dell'immagine del lucchetto e gli avvisi spaventosi nei browser Web.
SSL garantisce un'integrità continua, il che significa che un attaccante attivo non può semplicemente mettersi in posizione MitM, inoltrare i byte di dati avanti e indietro e quindi dirottare la connessione dopo che l'autenticazione è avvenuta. La protezione garantita da SSL è sia per riservatezza (i dati sono illeggibili per gli esterni) sia per integrità (i dati non possono essere modificati dagli estranei) e questo comprende la connessione completa, non solo i passaggi iniziali.

Con SSL attivo e nessun problema di convalida del certificato, è possibile inviare la password con ragionevole garanzia che solo il server previsto la vedrà. Qui il modo in cui il server verifica la password è irrilevante. Inoltre, e ancora grazie a SSL, il server può presumere che l'autenticazione iniziale sia valida per tutto il traffico successivo sulla stessa connessione, perché SSL garantisce che parlerà sempre con lo stesso client.