Domanda:
L'autenticazione BASIC è sicura se eseguita tramite HTTPS?
Morten
2010-12-06 04:42:45 UTC
view on stackexchange narkive permalink

Sto creando un'API REST ed è semplice eseguire l'accesso con l'autenticazione BASIC. Quindi lascia che HTTPS protegga la connessione in modo che la password sia protetta quando viene utilizzata l'API.

Può essere considerato sicuro?

Sì, l'utente / pass http andrà bene poiché supera SSL, ma la password deve essere complessa.
Bene, potrei inserire una logica nel mio server che vieta un client che tenta troppe password. Ciò impedirebbe DoS e indovinare la password?
Nove risposte:
#1
+303
AviD
2010-12-06 05:18:48 UTC
view on stackexchange narkive permalink

Ci sono alcuni problemi con l'autenticazione di base HTTP:

  • La password viene inviata via cavo nella codifica base64 (che può essere facilmente convertita in testo normale).
  • La password viene inviata ripetutamente, per ogni richiesta. (Finestra di attacco più ampia)
  • La password viene memorizzata nella cache dal browser web, almeno per la lunghezza della finestra / processo. (Può essere riutilizzato silenziosamente da qualsiasi altra richiesta al server, ad esempio CSRF).
  • La password può essere memorizzata in modo permanente nel browser, se l'utente lo richiede. (Come il punto precedente, inoltre potrebbe essere rubato da un altro utente su una macchina condivisa).

Di questi, l'uso di SSL risolve solo il primo. E anche con questo, SSL protegge solo fino a quando il server web - qualsiasi instradamento interno, registrazione del server, ecc. Vedrà la password in chiaro.

Quindi, come per qualsiasi cosa, è importante guardare l'intero quadro.

HTTPS protegge la password in transito? Sì.

È sufficiente? Di solito no. (Voglio dire, sempre no, ma dipende davvero da cosa è il tuo sito e da quanto deve essere sicuro.)

