Prima di tutto, prova a capire come funzionano l'autenticazione SSL (HTTPS) e HTTP.
I soliti metodi di autenticazione HTTP (Digest, Basic e qualsiasi altro schema di autenticazione basato su cookie che puoi implementare su HTTP) sono tutti insicuri da soli, perché inviano informazioni di autenticazione più o meno in testo chiaro. Indipendentemente dal fatto che i dati siano nei campi POST o nelle intestazioni e che sia applicata la codifica base64, a questo proposito la password è chiaramente visibile a chiunque abbia accesso al traffico di rete. Ciò significa che l'autenticazione HTTP su un canale non attendibile è priva di valore: tutto ciò che serve a un utente malintenzionato per leggere la tua password è un po 'di sniffing della rete.
SSL implementa un canale di comunicazione sicuro su un canale intrinsecamente insicuro. Questo funziona, grosso modo, come segue:
- Il server invia un certificato firmato
- Il client convalida il certificato rispetto a un elenco di chiavi di firma conosciute; le firme dei certificati possono essere concatenate, in modo che ogni nodo dica "se la firma che mi firma è buona, quindi lo sono anch'io", ma alla fine la catena deve risolversi in una delle poche autorità affidabili preconfigurate sul client.
- Il client utilizza la chiave di crittografia pubblica del server per inviare un segreto condiviso
- Il server decodifica il segreto condiviso utilizzando la chiave privata (poiché solo il server legittimo ha la chiave privata, altri server non saranno in grado di decodificare il segreto condiviso)
- Il cliente invia i dati della richiesta effettiva, crittografati utilizzando il segreto condiviso
- Il server decodifica i dati della richiesta, quindi invia una risposta crittografata
- Il client decrittografa la risposta e la presenta all'utente.
Nota alcuni punti importanti qui:
- La catena di certificati consente ai clienti di assicurarsi che il server con cui stanno parlando sia quello reale, non qualcuno che intercetta le loro richieste. Questo è il motivo per cui dovresti acquistare un vero certificato SSL e perché i browser ti lanciano degli avvertimenti spaventosi quando colpisci un sito che utilizza un certificato non valido, scaduto o altrimenti errato: tutta la crittografia nel mondo non aiuta se sei parlando con la persona sbagliata.
- La crittografia pubblica / privata utilizzata per lo scambio del segreto garantisce che la comunicazione riuscita funzionerà solo tra questa particolare coppia di client e server: i pacchetti di rete sniffati verranno crittografati e richiederanno la chiave privata del server per ottenere i dati .
- La crittografia simmetrica viene utilizzata per la maggior parte della richiesta, poiché ha un overhead delle prestazioni molto più basso rispetto alla crittografia delle chiavi privata / pubblica. La chiave (segreto condiviso) viene scambiata usando la crittografia a chiave privata / pubblica, perché questo è l'unico modo per farlo in modo sicuro (tranne il trasporto su un canale separato, come un servizio di corriere).
Quindi, ovviamente, ci sono alcune spese generali, ma non è così male come penseresti: è soprattutto sulla scala in cui "lanciare più hardware" è la risposta appropriata, a meno che non ti stia preparando per importi assolutamente massicci di traffico (pensa a Google o Facebook). In circostanze normali, vale a dire, l'utilizzo tipico delle applicazioni Web, il sovraccarico SSL è trascurabile e, di conseguenza, non appena si dispone di dati riservati, è meglio eseguire tutto su SSL, comprese le risorse. SSL è anche l'unico modo valido per proteggere il traffico HTTP; altri metodi semplicemente non sono standardizzati e quindi non ampiamente supportati, e tu non vuoi assolutamente implementarli tu stesso, perché onestamente, è semplicemente troppo facile sbagliarli.
TL; DR: Sì, l'autenticazione di base SSL + è una buona idea, sì, è necessario un server sicuro (e un certificato valido ), sì, lo sarà rallenta un po 'le cose, ma no, non è qualcosa di cui preoccuparsi adesso.