Quali sono i vettori di attacco per le password inviate su http?

Sto cercando di convincere un cliente a pagare per SSL per un sito Web che richiede l'accesso. Voglio assicurarmi di comprendere correttamente i principali scenari in cui qualcuno può vedere le password che vengono inviate.

La mia comprensione è che in uno dei salti lungo la strada è possibile utilizzare un analizzatore di pacchetti per visualizzare ciò che viene inviato. Ciò sembra richiedere che qualsiasi hacker (o il suo malware / botnet) si trovi sulla stessa sottorete di qualsiasi hop che il pacchetto impiega per arrivare a destinazione. È giusto?

Supponendo che un certo sapore di questo requisito di sottorete sia vero, devo preoccuparmi di tutti i luppoli o solo del primo? Il primo di cui posso ovviamente preoccuparmi se sono su una rete Wi-Fi pubblica poiché chiunque potrebbe essere in ascolto. Dovrei essere preoccupato di cosa sta succedendo nelle sottoreti attraverso le quali i pacchetti viaggeranno al di fuori di questo? Non conosco molto sul traffico di rete, ma suppongo che fluisca attraverso i data center dei principali corrieri e non ci siano molti succosi vettori di attacco lì, ma per favore correggimi se sbaglio.

Ci sono altri vettori di cui preoccuparsi al di fuori di qualcuno che ascolta con un analizzatore di pacchetti?

Sono un sostenitore del networking e della sicurezza, quindi sentitevi liberi di mettermi in chiaro se sto usando la terminologia sbagliata in tutto questo.

Qualcosa da notare che altri non hanno menzionato qui è che alcuni browser memorizzano nella cache i dati del modulo. Il comportamento predefinito sui siti SSL è in genere di non memorizzare nella cache nulla a meno che non si scelga "salva la mia password". In genere i campi password non memorizzano nella cache comunque, ma ho visto alcune stranezze (in genere le informazioni sulla carta di credito, che so non sono proprio l'argomento della domanda).

L'altra cosa da notare è che la crittografia SSL inizia con l'handshake TCP. Una volta in SSL non è possibile distinguere HTTP su SSL da FTP su SSL (a parte le ipotesi fatte tramite il numero di porta).

Inoltre, non puoi distinguere una richiesta di accesso da una richiesta "Sto solo navigando", ciò offusca il flusso di pagine da potenziali hacker e assicura anche che non solo i tuoi dati di password siano al sicuro, ma la tua cronologia di navigazione / dati sui cookie / e qualsiasi informazioni personali che accompagnano il tuo account.

Tutto sommato se elimini gli attacchi man-in-the-middle dallo spettro che riduci a molti potenziali attacchi, ciò non significa che il tuo sito sia "sicuro". Anche la politica di suddivisione in zone dovrebbe aiutarti a proteggerti dagli attacchi XSS poiché effettuerai un cambio di zona se il tuo utente viene reindirizzato fuori dal tuo sito.

I dati sono vulnerabili ovunque lungo il percorso, non solo nella prima o nell'ultima fase. È abbastanza ipotizzabile che un sistema coinvolto nel trasferimento cerchi nomi utente, password e altri dati sensibili. Ne consegue quindi che i dati sensibili dovrebbero viaggiare solo su un collegamento protetto fino in fondo e, naturalmente, questo è esattamente ciò che serve a SSL. A seconda dei dati coinvolti, potrebbero esserci delle leggi locali che dettano SSL.

Esistono server proxy che potrebbero archiviare dati.

Ma esiste anche l'obbligo di proteggere le password degli utenti. Molti utenti utilizzano un set limitato di password, quindi un sito non sicuro potrebbe compromettere la password della homebank, ad esempio.

La tua analisi è ragionevole, IMHO.

La cosa da notare, suppongo, è che potrebbero esserci delle cache nel tuo percorso. Quindi potrebbe essere che la richiesta venga registrata da qualche parte (specialmente se il login è su GET, il che sarebbe terribile).

Probabilmente la cosa da considerare è che la maggior parte dell'accesso alla rete avviene in un'area in cui ci sono molte altre persone sulla stessa rete. Lavoro / Uni / Scuola sono gli esempi principali. A casa potresti sostenere che è meno rischioso, perché devi preoccuparti solo dei percorsi verso l'alto.

Ma davvero, non c'è dubbio qui. Usi SSL quando accedi. Probabilmente l'argomento più convincente per il ragazzo sarà che farà sembrare il tuo sito web più affidabile, poiché - idealmente - il pubblico in generale non accederà mai a un sito che non ha una schermata di accesso basata su SSL .

Ma siamo realistici. Quasi certamente questo vettore di attacco non è il modo in cui il suo sistema o gli utenti saranno compromessi.

HTH.

Sono d'accordo con le riflessioni di KevinM sul rispondere alle sue stesse domande e John Gardeniers sta indicando la direzione corretta. Devo anche essere d'accordo con ciò che ha detto la seta, "idealmente - il grande pubblico non accederà mai a un sito che non ha una schermata di accesso basata su SSL", e sottolineo che questo non è, tuttavia, il caso contemporaneo affatto.

Non sono d'accordo con il tono setoso (probabilmente non intenzionale), che porta alla percezione onnipresente che "il grande pubblico" sia stupido. Il cliente di KevinM non ha chiaramente idea di un bisogno di SSL, e questa è la persona media in breve. Non sono stupidi, semplicemente non lo sanno. Dire "hai bisogno di questo", illecirà la risposta, "ho vissuto x anni senza di essa, e vivrò x più bene", o forse anche una risposta peggiore ", odio sentirmi dire di cosa ho bisogno ". Quindi sii attento!

La tua preoccupazione è legittima, Kevin. Il tuo cliente ha bisogno di un certificato SSL. Penso che la tua vera preoccupazione dovrebbe essere come venderli uno. Non sono solo gli accessi degli utenti a preoccuparsi, ma gli accessi dell'amministratore e dell'operatore che trarrebbero beneficio anche dalla protezione da SSL.

Sì, ci sono altre cose di cui preoccuparsi a questo proposito, ancor più che lo sniffing dei pacchetti, come XSS . Sono numerosi e ben documentati .

nell'intero percorso seguito dal pacchetto, se il suo over HTTP può essere annusato e i dati possono essere visti ... anche se si utilizza HTTP in Proxy come TOR ... usando harvesting-attack, ecc. si può ingannare il proxy per far trapelare i pacchetti di dati ... quindi se c'è qualcosa vicino ai sensibili (password, dettagli personali, immagini private, ecc.) ... è adatto solo per trasferirli su HTTPS.

Anche questo, anche HTTPS è vulnerabile con un'implementazione errata e sono diversi gli attacchi SSL applicabili su di esso ... tuttavia quelli possono essere evitati con un'implementazione attenta.

Ma usare HTTP per il solo testo è come invitare anche i neofiti a annusare le password.