Attualmente sto lavorando su un provider PHP OpenID che funzionerà su HTTPS (quindi crittografato con SSL).
È sbagliato per me trasmettere la password come testo normale? HTTPS in teoria non può essere intercettato, quindi non vedo nulla di sbagliato. O questo è pericoloso a un certo livello e non riesco a vederlo?
Risposte:
È sicuro. È così che funziona l'intero web. Tutte le password nei moduli vengono sempre inviate in testo normale, quindi spetta a HTTPS proteggerle.
Devi comunque assicurarti di inviarlo tramite richiesta POST, non GET. Se lo invii tramite richiesta GET, potrebbe essere salvato come testo normale nei log della cronologia del browser dell'utente o nei log di accesso del server web.
Se HTTP è disabilitato e utilizzi solo HTTPS, non stai comunque trasmettendo la password come testo normale.
Hash lato client. Perché? Lascia che ti parli di un piccolo esperimento. Avvicinati al computer nella mensa aziendale. Aprire il browser alla pagina di accesso al sito Web dell'azienda (https). Premere F12, fare clic sulla scheda di rete, selezionare il registro persistente, ridurre a icona la console ma lasciare la pagina Web aperta alla pagina di accesso. Siediti e pranza. Guarda come dipendente dopo che il dipendente accede al sito Web dell'azienda e, essendo un bravo piccolo lavoratore, si disconnette al termine. Termina il pranzo, siediti al computer, apri la scheda di rete e vedi ogni singolo nome utente e password in testo normale nella forma bodys.
Nessuno strumento speciale, nessuna conoscenza speciale, nessun hardware di hacking, nessun keylogger solo il buon vecchio F12.
Ma hey, continua a pensare che tutto ciò di cui hai bisogno è SSL. I cattivi ti ameranno per questo.
Prendiamo alcune note alle risposte precedenti.
In primo luogo, probabilmente non è la migliore idea utilizzare algoritmi hash lato client. Se la tua password è salata sul lato server, non sarai in grado di confrontare gli hash (almeno non se non archivi l'hash del client nel database in uno dei livelli di hashing della password, che è lo stesso o peggio). E non vuoi implementare l'algoritmo di hashing utilizzato dal database sul lato client, sarebbe sciocco.
In secondo luogo, nemmeno il trading di chiavi crittografiche non è l'ideale. Il MITM potrebbe teoricamente (considerando che ha un certificato di root installato sul client) modificare le chiavi crittografiche e modificarle con le proprie chiavi:
Connessione originale (non considerando tls) da un server teorico che scambia le chiavi:
Il client richiede le chiavi pubbliche> il server detiene le chiavi private, genera le chiavi pubbliche al client> il server invia le chiavi pubbliche al client
Ora, in una traccia teorica MITM:
Il client richiede le chiavi pubbliche> MITM genera chiavi private false > Il server detiene le chiavi private, genera chiavi pubbliche per il client> MITM riceve le chiavi pubbliche dal server originale, ora siamo liberi di inviare le nostre chiavi pubbliche false al client e ogni volta che una richiesta arriva dal client, decifreremo i dati del client con le chiavi false, cambieremo il payload (o lo leggeremo) e crittograferemo con le chiavi pubbliche originali > MITM invia chiavi pubbliche false al client.
Questo è il punto di avere un certificato CA attendibile in TLS, ed è così che ricevi un messaggio di avviso del browser se il certificato non è valido.
In risposta all'OP: a mio modesto parere non puoi farlo, perché prima o poi qualcuno vorrà attaccare un utente dal tuo servizio e proverà a violare il tuo protocollo.
Quello che puoi fare, tuttavia, è implementare 2FA per impedire alle persone di tentare di accedere con la stessa password. Beaware di replay attack, però.
Non sono bravo con la crittografia, per favore correggimi se sbaglio.
Gli altri poster sono corretti. Ora che stai utilizzando SSL per crittografare la trasmissione della password, assicurati di eseguirne l'hashing con un buon algoritmo e sale in modo che sia protetto anche quando è a riposo ...
L'esempio @CodeDog presenta problemi ..
Sì, posso credere che gli utenti accederanno a un box della caffetteria. Se stai acquisendo i registri da una caffetteria aziendale, allora sei la violazione della sicurezza. Le caselle delle caffetterie aziendali dovrebbero essere impostate disabilitate, ad esempio nessun termine, nessun logger, nessun accesso remoto, ecc. Per prevenire te, hacker interno.
L'esempio è buono per la sicurezza dell'accesso al computer e non è realmente correlato alla sicurezza della rete. Viene fornito come giustificazione per l'hashing lato client, ma se hai accesso al computer puoi semplicemente usare un registratore di tasti e aggirarlo. L'hash lato client è di nuovo irrilevante. L'esempio di @CodeDog è un hack per l'accesso al computer e richiede tecniche diverse dagli hack a livello di rete.
Inoltre, un attacco informatico pubblico è protetto paralizzando il sistema dalle minacce, come menzionato sopra. ad esempio, usa un Chromebook per un computer di una caffetteria pubblica. Ma questo è bypassato da un fisico hack . Durante le ore libere, vai alla caffetteria e imposta una telecamera segreta per registrare le pressioni della tastiera da parte degli utenti. Quindi non importa se il computer della caffetteria è paralizzato, O che tipo di crittografia viene utilizzato.
livello fisico -> livello computer -> livello client -> livello rete -> livello server
Per il networking, non importa se si esegue l'hash sul lato client perché il livello https / ssl crittograferà il semplice passwd. Quindi, come altri menzionano, l'hashing del client è ridondante se il TLS è sicuro.