Traccia di password per i principali siti Web su Internet

Question

Traccia di password per i principali siti Web su Internet

#1 da (2 voti)

1

Ero curioso di sapere come le password inserite nei campi password passano dal lato client al lato server. Così, ho iniziato a esplorare articoli online e usando la mia conoscenza di reti e crittografia, ho raggiunto una certa conclusione. Ma continuo a pensare di non capire il meccanismo completo. Questo è ciò che so e correggo se sbaglio.

Oggi la maggior parte dei browser Web utilizza HTTPS che è TLS tramite il protocollo HTTP. In questo, viene creata una sessione tra i due lati utilizzando il protocollo di handshake in cui vengono scambiate le chiavi per la crittografia dei dati. Pertanto, quando eseguo l'accesso o creo un nuovo account su Google, Facebook o altrove, queste chiavi vengono utilizzate per crittografare i dati prima del trasferimento. ( inclusa la password ).

Quando il pacchetto raggiunge il server, decodifica i dati (inclusa la password). Se si tratta di un nuovo account, il server memorizza il valore hash della password o il valore hash salato. Sto pensando in questo momento che la password sia in forma di testo. Nel caso in cui si tratti di un vecchio account, il server controlla semplicemente il valore hash della password con il valore hash memorizzato del client.

Tutto questo o i siti Web si prendono particolarmente cura delle password per il trasferimento ? Qual è la situazione in cui viene utilizzato solo HTTP? Qual era lo scenario prima dell'arrivo di HTTPS nell'immagine?

passwords web-browser password-policy tls

posta Ugnes 20.06.2017 - 08:41

fonte

1 risposta

Leggi altre domande sui tag passwords web-browser password-policy tls

Quale sarebbe un algoritmo di crittografia migliore di RSA_DES_EDE3_CBC? Come filtrare i pacchetti "dati applicativi" di PCAP per TLS?

score 2 · Accepted Answer

Dalla generalizzazione di HTTPS, la maggior parte dei siti si basa sulla crittografia SSL / TLS tra il client e il loro sito. Quindi, come hai detto, memorizzano solo un hash della password. È vero che tra l'endpoint SSL e l'elaborazione effettiva, la password è in chiaro, ma si presume che sia la stessa zona di sicurezza.

Nei vecchi giorni (solo HTTP), erano stati usati due modi, nessuno dei quali perfetto.

Variante di digest dell'autenticazione BASIC.

Il protocollo HTTP prevede la trasmissione di credenziali nei campi dell'intestazione, la cosiddetta autenticazione base . Il nome utente e la password sono combinati con un singolo punto e codificati in una variante di Base64. E può essere rubato da chiunque sia in grado di accedere ai dati di rete.

Per aggiungere un po 'di privacy, le persone immaginavano di inviare solo un hash delle credenziali. Questa era l' autenticazione del digest specificata in RFC 2617. In questa modalità, un hash (MD5) delle credenziali combinato con un nonce dato dal server viene trasmesso. Dato che MD5 non è invertibile, un utente malintenzionato non può rubare la password originale. Ma il principale svantaggio è che la password deve essere mantenuta in una forma invertibile sul server.
Crittografia Javascript dei moduli di accesso

Questa è principalmente una variante del primo per i moduli di accesso. Le credenziali sono lato client con hash, normalmente con un nonce trasmesso in un campo nascosto. Qui di nuovo le password devono essere mantenute sul server in una forma invertibile.

Come è generalmente accettato che sia più sicuro scambiare la password in testo semplice su una linea sicura che ha solo un hash su uno non sicuro, questi due modi non sono più realmente usati.