in realtà, anche con HTTP Digest, potresti essere in grado di creare un hash della password (`md5 (username: realm: password)`, a volte chiamato HA1).
@AviD ♦ Imho i tuoi punti 3) e 4) sono raramente validi per le API REST.
In caso di autenticazione di base, la password "deve essere" memorizzata nel browser, operazione che può essere eseguita solo tramite un cookie, che non può mai essere considerato sicuro. Ho pubblicato una domanda simile qui: http://stackoverflow.com/questions/27177224/how-to-keep-state-at-the-client-safely/27177995#27177995 La mia conclusione è stata che l'autenticazione di base NON è sicura, NON dovrebbe essere usato come tale e che la memorizzazione di dati sensibili sul client (come una password utente) non dovrebbe nemmeno essere considerata.
@KimGysen per Basic Auth, la password NON viene trasmessa o memorizzata in un cookie, viene inviata nell'intestazione della richiesta `Autorizzazione:`, e memorizzata in una parte speciale (protetta) della memoria del browser. Non che io sia in disaccordo con te, nel caso generale Basic Auth non dovrebbe essere usato, tuttavia ci sono alcune situazioni in cui il compromesso potrebbe essere praticabile.
Il secondo punto non è un problema. L'invio di credenziali a ogni richiesta mantiene il tuo backend senza stato.
Oltre alla "finestra di attacco più ampia", non esiste un meccanismo integrato come il blocco dell'account per la protezione contro la forzatura bruta.
@Artjom: L'invio di credenziali di base su ogni richiesta è un problema, non perché devi continuare a inviare le credenziali, ma piuttosto perché la stessa stringa viene inviata a ogni richiesta. Esistono altri meccanismi di autenticazione, come HMAC, in cui l'intestazione di autorizzazione non può essere decrittografata nel segreto dell'utente e il server può autenticare la richiesta senza conoscere effettivamente il segreto dell'utente. In questo meccanismo, la stringa inviata nell'intestazione di autorizzazione cambia in base all'hash della richiesta.
@LieRyan Onestamente non capisco: - \. Qual è il problema con l'invio della stessa stringa? È perché la varietà è il sale della vita?
@DavidS: replay attack. Inoltre, se si passa il traffico attraverso un proxy o un servizio CDN, si ha la certezza che un utente malintenzionato non possa attaccare il proxy / CDN per modificare le richieste dell'utente.
@Bruno, HTTP Digest è * peggiore * perché richiede al server di memorizzare le password degli utenti in testo normale!
@Jacco In linea di principio, il server potrebbe memorizzare solo `md5 (username: realm: password)` e non richiedere la password in chiaro (puoi controllare il contenuto di un file generato con `htdigest` per esempio).Questo dipende dall'implementazione.Detto questo, non è ancora eccezionale (anche con lo svantaggio di essere facilmente vulnerabile agli attacchi di downgrade a Basic).
"Finestra di collegamento più grande" Quindi il normale token di sessione che invia come cookie ha anche il problema simile, giusto?
@JithinJose che non includerebbe la password dell'utente, né è statico + valido per un tempo molto lungo.
@LieRyan HMAC non è uno dei meccanismi di autenticazione HTTP standard, a differenza di Basic e Digest.Stavi parlando di [quello implementato da AWS] (https://docs.aws.amazon.com/en_us/AmazonS3/latest/dev/RESTAuthentication.html#ConstructingTheAuthenticationHeader)?
@LieRyan: Sia la riproduzione che lo scenario proxy / CDN non sono possibili con TLS, a meno che TLS non abbia un difetto.
#2
+91
Nemo
2012-07-15 08:27:07 UTC
view on stackexchange narkive permalink

Prova a pensarla in questo modo: quando accedi a qualsiasi sito web utilizzando SSL, molto probabilmente stai passando la password in testo normale su HTTPS (ad esempio GMail).

L'unica differenza che Basic-Auth fa è che nome utente / password venga passato nelle intestazioni della richiesta invece che nel corpo della richiesta (GET / POST).

Come tale, usando basic-auth + https non è né meno né più sicuro di un'autenticazione basata su form su HTTPS.

C'è una leggera differenza tra queste situazioni: con l'autenticazione di base http la password viene inviata per * ogni richiesta *, mentre con un login basato su form viene inviata solo una volta e poi viene utilizzato qualcosa come un cookie di sessione. Questo * leggermente * riduce la superficie di attacco.
La password dell'utente viene inviata una sola volta ma anche il cookie di autenticazione viene inviato ad ogni richiesta, quindi la domanda è solo di inviare l'utente e la password anziché l'autenticazione del cookie
@deFreitas e quindi hai la premessa di OAuth: utilizzare un altro token per l'autenticazione invece di inviare sempre u / p.
Penso che ci sia più di una leggera differenza: nell'esempio POST del modulo, il rendering della pagina iniziale deve essere inviato tramite HTTPS prima che l'utente decida di inserire le proprie credenziali e POST (in modo sicuro). Con l'autenticazione di base HTTP, anche se il server rifiuta di servire una richiesta non HTTPS e reindirizza a HTTPS, le credenziali sono già passate in modo insicuro e sono quindi venerabili per lo snooping di MiTM. Il cliente deve decidere di POST HTTPS inizialmente o rischiare un canale non sicuro. Ciò è meno probabile con lo scenario POST del modulo.
@PepijnSchmitz Vorrei notare che la differenza di una chiave di sessione (che può essere invalidata) è enormemente diversa dal furto delle credenziali di accesso.Il danno può ancora essere inflitto mentre un'altra parte ha la tua chiave di sessione privata, ma è di natura molto più limitata, soprattutto perché puoi far disconnettere la tua applicazione dall'API al termine dell'esecuzione per invalidare la chiave.
#3
+23
goodguys_activate
2010-12-06 11:49:54 UTC
view on stackexchange narkive permalink

L'autenticazione di base su HTTPS è buona, ma non del tutto sicura. In modo simile a come funziona Fiddler per il debug SSL, un proxy HTTPS aziendale gestisce la connessione tra il browser web e il proxy (il cui indirizzo IP appare nei log del tuo server web). In tal caso, la password HTTPS viene decrittografata e successivamente nuovamente crittografata nel proxy aziendale.

A seconda di chi gestisce il proxy e di come vengono utilizzati i suoi log, questo può essere accettabile o essere un problema dal tuo punto di vista.

Per ulteriori informazioni su come viene eseguita l'intercettazione SSL , vedi questo link:

Quando il proxy SSL intercetta una connessione SSL, presenta un certificato del server emulato al browser del client. Il browser client invia un popup di sicurezza all'utente finale perché il browser non si fida dell'emittente utilizzato da ProxySG. Questo popup non si verifica se il certificato dell'emittente utilizzato da SSL Proxy viene importato come radice attendibile nell'archivio certificati del browser client.

ProxySG rende tutti i certificati configurati disponibili per il download tramite la sua console di gestione. Puoi chiedere agli utenti finali di scaricare il certificato dell'emittente tramite Internet Explorer o Firefox e installarlo come CA attendibile nel browser preferito. Questo elimina il popup del certificato per i certificati emulati ...

Alcune aziende aggirano il problema del pop-up del certificato menzionato sopra distribuendo i certificati radice (del Proxy) su ogni workstation tramite GPO. Sebbene ciò interesserà solo il software che utilizza l'archivio certificati Microsoft. Software come Firefox deve essere aggiornato in modo diverso.

In realtà questo dipende dal sito di cui parli. Per esempio. se stai navigando nella tua banca dal lavoro e usano l'autenticazione di base, non viene decrittografato dal proxy al tuo lavoro. SSL passa proprio attraverso quello.
Questo non ha senso per me: a quale scenario stai pensando? I proxy non possono vedere cosa c'è all'interno di una sessione https, se il browser lo ha configurato con l'endpoint effettivo, correttamente autenticato con un buon certificato (o DNSSEC o altro).
Il votante negativo dovrebbe leggere la documentazione collegata, poiché questo è un punto reale e valido che non è ampiamente noto. Documenti: http://www.bluecoat.co.jp/downloads/manuals/SGOS_DG_4.2.x.pdf
Sì, hai ragione: BlueCoat sembra un malware aziendale, che utilizza FUD per rendere insicuro il business.
E a proposito: Chrome utilizza l'Archivio certificati di Windows ...
Qualche anima gentile dovrebbe dare un voto positivo a questa risposta, quindi non è più (-1) Questa risposta contiene informazioni vere e fattuali
@AViD, ci sono alcuni casi in cui i proxy aziendali in realtà _do_ decrittografano il traffico SSL, presentando il proprio certificato (che è firmato da un certificato aziendale interno che viene importato come certificato di autorità radice attendibile su tutte le workstation aziendali). La mia azienda lo fa per alcuni siti, incluso Gmail (ma non per i siti bancari). Funziona e spesso è invisibile agli utenti perché l'azienda gestisce anche i desktop / browser. Nota che Strict Transport Security (HSTS) può sconfiggerlo ... è stato l'avvertimento HSTS di Firefox che mi ha avvisato in primo luogo!
@MichaelLucas - sì, vedere i commenti precedenti riguardanti BlueCoat (un popolare malware, erm, fornitore di software in questo spazio). Come ho sottinteso, questo è un anti-pattern, con numerosi svantaggi (ad esempio l'utente non ha indicazioni su certificati server non validi o problematici ... e questo oltre ai problemi di privacy)
@MichaelLucas Per quanto ne so, se lo fanno correttamente, l'HSTS non può sconfiggerlo, puoi approfondire come l'HSTS lo affronta? Penso che te ne accorgeresti se guardassi effettivamente la catena di certificati nel tuo browser e inizierai a chiederti perché la tua azienda è la CA di un sito di terze parti. Tuttavia, se la mia azienda lo facesse, mi lamenterei!
@Nappy Forse ciò che si intendeva era [HPKP] (https://en.wikipedia.org/wiki/HTTP_Public_Key_Pinning) piuttosto che HSTS?Questo potrebbe certamente sconfiggere i cattivi scanner aziendali.Tranne che Wikipedia afferma che la maggior parte dei browser disabilita i controlli HPKP per i certificati con radici private specificamente per consentire tali scanner.Oh bene...
Se la società attacca MITM al traffico dei dipendenti, sconfigge quasi ogni forma di autenticazione, non solo l'autenticazione di base.Quindi, a meno che il server web non sia disposto a utilizzare qualcosa di più complesso come l'autenticazione a 2 fattori, Basic è quasi sicuro come qualsiasi altra forma di autenticazione.
#4
+12
nealmcb
2012-07-14 07:04:17 UTC
view on stackexchange narkive permalink

Notate la necessità di autenticare il client e chiedete informazioni sulla sicurezza dell'autenticazione di base HTTP, su SSL. Questo è ciò per cui SSL è stato progettato e funzionerà bene fintanto che la password è buona. Se lo stai configurando per un solo client, è facile assicurarlo scegliendo una password casuale lunga, ad es. 12 caratteri che utilizzano una buona fonte di casualità, o altre tecniche discusse in questo sito.

Anche il tuo client deve assicurarsi di avere il certificato corretto per il server. Nella situazione come quella che descrivi, andrà bene usare un certificato autofirmato come descritto nella pagina python ssl a cui si fa riferimento.

Se stai per autofirmarti, assicurati di comunicare quali dovrebbero essere le impronte SHA1 e MD5 del certificato in modo che possano verificarne la legittimità al momento della connessione. O distribuire in anticipo, se possibile.
C'è un altro problema con l'utilizzo dell'autenticazione di base HTTP: la password completa viene inviata tramite il tunnel SSL. In altre parole, la password non viene sottoposta ad hashing prima di essere inviata e potrebbe quindi essere catturata (bug nel codice dell'applicazione, ecc.). Questo di solito non è una delle principali preoccupazioni (questo è vero per la maggior parte delle password inviate tramite HTTPS, anche nei moduli di accesso al sito Web e persino nella password SSH), ma vale la pena prenderne nota.
@ChrisKuehl Non ci sono validi argomenti contro l'esecuzione di criptovalute in javascript lato client? È quello che stai suggerendo? Mi sembra che TLS sia più o meno buono che posso ottenere oltre a pagare per la firma del certificato.
@StevenLu non che io sappia o che posso trovare rapidamente, ma sarei interessato a leggere qualsiasi cosa sull'argomento. Non riesco a vedere in alcun modo che l'hashing di qualcosa preliminarmente prima di inviarlo sul server possa diminuire la sicurezza, anche se il lato server lo sottopone ad ulteriore hash prima di archiviarlo. Sarei tentato di utilizzare invece [SSL / TLS auth] (http://goo.gl/xmzFI) (i browser moderni consentono l'autenticazione bidirezionale con i siti Web che utilizzano l'autenticazione della chiave), soprattutto per una pagina che non deve essere visualizzata da utenti regolari. Tuttavia, questo dipende molto dal tuo caso d'uso ed è probabilmente difficile con il tuo server web Python.
Che dire di TLS in TLS, penso che avvolgerlo 4 volte sarebbe più sicuro che avvolgerlo una volta. In questo modo puoi diffondere le chiavi di root in posizioni diverse, quindi se usi 4 società per farlo, è probabile che (LORO) non avranno la chiave di root segreta, o tutte.
Dai un'occhiata: http://www.matasano.com/articles/javascript-cryptography/
@StevenLu interessante, ma manca il punto; L'autenticazione TLS, [come implementata nei browser] (http://www.browserauth.net/tls-client-authentication), non coinvolge JavaScript. È una caratteristica del browser stesso. Ci sono problemi che lo rendono non adatto per l'uso con l'autenticazione rivolta agli utenti, ma per gli sviluppatori / amministratori, penso che ci sia un motivo valido che può essere fatto per questo.
@ChrisKuehl Quindi, immagino che dovrò scavare un po 'più a fondo per trovare un modo per impostare il mio server per eseguire un'autenticazione client TLS completa?
@StevenLu, la tua configurazione suona bene per me, ma tutto dipende da quanta sicurezza desideri. Sto solo buttando fuori un'idea in più :-).
@ChrisKuehl l'autenticazione del server TLS è decisamente sufficiente per le mie esigenze e sono rimasto piacevolmente sorpreso di scoprire la semplicità con cui sono riuscito a configurarlo. Tuttavia, ora mi chiedo cosa ci vorrebbe per ottenere l'autenticazione completa del client.
#5
+9
Steve
2010-12-06 04:59:26 UTC
view on stackexchange narkive permalink

Dipende interamente da quanto deve essere sicuro. L'autenticazione di base su ssl invierà ancora le credenziali in testo normale, il che significa che hai solo un livello di protezione.

Faresti meglio ad eseguire l'hashing della password con un nonce, o meglio ancora utilizzare il modello di attestazioni che passa l'autenticazione a una terza parte fidata.

#6
+4
Weber
2010-12-06 06:25:50 UTC
view on stackexchange narkive permalink

Molti siti grandi e popolari utilizzano l'autenticazione di base (o un'altra basata su moduli) su HTTPS. Di solito riceve un "sospiro" dalle persone attente alla sicurezza. Puoi eseguire l'hash della password sul lato client e inviare invece l'hash? Ciò alzerebbe ulteriormente il livello.

Detto questo, è generalmente considerato accettabile, a condizione che anche la pagina di destinazione che ospita il modulo di accesso sia HTTP / S. Nel tuo caso di un'API RESTful probabilmente non hai una pagina di destinazione, quindi va bene. Se puoi, verifica la tua applicazione con alcuni strumenti di sicurezza gratuiti come Watcher e Skipfish.

solo una risposta alla sfida con l'hash è un aggiornamento della sicurezza, altrimenti l'attaccante può semplicemente ficcare il naso nell'hash e comunque ottenere l'accesso quando la sessione scade
#7
+4
Luc
2012-07-15 05:47:41 UTC
view on stackexchange narkive permalink

Lo sto usando io stesso per molte cose e, a patto che non ignori alcun avviso TLS dal browser, dovresti essere bravo.

TLS funziona sotto HTTP, quindi qualsiasi dato trasmesso tramite HTTP sarà crittografato. Sarà sicuro quanto l'invio di qualsiasi modulo per la password.

Invece di utilizzare un certificato autofirmato, tuttavia, suggerirei di utilizzare Let's Encrypt. Forniscono certificati gratuiti e sono considerati attendibili da Microsoft, Mozilla, ecc., Pertanto, non fornirà un avviso TLS nel browser. Penso che sia meglio usare questo invece di un certificato autofirmato; se vedi un errore TLS, sai che è reale e non solo perché il tuo certificato è autofirmato.

Sicuramente farei qualcosa di simile, soprattutto se è gratuito. Gli errori di "certificato non valido" sono piuttosto evidenti.
Sì, StartSSL è davvero una sorta di soluzione homebrew, ma è considerato affidabile da grandi parti, quindi immagino che vada bene finché non ti assicuri nulla che valga milioni. Tutto è meglio di un certificato autofirmato. Il modo per rendere sicuro l'auto-firmato è controllare l'impronta digitale, ma puoi comunque farlo mentre usi (ad esempio) StartSSL.
Sto ospitando i miei contenuti protetti su un server diverso da quello in cui posso impostare il dominio di destinazione per un certificato (che deve essere emesso da StartSSL). Questo perché non sto pagando per un VPS con un IP statico, sto usando il servizio No-IP per darmi un reindirizzamento al mio IP. È possibile ottenere una chiave / certificato che mi consentirà di aprire il mio sito da qualsiasi luogo senza che mostri errori di certificato non validi?
Quindi mi sembra chiaro che con un IP dinamico non c'è assolutamente alcun modo per impostare un certificato SSL appropriato. Ok, immagino di essere bloccato con l'errore del browser quindi (a meno che non esegua una sorta di configurazione del proxy).
Aggiornamento: StartSSL ha chiuso i battenti.La tua prossima migliore opzione è Let's Encrypt.
Grazie @starbeamrainbowlabs!Ho aggiornato la risposta.
#8
+2
lightxx
2015-03-06 17:32:02 UTC
view on stackexchange narkive permalink

Un altro argomento non menzionato (immagino) finora è il fatto che molti dispositivi mobili come gli smartphone non consentono all'utente di controllare il certificato quando esegue l'autenticazione di base su HTTPS nel browser. Ciò significa che, a differenza dell'autenticazione basata su moduli, non è possibile ignorare il popup di autenticazione di base che è una finestra di dialogo modale sulla maggior parte delle piattaforme mobili per controllare il certificato prima di inserire le proprie credenziali. Ciò potrebbe rappresentare un rischio quando un utente malintenzionato utilizza un certificato valido.

#9
+1
Daniel Szpisjak
2019-02-05 13:05:44 UTC
view on stackexchange narkive permalink

Ecco un po 'più di contesto per la storia. Proprio come altri hanno affermato che l'autenticazione di base su TLS funziona bene se puoi vivere con alcune limitazioni.

Utilizzato sul lato client , probabilmente devi occuparsi della gestione delle sessioni, che è piuttosto difficile con l'autenticazione di base.

Sul back-end , l'autenticazione di base funziona bene ma si basa interamente su TLS per la riservatezza e l'integrità. È simile all'autenticazione basata su token. Se hai bisogno di qualcosa di più valido, considera l'utilizzo di schemi di firma o autenticazione client TLS.



Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 2.0 con cui è distribuito.
Loading...