Come inviare password in modo sicuro tramite HTTP utilizzando Javascript in assenza di HTTPS?

Il problema fondamentale che tutti gli sviluppatori devono affrontare: ogni volta che l’utente invia il modulo, la password viene inviata tramite rete e deve essere protetta. Il sito che sviluppo non ha HTTPS. Nemmeno il proprietario desidera acquistare un certificato SSL, né è interessato a uno autofirmato. Quindi voglio proteggere la password inviata tramite HTTP utilizzando Javascript durante l’invio del modulo.

Per appassionati downvoters: come inviare password in modo sicuro su HTTP? NON fornisce alcuna soluzione ragionevole e sono in un’altra situazione.

Se uso MD5, è ansible invertire la stringa della password. Che dire di nonce / HMAC? Qualche libreria Javascript disponibile per questo? O hai qualche suggerimento / suggerimento da affrontare? Grazie in anticipo!

Non c’è modo di inviare una password in modo sicuro che l’utente possa verificare senza SSL.

Certo, puoi scrivere JavaScript che renderà sicura una password per la trasmissione over-the-wire tramite hashing o crittografia a chiave pubblica. Ma come può l’utente essere sicuro che lo stesso JavaScript non sia stato manomesso da un man-in-the-middle prima di raggiungerli, per inviare la password a un utente malintenzionato invece del sito, o anche solo a compromettere la sicurezza del algoritmo? L’unico modo per loro sarebbe di essere dei programmatori esperti e farli ispezionare ogni riga della tua pagina e script per assicurarti che fosse kosher prima di digitare la password. Questo non è uno scenario realistico.

Se si desidera che le password siano sicure dagli attacchi man-in-the-middle, è necessario acquistare un certificato SSL. Non c’è altro modo. Ci si abitua.

Se uso MD5, è ansible invertire la stringa della password.

No … non banalmente almeno. Mentre MD5 ha attacchi contro di esso, è un algoritmo di hashing e quindi non reversibile. Dovresti forza-forza.

Ma ancora, un attaccante uomo-in-centro non ha bisogno di guardare i tuoi MD5. Può semplicemente sabotare il codice JavaScript che si invia all’utente per creare gli MD5.

La soluzione qui è di non inviare la password. Usa sfida / risposta.

Nella forma originale include un grande blocco di testo casuale insieme a una chiave. Memorizza il testo casuale originale nella sessione in base alla chiave sul server. Quando il client invia il modulo, utilizzare JS per eseguire l’hash del testo e della password casuali insieme. Quindi inviare il nome utente, la chiave e l’hash del testo casuale al server. NON inviare la password. Sul server, utilizzare la chiave per cercare il testo casuale originale, eseguire la stessa operazione di hashing con la password memorizzata. Se il valore hash del server corrisponde al valore hash del client, si sa che il client ha inserito la password corretta senza mai inviare la password al server.

Indipendentemente dal fatto che la password sia corretta o meno, scadono la chiave e il testo casuale in modo che ciascuno sia utilizzabile una sola volta.

Se vuoi davvero approfondire questo, guarda lo scambio di chiavi Diffie-Hellman che è stato creato per “consentire a due parti che non hanno conoscenza l’una dell’altra per stabilire congiuntamente una chiave segreta condivisa su un canale di comunicazione non sicuro”

Non sono un esperto in crittografia, quindi non so se è davvero sicuro se un utente malintenzionato ha sia il client (codice sorgente JavaScript) che il meccanismo di trasporto (sniffer Packet)

È ansible utilizzare un’implementazione RSA javascript per crittografare la password prima dell’invio. (Ecco un esempio di RSA in Javascript .)

Ma credo che sia questo sia l’uso di una funzione di hash saranno vulnerabili agli attacchi di replay . Perciò stai attento.

Sfortunatamente non ci sarà alcun modo per garantire la sicurezza di una richiesta non crittografata. Chiunque abbia accesso al tuo javascript sarà semplicemente in grado di decodificarlo / manometterlo e chiunque abbia uno sniffer di pacchetti sarà in grado di vedere il traffico non criptato. Questi due fatti insieme significano:

Nessun SSL? Nessuna sicurezza.

Qualsiasi trasmissione che hai sarà in chiaro; cioè, senza SSL le tue informazioni critiche saranno esposte. Vale la pena discutere di questo punto con il proprietario del sito. In altre parole, è meglio prendere le misure necessarie per rafforzare la trasmissione dei dati, e SSL è uno dei passi fondamentali e poco costosi che puoi intraprendere.

Non penso che il problema qui sia la tecnologia, ma come spieghi l’importanza di SSL. Fornire loro materiali di lettura affidabili, sono sicuro che ci sono molti sul web.

