È sicuro inviare nomi utente / password chiari su una connessione https per autenticare gli utenti?

Sì, questa è la pratica standard. Fare qualcosa di diverso da questo offre un vantaggio aggiuntivo minimo, se del caso (e in alcuni casi può danneggiare la sicurezza). Finché si verifica una connessione SSL valida al server corretto, la password viene protetta sul cavo e può essere letta solo dal server. Non si guadagna nulla mascherando la password prima di inviarla poiché il server non può fidarsi del client.

L'unico modo in cui le informazioni potrebbero perdersi comunque è se la connessione SSL fosse compromessa e se la connessione SSL fosse in qualche modo compromessa, il token "mascherato" sarebbe ancora tutto ciò che è necessario per accedere all'account, quindi non fa buono per proteggere ulteriormente la password. (Probabilmente fornisce una leggera protezione se hanno usato la stessa password su più account, ma se lo fanno, non sono particolarmente attenti alla sicurezza per cominciare.)

Come ha sottolineato MyFreeWeb, ci sono anche alcuni sistemi elaborati che possono utilizzare una risposta alla sfida per assicurarsi che la password sia gestita dal client, ma questi sono veramente elaborati e non ampiamente utilizzati. Inoltre, non forniscono ancora molti vantaggi in più poiché proteggono solo la password da compromissioni su un server compromesso attivamente.

Non necessariamente.

Devi anche assicurarti che:

1. Il tuo sito è protetto da falsi di richieste cross-site. Utilizza Sincronizzazione del token pattern.

2. Il tuo sito è protetto dagli attacchi di fissazione delle sessioni. Cambia ID di sessione al login.

3. Se si utilizzano i cookie di sessione, l'intero sito è HTTPS, non solo l'URL di accesso e il cookie di sessione viene contrassegnato come sicuro e solo http (senza accesso JavaScript). Il browser invierà i cookie di sessione non crittografati se l'utente digita http://yoursecuresite (nella stessa sessione del browser).

4. Stai utilizzando un protocollo recente. SSL 1 e 2 sono interrotti e potrebbe esserlo anche 3. Prova a utilizzare TLS 1.1 o 1.2.

5. Stai utilizzando una cifratura strong.

6. Non stai usando la compressione HTTP (GZip) o la compressione TLS. Se il tuo sito visualizza l'input dell'utente (come un input di ricerca), allora posso capire i tuoi token CSRF e il numero di conto bancario se stai usando la compressione.

7. Il tuo server non consente la rinegoziazione dei client non sicuri.

8. Si sta utilizzando una chiave RSA a 2048 bit (o l'equivalente per una chiave EC) e nessun altro conosce la propria chiave privata.

9. Stai utilizzando HSTS, quindi il browser passa direttamente a https anche se l'utente digita http

10. Stai utilizzando la perfetta segretezza in modo che le tue comunicazioni storiche siano protette anche se la tua chiave privata è trapelata

Finché si verifica la validità del certificato, questo è perfettamente valido e viene eseguito sempre.

La maggior parte dei siti di solito considerati sicuri prende praticamente l'approccio che stai descrivendo. In altre parole, hai semplicemente descritto lo standard industriale consolidato.

Raccomanderei di non utilizzare un approccio meno sicuro di quello che hai citato. (Sia che il bcrypt sia migliore o peggiore di altri hash salati è una discussione che non approfondirò. Semplicemente non usare niente di più debole di un hash salato.)

Se vuoi distinguerti come avente sicurezza al di sopra degli standard di settore stabiliti, ci sono altre opzioni disponibili. Ma ci vuole un enorme sforzo in tutte le aree della tua applicazione per renderlo utile.

Le aree relative alla convalida della password che potrebbero essere più sicure includono:

• Proteggere il server dagli attacchi DoS scaricando la maggior parte del calcolo durante la convalida sul client. Cioè non iterare l'hashing sul lato server, solo iterare sul lato client ed eseguire l'ultimo passaggio di hashing sul server.
• Protezione contro le perdite di password se il server viene compromesso derivando una coppia di chiavi pubbliche dalla password e mai lasciare che il server visualizzi la password o la chiave segreta.

Come altri hanno affermato, questo è un approccio standard.

Tuttavia, per un sito personale non lo seguirò necessariamente ... Utilizzerei il login federato da Facebook, Google o simili in questo modo non devo gestire i problemi del ciclo di vita degli account e posso usare Google 2 fattore Auth ecc.

Si risparmia avere un numero limitato di moduli e campi nel database, il che significa meno errori.

Naturalmente avresti comunque bisogno di autorizzare quegli utenti a cui desideri poter accedere sia attraverso una funzione del provider di autenticazione come un gruppo Facebook, una sorta di whitelisting di utenti autorizzati, o un flusso di lavoro di approvazione fuori dal tuo account . A volte ciò avviene invitando gli utenti: fornendo loro un URL contenente un codice di sicurezza univoco e il sistema che lo collega a un provider di Auth al primo accesso. In alternativa, gli utenti eseguono l'autenticazione e richiedono l'accesso. Questo li pone in uno stato "in sospeso". Quindi fornisci un'interfaccia in cui puoi effettuare il login e approvarli.

HTTPS rende la richiesta di autenticazione non accettabile durante il transito. Tuttavia, per renderlo "sicuro", ci sono altre cose che devi anche avere ragione. Ad esempio:

• Anche l'intera pagina di accesso e tutte le sue dipendenze dovrebbero essere state pubblicate su HTTPS, anche se non viene trasmessa alcuna password. Servire qualsiasi parte di esso (come JavaScript, CSS o risorse immagine) su HTTP non crittografato consentirebbe a un utente malintenzionato di modificare l'aspetto o il comportamento della pagina di accesso tramite un attacco man-in-the-middle.

  I browser tratteranno contenuti HTTP / HTTPS misti con vari gradi di sospetto. Alcuni semplicemente sopprimono l'icona lock "lock" nell'interfaccia utente. Più browser paranoici si rifiuteranno di caricare del tutto le risorse dipendenti non crittografate. In ogni caso, dovresti servire l'intera pagina di accesso su HTTPS.

• Non inviare la password nella stringa di query di un GET HTTP. I server Web sono in genere configurati per registrare gli URL delle richieste, che includeranno la parte della stringa di query dell'URL. Metti invece la password in un corpo POST. (Puoi anche utilizzare l'autenticazione HTTP RFC 2617 , ma il supporto per la disconnessione è discutibile.

Wikipedia che contiene la pagina intera dei problemi di sicurezza HTTPS storici.

I bug di sicurezza HTTPS sono già accaduti prima (perché le due versioni precedenti sono rotte? E cos'è "goto fail"? Che cos'è "https feak"?).

Non suggerisco di sbarazzarmi di HTTPS, ma posizionare qualcosa di aggiuntivo al di sotto non farà danni nella maggior parte dei casi. Se già puoi inviare una password non crittografata attraverso quel canale, probabilmente puoi inviare quello che vuoi.

L'uso di HTTPS non impedisce ai tentativi di forzare la password. Quindi, se stai ruotando la tua gestione degli account utente, allora potresti prendere in considerazione funzionalità come la complessità minima delle password e il blocco degli account / il numero massimo di tentativi che potrebbero attenuare tali tentativi.