Sto creando un'API REST ed è semplice eseguire l'accesso di 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?
Ci sono alcuni problemi con l'autenticazione di base HTTP:
Di quelli, l'uso di SSL risolve solo il primo. E anche con questo, SSL protegge solo fino al server web: qualsiasi instradamento interno, registrazione del server, ecc. Vedrà la password in chiaro.
Quindi, come per qualsiasi cosa, è importante guardare l'intera immagine.
HTTPS protegge la password durante il transito? Sì.
È abbastanza? Di solito, no. (Voglio dire, sempre no - ma in realtà dipende da cosa è il tuo sito e quanto deve essere sicuro.)
Prova a pensare in questo modo: quando accedi a qualsiasi sito web usando SSL, molto probabilmente passerai la password in testo normale su HTTPS (ad es. GMail).
L'unica differenza che fa Basic-Auth è che nome utente / password è passato nelle intestazioni delle richieste invece del corpo della richiesta (GET / POST).
Pertanto, l'uso di basic-auth + https non è meno o più sicuro di un'autenticazione basata su modulo su HTTPS.
L'autenticazione di base su HTTPS è buona, ma non completamente sicura. Simile a come Fiddler funziona per il debug SSL, un proxy HTTPS aziendale sta gestendo la connessione tra il browser Web e il Proxy (di cui IP l'indirizzo appare nei log del tuo server web). In tal caso, la password HTTPS viene decrittografata e successivamente crittografata nuovamente nel proxy aziendale.
A seconda di chi gestisce il proxy e di come vengono utilizzati i suoi registri, ciò può essere accettabile o negativo dalla tua prospettiva.
Per ulteriori informazioni su come l'intercettazione SSL è stata eseguita, consulta questo link :
When the SSL Proxy intercepts an SSL connection, it presents an emulated server certificate to the client browser. The client browser issues a security pop-up to the end-user because the browser does not trust the issuer used by the ProxySG. This pop-up does not occur if the issuer certificate used by SSL Proxy is imported as a trusted root in the client browser's certificate store.
The ProxySG makes all configured certificates available for download via its management console. You can ask end users to download the issuer certificate through Internet Explorer or Firefox and install it as a trusted CA in their browser of choice. This eliminates the certificate popup for emulated certificates...
Alcune aziende aggirano il problema del pop-up dei certificati sopra menzionato distribuendo i certificati radice (del Proxy) su ogni workstation tramite GPO. Sebbene ciò influirà solo sul software che utilizza l'archivio certificati Microsoft. Software come Firefox deve essere aggiornato in modo diverso.
Si noti la necessità di autenticare il client e chiedere la sicurezza dell'autenticazione di base HTTP, su SSL. Questo è ciò che è stato progettato per SSL e funzionerà bene finché la password è buona. Se lo stai configurando per un singolo client, è facile assicurarti selezionando una password casuale lunga, ad es. 12 caratteri usando una buona fonte di casualità o altre tecniche discusse in questo sito.
Anche il tuo cliente deve assicurarsi di avere il certificato giusto per il server. Nella situazione come quello che descrivi, usare un certificato autofirmato come descritto nella pagina ssl python referenziata andrà bene.
Dipende interamente dalla sicurezza che deve essere. L'autenticazione di base su ssl invierà comunque le credenziali in testo semplice, il che significa che hai solo un livello di protezione.
È meglio usare hash la password con un modello di reclamo nonce, o meglio ancora, che trasmette l'autenticazione a una terza parte attendibile.
Molti siti grandi e popolari utilizzano un'autenticazione di base (o un'altra basata su form) su HTTPS. Di solito è un "sospiro" da parte di persone attente alla sicurezza. Puoi cancellare la password sul lato client e inviare l'hash? Ciò farebbe aumentare la battuta un po 'di più.
Detto questo, è generalmente considerato accettabile, a condizione che la tua 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 .
Sto usando questo me stesso per molte cose, e finché non ignori gli avvisi TLS dal browser dovresti essere bravo.
TLS funziona sotto HTTP, quindi tutti i dati trasmessi tramite HTTP saranno crittografati. Sarà sicuro come inviare qualsiasi modulo di password.
Tuttavia, invece di utilizzare un certificato autofirmato, suggerisco di utilizzare Let's Encrypt . Forniscono certificati gratuiti e sono considerati affidabili da Microsoft, Mozilla, ecc. E pertanto non forniscono 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é la tua certificazione è autofirmata.
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 tramite HTTPS nel browser. Ciò significa che, diversamente dall'autent basata su form, non puoi ignorare il popup di autorizzazione di base che è una finestra di dialogo modale sulla maggior parte delle piattaforme mobili per controllare il certificato prima di inserire le tue credenziali. Ciò potrebbe rappresentare un rischio quando un utente malintenzionato utilizza un certificato valido.
Leggi altre domande sui tag authentication http web-application tls appsec