Prima di tutto, cerca di capire come funziona l'autenticazione SSL (HTTPS) e HTTP.
I soliti metodi di autenticazione HTTP (Digest, Basic e qualsiasi modulo + schema di autenticazione basato su cookie che puoi implementare su HTTP) sono tutti insicuri da soli, perché inviano più o meno informazioni di autenticazione in chiaro. A prescindere dal fatto che i dati si trovino nei campi o nelle intestazioni POST e che venga applicata la codifica base64, la questione è chiaramente visibile a chiunque abbia accesso al traffico di rete. Ciò significa che l'autenticazione HTTP su un canale non attendibile è inutile: tutto ciò che serve a un utente malintenzionato per leggere la password è un po 'di sniffing della rete.
SSL implementa un canale di comunicazione sicuro su un canale intrinsecamente insicuro. Funziona approssimativamente come segue:
- Il server invia un certificato firmato
- Il client convalida il certificato in base a un elenco di chiavi di firma note valide; le firme dei certificati possono essere concatenate, in modo che ogni nodo dica "se la firma che mi firma è buona, allora lo sono anch'io", ma alla fine la catena deve risolversi in una delle poche autorità fidate preconfigurate sul client.
- Il client utilizza la chiave di crittografia pubblica del server per inviare un segreto condiviso
- Il server decodifica il segreto condiviso usando la chiave privata (poiché solo il server legittimo ha la chiave privata, gli altri server non saranno in grado di decrittografare il segreto condiviso)
- Il client invia i dati della richiesta effettiva, crittografati utilizzando il segreto condiviso
- Il server decodifica i dati richiesti, quindi invia una risposta crittografata
- Il client decodifica la risposta e la presenta all'utente.
Nota alcuni punti importanti qui:
- La catena di certificati consente ai client di assicurarsi che il server con cui stanno parlando sia quello reale, non qualcuno che intercetta le loro richieste. Ecco perché dovresti acquistare un vero certificato SSL e perché i browser ti lanciano avvisi 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 scambiare il segreto assicura che la comunicazione riuscita funzionerà solo tra questa particolare coppia di client e server: i pacchetti di rete sniffati saranno 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 sovraccarico di prestazioni molto inferiore rispetto alla crittografia a chiave privata / pubblica. La chiave (segreto condiviso) viene scambiata utilizzando la crittografia della chiave privata / pubblica, poiché è l'unico modo per farlo in modo sicuro (tranne per il trasporto su un canale separato, ad esempio un servizio di corriere).
Quindi, ovviamente, ci sono alcune spese generali, ma non è così male come si potrebbe pensare - è principalmente nella scala in cui "lanciare più hardware" è la risposta appropriata, a meno che non si stia preparando per quantità di traffico assolutamente enormi ( pensa a Google o Facebook). In circostanze normali, vale a dire l'utilizzo tipico delle applicazioni Web, l'overhead 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 possibile per proteggere il traffico HTTP; altri metodi semplicemente non sono così standardizzati e quindi non ampiamente supportati, e tu non vuoi assolutamente implementare queste cose da solo, perché onestamente, è semplicemente troppo facile sbagliarle.
TL; DR: Sì, l'autenticazione SSL + di base è una buona idea, sì, hai bisogno di un server sicuro (e un certificato valido ), sì, rallenterà un po 'le cose, ma no, questo non è qualcosa di cui preoccuparsi, giusto adesso.