Quanto è sicuro l'invio di dati sensibili tramite https?

Question

SSL è abbastanza sicuro per usare dati sensibili (come password) nella stringa di query? Esistono opzioni extra da implementare?

Answer 1

SSL fornisce sicurezza sicura a livello di trasporto . Nessuno tra client e server dovrebbe essere in grado di leggere le informazioni.

Ma dovresti cambiare idea sulla scrittura di dati sensibili nella stringa di query . Verrà visualizzato nella cronologia del browser ed è visibile nella barra degli indirizzi del browser e nei registri sul server. Vedi questo articolo: Quanto sono sicure le query Stringhe su HTTPS?

Se l'utilizzo delle stringhe di query è l'unica opzione (ne dubito), ecco un articolo interessante sulla protezione delle stringhe di query .

Answer 2

SSL è sicuro, ma ricorda che qualsiasi crittografia può essere interrotta se viene concesso tempo e risorse sufficienti. Dato che non sai quali pacchetti contengono una password e quali no, dovresti decrittografare tutto il traffico crittografato per trovare quello giusto. Questo è intrattabile nel caso generale.

Tuttavia, un modulo di accesso avrà bisogno di un input [tipo = testo] per inserirlo. Ci vorrebbe del lavoro per "decomprimere" questo e trasformare la richiesta in una richiesta GET HTTP utilizzando stringhe di query anziché un POST con i dati nei parametri del modulo. Non riesco a immaginare perché qualcuno dovrebbe farlo. Una volta che la password è stata fornita dall'utente (e l'utente autenticato), utilizzare il fatto di autenticazione anziché mantenere la password. Se è necessario conservare la password, per la rappresentazione, ad esempio, conservarla sul lato server e preferibilmente in una stringa protetta. Se stai provando a fare il single sign-on (inserisci il mio ID / password una volta per molti siti), usa una sorta di servizio di autenticazione centrale (CAS) - OpenID, WindowsLive - o implementa il tuo.

Meno volte una password attraversa il filo, meglio è.

E c'è sempre la barra di posizione del browser da considerare che sosterrebbe che è necessario crittografare e codificare tutti i dati sensibili inseriti nelle stringhe di query come menzionato in precedenza.

Answer 3

I dati sensibili nella stringa di query sono una cattiva idea, i passanti occasionali possono vedere la stringa di query e ci sarebbe la tentazione di aggiungere un segnalibro che in realtà non è sicuro.

SSL è abbastanza sicuro, se fai internet banking e ti fidi di esso, allora SSL sarà abbastanza buono anche per te.

Answer 4

accetta che SSL sia sicuro * ish e il problema delle query

ricorda che ci sono limitazioni su SSL -

assicurarsi che il certificato sia certificato come root.

alcune macchine Windows 2000 devono avere uno sp applicato per far funzionare ssl a 128 bit, se non è lì va a 40 bit o non carica (se ricordo bene)

Alcuni firewall software come ISA - dove pubblichi il sito sicuro e ti certene all'interno - agiscono come un uomo nel mezzo.

Sicuro su ISA e poi su Sicuro su LAN. ma il grande aspetto qui è "allora" come ISA effettuerà il log, la registrazione è un problema in quanto è possibile visualizzare la password sulla stringa di query e sul post, il che significa che chiunque (amministratore) può vedere ...

Quindi cerca algoritmi di hashing sicuri nella tua lingua per eseguire semplicemente l'hashing della password.

Answer 5

Non esiste "abbastanza sicuro", la sicurezza non è una cosa statica con una proprietà bool che è falsa o vera.

SSL è buono, ma dipende da quanto è sicura la chiave privata sul lato server, da quanti bit ha la chiave, dall'algoritmo utilizzato, da quanto sono affidabili i certificati utilizzati, ecc ....

Ma se si utilizza SSL almeno tutti i dati trasmessi sono crittografati (tranne l'IP di destinazione perché utilizzato per instradare il pacchetto).

Un altro punto da considerare è: se si inserisce manualmente la stringa di query della password nel browser, questa potrebbe finire nella cache del browser locale (in un file locale completamente non crittografato). Quindi meglio usare POST e non OTTENERE la meccanica di trasferimento.

Se sei veramente interessato alla sicurezza, ti consiglio ulteriori ricerche su questo argomento, perché spesso l'algoritmo non è il punto debole della sicurezza.

Answer 6

Sì, è abbastanza sicuro. Sebbene io sia d'accordo che di solito non è una buona idea avere cose come quella in una stringa di query, va bene se non è una stringa di query che verrà mostrata nella barra degli indirizzi. Se viene visualizzato nella barra degli indirizzi per ovvi motivi, si perde un livello di sicurezza (persone che camminano, ecc.)

Answer 7

L'ispettore SSL può aprire i traffici ssl http: // www.ssl-inspector.com/files/file/SSL%20Inspector%20Appliance%20Product%20Brief%20(2-11).pdf

Answer 8

non devi mai inviare nulla di particolarmente critico usando le stringhe di query!

Answer 9

Non si dovrebbero inviare password con hash? - non importa se sbaglio.

SSL è praticamente la maggior sicurezza che puoi ottenere.

Answer 10

I certificati autofirmati sono certificati SSL creati e firmati da te. Ciò significa che non è necessaria un'autorità di certificazione di terze parti (CA) per firmare il certificato, ma significa che i browser, per impostazione predefinita, emetteranno un avviso, poiché un certificato autofirmato non può in modo affidabile (il tuo browser ha un elenco di autorità di certificazione attendibili) verifica che il firmatario del certificato sia esattamente ciò che dice il certificato.

Considera la situazione in cui crei un certificato SSL " per conto di " una certa società di software basata su Redmond. Ora, se il tuo server HTTP presenta quel certificato, che hai autofirmato, a un client, l'agente utente avviserà che questo certificato potrebbe non essere effettivamente quello che dice che è. Un'autorità di certificazione verificherà - per mezzo di documenti cartacei, il vero e proprio tipo di albero morto - l'identità della parte che richiede la firma, quindi è attendibile.

Spero che questo aiuti.