L'autenticazione su HTTPS rallenterà la mia applicazione?

11

Sto creando un'applicazione web e un servizio web RESTful.

Ho letto vari articoli sul modo migliore per autenticare le richieste al servizio web.

L'opzione migliore per me sembra essere quella di utilizzare l'autenticazione di base HTTP. Praticamente tutti gli articoli in questione dicono che l'autenticazione dovrebbe essere crittografata su SSL o equivalente.

Non sono completamente sicuro di ciò che questo comporta. Questo significa che il mio intero servizio web dovrà essere su un server sicuro? Questo rallenterà le cose?

    
posta Gaz_Edge 05.02.2013 - 16:57
fonte

7 risposte

11

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:

  1. Il server invia un certificato firmato
  2. 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.
  3. Il client utilizza la chiave di crittografia pubblica del server per inviare un segreto condiviso
  4. 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)
  5. Il cliente invia i dati della richiesta effettiva, crittografati utilizzando il segreto condiviso
  6. Il server decodifica i dati della richiesta, quindi invia una risposta crittografata
  7. 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.

    
risposta data 05.02.2013 - 20:35
fonte
12

HTTPS (SSL) non è l'autenticazione dell'utente FYI. Fornisce solo la crittografia tra 2 endpoint.

Ma sì, c'è una piccola quantità di overhead da esso (anche se non abbastanza da giustificare un cambiamento nei piani / hardware). Vedi qui:

link

    
risposta data 05.02.2013 - 17:01
fonte
6

Con l'autenticazione di base HTTP, il nome utente e la password forniti dall'utente vengono inviati ad ogni richiesta al server. Ciò significa che sono in chiaro anche nelle aree del tuo sito che non devono necessariamente essere sicuri. Ovviamente, ti consigliamo SSL qui per mantenere al sicuro i tuoi utenti.

In teoria, è possibile utilizzare l'autenticazione dei cookie e inserire solo SSL nella pagina di accesso (dove vengono inviati nome utente e password). Se i tuoi cookie sono decentemente protetti e sicuri contro gli attacchi di replay, allora un utente malintenzionato non sarebbe in grado di fare nulla con loro anche se fosse riuscito a ottenerne uno.

    
risposta data 05.02.2013 - 17:00
fonte
3

L'autenticazione di base sta impostando un nome utente e una password nell'intestazione della richiesta http. Se non si utilizza SSL o equivalente, quel nome utente e password vengono inviati in formato testo e sono banali da rubare a chiunque.

Oggigiorno la maggior parte dei server Web supporta HTTPS e, sebbene aggiunga un sovraccarico a ogni chiamata, l'overhead è minimo.

È possibile proteggere alcuni endpoint e non altri (ovvero disporre di un endpoint autenticato che produce un token che può essere utilizzato per altre chiamate). Raccomanderei strongmente SSL per l'intero servizio anche se è molto più sicuro. (se non altro, impedisce che i dati sensibili vengano intercettati)

    
risposta data 05.02.2013 - 17:15
fonte
2

Jeff Atwood ha scritto un breve blogpost non tanto tempo fa su se la crittografia completa è la strada da percorrere. Descrive alcuni esempi del mondo reale e ha alcune linee anche su considerazioni relative alle prestazioni.

Inoltre, fa riferimento a questo articolo su un caso di studio Gmail, citando quanto segue :

In January this year (2010), Gmail switched to using HTTPS for everything by default. Previously it had been introduced as an option, but now all of our users use HTTPS to secure their email between their browsers and Google, all the time. In order to do this we had to deploy no additional machines and no special hardware. On our production frontend machines, SSL/TLS accounts for less than 1% of the CPU load, less than 10KB of memory per connection and less than 2% of network overhead. Many people believe that SSL takes a lot of CPU time and we hope the above numbers (public for the first time) will help to dispel that.

Egli menziona anche alcuni miglioramenti recenti del caching delle pagine lato client tramite HTTPS da il browser .

Nonostante ciò, sottolinea, ci sono altre sanzioni, molte delle quali non sono prestazioni ma costi di implementazione:

  • Mantenimento della qualità del software e complessità addizionale per i team già occupati,
  • Il caching del proxy è molto più difficile da configurare correttamente e richiede anche modifiche al codice,
  • È difficile ottenere la sicurezza giusta per un mashup di contenuti provenienti da fonti diverse,
  • I dispositivi mobili di fascia bassa potrebbero avere problemi con la crittografia.
risposta data 05.02.2013 - 19:08
fonte
0

L'autenticazione di base HTTP senza la tua gestione della sessione probabilmente ti lascerà aperto agli attacchi di falsificazione delle richieste tra i siti. Probabilmente puoi usarlo se accetti la tua gestione della sessione, ma potresti avere problemi a fornire una funzione di "disconnessione" pulita.

Indipendentemente da ciò che utilizzi per l'autenticazione, dovrai utilizzare HTTPS per crittografare la connessione (a meno che l'applicazione web sia accessibile solo su una rete controllata e sicura). Potrebbe rallentare un po 'le cose (gli stabilimenti di connessione sono costosi, ma i browser tendono a mantenere le connessioni per un po'), ma se vuoi un'applicazione sicura, non sarai in grado di evitare comunque, quindi non devi preoccuparti di questo.

Nota: "L'autenticazione HTTPS" (che hai citato nel titolo) è fuorviante - potrebbe riferirsi all'autenticazione del certificato client SSL, che ha poco a che fare con il testo della tua domanda e ha il suo set di vantaggi e problemi. Probabilmente non vuoi toccarlo.

    
risposta data 05.02.2013 - 21:01
fonte
0

Come riuscirai a realizzare l'autenticazione di base?
Se si tratta di un nome utente / password hard coded e si sta utilizzando la funzionalità integrata del server web per farlo, probabilmente avrà un impatto quasi nullo. Se stai facendo cose pazze in un database o qualcosa di simile, allora sì, ci potrebbe essere un impatto.

Come altri hanno notato qui, SSL e amp; l'invio di intestazioni extra tecnicamente renderà le cose più lente ma non sarà significativo in alcun modo.

    
risposta data 06.03.2014 - 21:52
fonte

Leggi altre domande sui tag