HTTP Web e insicuro - Utilizzo di RSA per crittografare le password sul lato client

In primo luogo, suppongo che tu stia facendo questo per indebolire l'uomo nel mezzo degli attacchi (che sono davvero l'unico problema quando si tratta di password in chiaro su HTTP non sicuro)

L'hashing del lato client ha poco o nessun vantaggio. Un attaccante, al momento del ritiro dell'hash non avrà bisogno di forzare l'hash. Tutto il tuo server ha bisogno dell'hash, quindi l'attaccante può semplicemente creare una richiesta POST con l'hash in esso e inviarla. Non è necessario il testo in chiaro per entrare nel sistema.

Per quanto riguarda la soluzione:

Se si sta utilizzando la stessa chiave pubblica per tutti i client, la situazione è effettivamente la stessa. Come attaccante ho solo bisogno di sniffare il testo cifrato che invii e posso impersonarti mandando lo stesso testo cifrato.

Che cosa succede se hai fornito diverse chiavi pubbliche a ciascun client su ciascun accesso? Poi potrei lanciare un uomo nell'attacco intermedio dove cambio la chiave pubblica del server con la mia, decrittografare il testo cifrato che invii (ottenendo il tuo testo in chiaro, ancora meglio) e cifrarlo con la chiave pubblica del server.

C'è ottenuto per consentire al client di sapere quale chiave pubblica è corretta. Per quello avresti bisogno di un qualche tipo di sistema di fiducia. Dove i clienti sanno quali chiavi pubbliche corrispondono a quale server. Ma questo porterà a milioni di chiavi pubbliche memorizzate nei browser. Quindi avresti bisogno di una sorta di sistema di concatenazione dei certificati. E penso che tu realizzi dove sto andando con questo ; -)

TL; DR: usa HTTPS, la crittografia del lato client senza un sistema di fiducia non è più sicura di nessuna crittografia.

Se sei preoccupato che le password condivise su altri siti vengano rilevate dopo la rottura dell'hash, allora sia l'hashing che la crittografia a chiave pubblica vanno bene (la crittografia a chiave pubblica è migliore a causa delle tabelle arcobaleno). Nota che questi sventeranno solo i piani di un attaccante passivo. Se l'attaccante monta un attacco MITM attivo, può cambiare il codice JS che si invia e rimuovere completamente i bit di crittografia.

Questo è ciò che capisco dalla tua domanda.

• Accetti una password sul lato client
• Hai inserito casualmente la password.
• Hai cancellato la password sul client.
• Cifri l'hash utilizzando la chiave pubblica del server
• Invia l'hash crittografato al server
• Il server decodifica l'hash utilizzando la sua chiave privata & lo confronta con il suo hash memorizzato per verificare la validità.

Il problema qui è un attacco di replay. Chiunque origlia l'hash crittografato può riutilizzarlo.

La soluzione a questo può essere

1. Aggiungi l'ora corrente alla password sul lato client. Quindi cancellalo. Quando il server decodifica ciò che ottiene, divide prima il pacchetto in hash e amp; tempo. Solo se il tempo si trova entro + - delta dell'ora corrente, controlla la password. Ciò non consentirà di riutilizzare l'hash crittografato eavesdropped a meno che non venga utilizzato molto rapidamente.
2. Prendi lo schema precedente e aggiungi anche un numero ID alla stringa password + tempo. E poi hash, ecc. La responsabilità del server è quella di assicurarsi che un determinato numero ID non venga riutilizzato per un determinato cliente nello stesso giorno. La responsabilità del cliente è di assicurarsi che non riutilizzi lo stesso numero ID nello stesso giorno. Ciò impedirà un attacco di replay anche se fatto molto poco dopo l'evento.

Un componente molto importante qui è che il certificato del server (chiave pubblica) deve essere preinstallato sul client - non dovrebbe essere che il client ottiene il certificato richiedendolo dal server.