La soluzione richiede che il client sia in grado di crittografare la password utilizzando una chiave di crittografia segreta nota solo al client e al server.

SSL lo fa richiedendo sia al server che al browser web client di avere una propria coppia di chiavi pubblica / privata asimmetrica, che usano per crittografare e trasmettere una chiave di sessione casuale tra loro. Il resto della conversazione utilizza quindi quella chiave di sessione sicura.

Quindi stai chiedendo come risolvere lo stesso problema di SSL senza il vantaggio di avere una chiave segreta che è nota solo al client e al server. Non sono esperto, ma sembra che questo non possa essere fatto, o almeno non facilmente.

Se non si ha accesso a SSL, MD5 dovrebbe essere adeguato per impedire la scoperta accidentale delle password (come in un file di registro di rete o qualcosa del genere). Qualsiasi altra cosa sarebbe una perdita di tempo. Assicurati che l’app non dia accesso a informazioni sensibili (ad es. Numeri di carte di credito, anamnesi, ecc.).

Come altri commentatori hanno suggerito, un aggressore serio sarà in grado di violare qualsiasi tipo di sicurezza sulla pagina. Anche SSL è una piccola barriera dal momento che la maggior parte degli utenti usa password facili da indovinare, riutilizza le stesse password ovunque, fornirà la propria password a chiunque richieda, o può essere indotta a rinunciare alla propria password da una pagina copiata o “tecnologia” supporto “telefonata.

– Inglese – Penso in qualcosa, ma non so se potrebbe essere davvero sicuro. Se è ansible inserire il modulo in un file php, è ansible creare un algoritmo per creare una stringa in base al tempo o in qualcos’altro, quindi inserire questa stringa nel proprio html.

Quando l’utente digita una password in un campo di immissione della password, quando esegui il debug non puoi vedere il valore digitato dall’utente, quindi prima di inviare le informazioni via posta o ottenere, puoi usare l’utente della password come suggerimento per crittografare la stringa crittografata previosly generato, e quindi, appena inviato insted della password digitata dall’utente.

In questo modo, gli hacker non hanno tutto all’interno del codice js, quindi avranno bisogno di scoprire l’algoritmo che si crea per decodificarlo.

Questa è solo un’idea, quindi se puoi dirmi come questo non può essere sicuro, lo apprezzerei.

– Spagnolo – Se me acaba de ocurrir algo que puede servir, pero no se si realmente mare algo seguro. Per mezzo di php puedes generar un algoritmo que cree un string en base al timestamp o algo más, y después colocar esta cadena en el html.

Nota que cuando alguien escribe una contraseña en un campo input tipo password, con un debug no se puede ver el valor que tecleo el usuario (no se si esista manera pero no quis investigar más), asi que podemos utilizar la contraseña que el usuario escribió como palabra clave para encriptar la cadena de texto que previamente habiamos generado con php, per medio di un algoritmo in JS. Sería algo así como encriptar lo encriptado. Posteriormente lo stato di conservazione non è mai stato usato per la precisione.

Buscando un contra, lo ònico mi ha guardato molto bene e mi è piaciuto moltissimo tempo per tratar de encontrar el agoritmo que creamos per medio de php e poder decriptar la cadena final, o per chi ha fatto il servidor per il pubblico e per il pubblico el algoritmo.

Esprime solo un’idea, per quanto riguarda il decennio in cui si parla di sé, se si agradecería.

Come accennato, nessuno di questi è sicuro contro lo spoofing del server , poiché ciò richiede la capacità di fidarsi del Javascript sul lato client. Ma se siamo sicuri che il server non possa essere falsificato (firma firmata, hash signing immune all’estensione della lunghezza, ecc.) Ma non che la connessione sia immune agli intercettatori, ecco come la implementerei.

Penso che il modo più sicuro sia, invece di memorizzare H ( password ), dove H è la tua funzione hash di scelta, memorizzare g ^ H ( password ), cioè utilizzare la password come chiave privata per lo scambio di chiavi Diffie-Hellman. (Probabilmente dovresti usare anche un g casuale per diversi utenti – diventa il tuo sale.) Quindi per verificare, si genera un nonce b, si invia l’utente g ^ b e si computa (g ^ H ( password )) ^ b. L’utente non ha bisogno di sapere g – hanno bisogno solo di calcolo (g ^ b) ^ H ( password ) = (g ^ H ( password )) ^ b. Ora avete un numero che entrambe le parti sanno che se l’utente ha inserito la password corretta e la costruzione di una prova di zero-conoscenza basata sulla sfida di conoscenza del numero corretto è banale, mentre il numero casuale usato come “chiave privata” del server rende approccio immune agli attacchi replay.