Domanda:
È sicuro inviare nomi utente / password chiari su una connessione https per autenticare gli utenti?
Emiliano
2014-08-04 18:56:32 UTC
view on stackexchange narkive permalink

Sto configurando un server HTTP domestico che può inviare e ricevere dati JSON a / da diversi client (app Android e iPhone).

Vorrei consentire l'accesso solo a determinati utenti e Sto valutando di utilizzare un semplice meccanismo nome utente / password, poiché la configurazione dei certificati client sembra un po 'eccessiva per questo piccolo progetto.

Ovviamente non posso inviare password chiare dal client al server su HTTP semplice, altrimenti chiunque abbia installato wirehark / tcpdump potrebbe leggerlo. Quindi, sto pensando al seguente meccanismo:

  1. Il server HTTP può essere configurato come server HTTPS
  2. Il server ha anche un database nome utente / password (le password potrebbero essere salvato con bcrypt)
  3. Il client apre la connessione HTTPS, autentica il server (quindi è necessario un certificato del server) e dopo aver scambiato la chiave principale, la connessione dovrebbe essere crittografata.
  4. Il client invia il nome utente / password in chiaro al server
  5. Il server esegue bcrypt sulla password e la confronta con quella memorizzata nel database

Ce n'è problema con questo tipo di configurazione? La password dovrebbe essere sicura poiché viene inviata su una connessione crittografata.

Solo per aggiungere alle risposte che hai già ricevuto, in questo tipo di configurazione consiglierei di guardare al Pinning dei certificati che aiuta a mitigare gli attacchi MITM ...
Forse prendi in considerazione l'hashing della password invece di (o oltre a) crittografarla.
Anche se potrebbe essere sicuro se usi https.Un problema che ho letto in altre domande è che il nome utente e la password verranno scritti nei log del server se vengono passati direttamente negli URL.Può essere pericoloso se la sicurezza dei log viene compromessa.
Otto risposte:
AJ Henderson
2014-08-04 21:23:04 UTC
view on stackexchange narkive permalink

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

L'unico modo in cui le informazioni potrebbero andare perse comunque è se la connessione SSL fosse compromessa e se la connessione SSL fosse in qualche modo compromessa, il token "mascherato" sarebbe comunque tutto ciò che è necessario per accedere all'account, quindi non serve a 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 challenge response per garantire che la password sia detenuta dal client, ma questi sono davvero elaborati e non ampiamente utilizzati. Inoltre, non forniscono ancora molti vantaggi aggiuntivi poiché proteggono solo la password dall'essere compromessa su un server attivamente violato.

@AJHenderson +1, avere il client che invia l'hash sarebbe sicuramente un male, poiché lo scopo del protocollo di autenticazione è assicurarsi che il visitatore conosca la * password * corretta, non la password * hash * corretta. Se un malintenzionato potesse ottenere l'hash (database delle password rubate, uomo nel mezzo, qualunque cosa) e il sistema si basasse sul visitatore che invia l'hash invece della password, qualsiasi nozione di sicurezza reale sarebbe fuori dalla finestra.
A volte c'è un vantaggio nell'hash sul client e poi nell'hash ancora sul server. Ciò può aiutare a garantire che la password sia offuscata in qualsiasi registro di testo non crittografato sul client, sul server e sulla rete.
@Craig Lasciare che il client calcoli il costoso hash salato va perfettamente bene, a patto che applichi un hash non salato economico sul server prima di memorizzarlo (o qualche altro tipo di funzione unidirezionale, come l'elevazione a potenza modulare).
@AndyBoura: se stai progettando il sistema in modo da supportare l'hashing lato client, hai il controllo sulla rete e sul comportamento del server per le parti che avrebbero accesso al testo in chiaro. È vero, non sei danneggiato dall'hashing sul client (a parte il tempo perso), purché non influisca in modo significativo sulla quantità di hashing che fai sul server.
@CodesInChaos - Vorrei solo che fosse leggermente meno cattivo. Anche utilizzando un hash complesso per creare un input "più lungo", è solo un'estensione chiave e un attaccante sarà in grado di produrre molto facilmente molti hash economici. In pratica, potrebbe non avere importanza se l'output dell'hash lato client è lungo e non ci sono vulnerabilità in nessuno degli hash che limitano l'espansione da valori semplici. È anche importante notare che in tal caso, sarà necessario eseguire il salt degli hash lato client e server. Tuttavia, sono ancora un po 'dubbioso sul costo rispetto al vantaggio.
@AJHenderson Ci sono diversi vantaggi per l'hashing lato client: 1) Limite di tempo più lungo poiché il client non ha bisogno di gestire molti accessi allo stesso tempo. 2) Evita DoS poiché il server non ha bisogno di calcolare un hash costoso. 3) Il server non impara la password. | Lo svantaggio principale è che i client hanno spesso una CPU più lenta del server. | Non vedo perché l'hash lato server dovrebbe usare un salt quando l'hash lato client ne usa già uno.
@CodesInChaos - Perché nulla è attendibile dal lato client. Un utente malintenzionato può saltare l'intero processo lento bypassando completamente il client. Devi assicurarti di non poter costruire una tabella arcobaleno di valori hash economici e veloci. Non è fattibile se salate ciascuno e purché l'hashish intermedio sia abbastanza lungo. Altrimenti, crei semplicemente una tabella arcobaleno di valori hash che possono essere generati a una velocità molto, MOLTO veloce se sono economici.
@AJHenderson Ovviamente il valore intermedio deve essere abbastanza grande da evitare l'enumerazione, almeno 128 bit preferibilmente 160-256 per tenere conto di attacchi multi target. Dato che usare un hashish corretto come SHA-256 è così facile, non vedo motivo per aggiungere complicazioni inutili come il sale.
@CodesInChaos - sì, se stai usando un hash intermedio sufficientemente grande e sei sicuro che si comporti bene (distribuzione veramente casuale), allora dovrebbe essere ok fintanto che l'hash iniziale è salato e impiega abbastanza tempo da forzare l'uso di un'enumerazione completa del spazio hash intermedio (o almeno quasi pieno).
A rischio di affermare l'ovvio, assicurati di trasmettere tramite POST e non tramite GET :-) I GET saranno in chiaro.
Inoltre, mentre stiamo parlando di problemi come POST vs GET, assicurati di implementare la segretezza di inoltro in modo che le tue sessioni protette non possano essere decrittografate in seguito da qualcuno che ottiene la chiave privata del tuo server.
Conversazione password / hash [continua in chat] (http://chat.stackexchange.com/rooms/16227/discussion-between-aj-henderson-and-craig).
Soprattutto con un'applicazione lato client, probabilmente utilizzerei ancora qualche versione con hash della password oltre la linea, poiché penso sia possibile che per qualche motivo possa essere creata una connessione non crittografata (da qualche errore di programmazione, aggiornamento dell'app difettoso , impostazioni errate della libreria sottostante, quindi è accettato un reindirizzamento a un server http ...) * Tutto nel caso della stessa password per più account, inoltre sei al sicuro da qualcuno con accesso al tuo server dall'ottenere password in chiaro ...
@Falco - e un errore di programmazione potrebbe rendere anche l'hash insicuro. Devi convalidare il comportamento del codice relativo alla sicurezza, non solo sperare che funzioni correttamente. Maggiore è la complessità che aggiungi a un sistema, più difficile è convalidarlo e più è probabile che compaia un errore o una vulnerabilità. Devi giudicare quanti benefici ottieni per una data quantità di sforzo aggiuntivo. Alla fine, il rischio aggiuntivo di errore nell'implementazione non vale il minimo guadagno in termini di resistenza aggiuntiva.
@AJHenderson: Affermi "Sì, questa è la pratica standard". Hai un riferimento per fare quella dichiarazione? Sto cercando le migliori pratiche da una nota fonte di autorità, come forse il NIST o anche un libro O'Reilly.
Questa "pratica standard" garantisce anche la sicurezza completa se abbiamo "goto fail" o "HTTPS freak" come parte della nostra comunicazione? E se due versioni SSL sono danneggiate, siamo sicuri che la versione recente sia sicura?
@h22 Suppongo che non possiamo essere sicuri al 100%, ma se non lo è, le password sono l'ultima delle nostre preoccupazioni. Inoltre, siamo molto più sicuri di TLS che di una configurazione di hash o crittografia lato client sviluppata internamente. Se dici che rientra nella pratica "non tirare il tuo".
La "crittografia interna" non suona bene, ma esistono anche librerie di crittografia standard.
@h22 la crittografia interna non si applica solo agli algoritmi o alle librerie, ma anche ai protocolli. Ci sono molti modi in cui uno scambio di password può fallire. Ad esempio, se si eseguisse la crittografia lato client senza inviare ogni volta una richiesta diversa al client, la crittografia non farebbe nulla poiché oscurerebbe solo i mezzi per generare una password che sarebbe protetta solo da ssl (poiché il il valore generato dal cliente sarebbe sempre lo stesso, rendendola la password "reale") Ci sono tutti i tipi di potenziali insidie, ovvie e non ovvie.
Resta il fatto che ci sono molti più test e analisi di protocolli come ssl di qualsiasi cosa tu crei come tua suite. Se le tue cose sono sovrapposte ad altre cose, potrebbe produrre attacchi di canale laterale. Il fatto che ci sia voluto così tanto tempo prima che i problemi venissero scoperti in SSL dovrebbe creare fiducia. Significa che anche con un sacco di occhi, le vulnerabilità sono difficili da trovare. Inoltre significa che i problemi vengono rilevati e annunciati dai ricercatori che esaminano questo genere di cose.
È ancora una buona risposta?Mi aspetterei di no;alcuni luoghi installano certificati aggiuntivi e eseguono attacchi HTTPS MitM, ad esempio.Ho visto qualche discussione altrove su quello che dovrebbe essere uno schema migliore, ma non abbastanza per giudicare se è stato da parte di persone che hanno effettivamente capito la sicurezza.
@DanielH se qualcuno ha accesso per installare i certificati di root, ha accesso al registro delle chiavi.Se non ti fidi di un computer, non inserire la password, punto.La protezione contro i client compromessi richiede un meccanismo completamente diverso come le smart card in grado di autenticarsi senza rivelare il segreto, ma che richiede hardware aggiuntivo per il client e non è pratico per la maggior parte delle applicazioni.
@AJHenderson Ci sono modi per far sì che un client abbia un certificato compromesso che non ti consente di installare un keylogger, ma ritiro comunque quella parte della mia obiezione perché ti permetterebbero anche di cambiare la schermata di accesso e pochi se nessun client controlleràche ogni volta per i cambiamenti.Ciò proteggerebbe solo da compromissioni del server parziali ma non totali (che possono o non possono essere plausibili a seconda dell'architettura e delle pratiche di sicurezza aziendali) o attacchi che hanno consentito l'eliminazione passiva ma non l'interferenza attiva con HTTPS (probabilmente può esistere, ma molto raro).
@AJHenderson Anche se la maggior parte di ciò che mi ha convinto è che diverse aziende di cui mi fido per avere una sicurezza superiore alla media sembrano tutte inviare la password inserita in un modo non crittografato oltre HTTPS.Sono sorpreso;Mi sarei aspettato che un metodo che non lo fa sarebbe diventato lo standard per il miglioramento forse piccolo che offre, soprattutto dato che combattere contro il riutilizzo delle password è una battaglia persa.
@DanielH come installeresti un certificato radice attendibile senza avere accesso amministrativo alla scatola per almeno un breve periodo?Se hai quel livello di accesso, potresti essere nefasto anche in molti altri modi, se lo volessi.E come hai giustamente sottolineato, avere solo la funzionalità MitM significa che qualsiasi meccanismo lato client potrebbe essere sconfitto a meno che non sia integrato in un'app piuttosto che in un sito web.
@AJHenderson È possibile compromettere un certificato, senza essere notato o eseguire l'attacco prima che venga revocato.Puoi scegliere come target i clienti che hanno ancora il certificato [Superfish] (https://en.wikipedia.org/wiki/Superfish) o un equivalente di una delle numerose altre utilità che fanno qualcosa di simile.Potresti vendere un middlebox o middleware per il filtraggio dei contenuti che avrebbe un motivo valido per MitMing e quindi non riuscire a proteggere il certificato o usarlo per scopi nefasti.Potresti indurre una CA a rilasciarti un certificato per un sito che controlli solo parzialmente.Eccetera.
@DanielH ok, questo è un contesto completamente diverso dal tuo commento iniziale che parla di luoghi che installano i certificati per il proxy MitM.I casi che hai appena descritto sono molto meno comuni e la maggior parte ha delle mitigazioni in atto o sono casi molto rari o si applicano solo a sistemi che sono altrimenti vulnerabili agli attacchi contro il client stesso.
Cerchiamo di [continuare questa discussione in chat] (https://chat.stackexchange.com/rooms/90709/discussion-between-daniel-h-and-aj-henderson).
Neil McGuigan
2014-08-04 22:26:15 UTC
view on stackexchange narkive permalink

Non necessariamente.

Devi inoltre assicurarti quanto segue:

  1. Il tuo sito è protetto contro le falsificazioni di richieste tra siti. Usa Synchronizing Token Pattern.

  2. Il tuo sito è protetto dagli attacchi di riparazione della sessione. Cambia l'ID di sessione all'accesso.

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

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

  5. Stai utilizzando una crittografia avanzata.

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

  7. Il tuo server non lo fa consentire la rinegoziazione non sicura del client.

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

  9. Stai usando HSTS quindi il browser va direttamente a https anche se l'utente digita http

  10. Stai usando la segretezza di inoltro perfetta quindi le tue comunicazioni storiche sono al sicuro anche se la tua chiave privata è trapelata

se l'intero sito è https, ho ancora bisogno dei cookie contrassegnati come sicuri? Sarebbero comunque crittografati "gratuitamente" grazie al livello TLS, giusto?
Puoi spiegare il punto 6? Perché la compressione renderebbe la connessione meno sicura?
Si desidera comunque un cookie sicuro, solo http, poiché in caso contrario è ancora bloccabile. Vedi xss. La compressione uccide la crittografia. Vedi gli attacchi BEAST e CRIME.
@Emiliano: anche il tuo sito è solo HTTPS, un utente malintenzionato può impostare un uomo nel mezzo dell'attacco e configurare un falso server che utilizza HTTP normale, eseguendo ciò che è noto come SSL stripping. Il browser invierà al falso server il cookie dell'utente. Per mitigare questo problema, sono necessari cookie protetti e criteri HSTS.
9. Utilizzare PFS per mitigare il rischio che qualcuno (ad esempio un governo malvagio) rubi le tue chiavi private.
8. questo è il punto centrale di HTTPS ... 1. non rilevante per il client mobile, è improbabile che ci siano cookie e sessioni. 6. cosa c'è di sbagliato nelle compressioni? - in genere un server che serve servizi JSON richiederebbe l'autenticazione di tutte le richieste.
@njzk 1. Gli URL saranno comunque visualizzabili in un browser, quindi è rilevante. 3. Dipende dalla sua implementazione, vale comunque la pena menzionarlo. 6. vedi gli attacchi BEAST e CRIME.
@NeilMcGuigan: È possibile indovinare la lunghezza della password se viene inviata in modo chiaro tramite HTTPS?
@user2284570 "In chiaro" e oltre "HTTPS" sono opposti.
@NeilMcGuigan: Volevo intendere non trasmetterli utilizzando hash o crittografia extra.
mricon
2014-08-04 19:07:11 UTC
view on stackexchange narkive permalink

Fintanto che verifichi la validità del certificato, va benissimo e viene fatto sempre.

kasperd
2014-08-04 19:15:11 UTC
view on stackexchange narkive permalink

La maggior parte dei siti generalmente considerati sicuri utilizza praticamente l'approccio che descrivi. O, in altre parole, hai semplicemente descritto uno standard industriale consolidato.

Consiglierei di non utilizzare un approccio meno sicuro di quello che hai menzionato. (Se bcrypt sia migliore o peggiore di altri hash salati è una discussione in cui non entrerò. Basta non usare niente di più debole di un hash salato.)

Se vuoi distinguerti come avente sicurezza al di sopra degli standard di settore stabiliti, sono disponibili altre opzioni. Ma ci vuole uno sforzo enorme in tutte le aree dell'applicazione per renderla utile.

Le aree riguardanti la convalida della password che potrebbero essere più sicure includono:

  • Protezione del server contro DoS attacchi scaricando la maggior parte dei calcoli durante la convalida sul client. Cioè non iterare l'hashing sul lato server, solo iterare sul lato client ed eseguire l'ultimo passaggio dell'hashing sul server.
  • Proteggersi dalle fughe di password se il server viene compromesso derivando una coppia di chiavi pubbliche dalla password e mai lascia che il server veda la password o la chiave segreta.
Andy Boura
2014-08-05 12:46:40 UTC
view on stackexchange narkive permalink

Come altri hanno detto, questo è un approccio standard.

Tuttavia per un sito personale non lo seguirò necessariamente ... userei il login federato da Facebook, Google o simili in quanto in questo modo non devo gestire i problemi del ciclo di vita dell'account e può utilizzare l'autenticazione a 2 fattori di Google, ecc.

Risparmierà un bel po 'di moduli e campi nel database, il che significa meno errori.

Ovviamente dovresti comunque autorizzare gli utenti a cui desideri poter accedere tramite una funzione del provider di autenticazione come un gruppo Facebook, una sorta di whitelist di utenti autorizzati o un lavoro di approvazione defluire dal tuo account. A volte questo viene fatto invitando gli utenti: fornendo loro un URL contenente un codice sicuro univoco e il sistema che lo collega a un provider di autenticazione al primo accesso. In alternativa, gli utenti effettuano l'autenticazione e richiedono l'accesso. Questo li pone in uno stato "in sospeso". Fornisci quindi un'interfaccia in cui puoi accedere e approvarli.

Bit non voglio che tutti si uniscano: voglio dare il permesso solo a determinati utenti (ad esempio i miei amici).
Sì, hai bisogno di un elenco di email che sono ancora consentite. Quindi lo controlli con l'ID federato.
Ah, quindi posso implementare una lista bianca, vuoi dire? Questo è interessante, esaminerò anche questo approccio.
Giusto. Potresti persino usare il tuo elenco di amici di Facebook o un gruppo per Auth, ma non ho familiarità con i dettagli su come lo faresti.
Aggiunte ulteriori informazioni sull'autorizzazione per rispondere.
200_success
2014-08-05 21:33:55 UTC
view on stackexchange narkive permalink

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

  • L'intera pagina di accesso e tutte le sue dipendenze avrebbero dovuto essere servite anche su HTTPS, anche se in quel momento non viene trasmessa alcuna password. Fornire qualsiasi parte di esso (come JavaScript, CSS o risorse di immagini) 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 il contenuto misto HTTP / HTTPS con diversi gradi di sospetto. Alcuni sopprimeranno semplicemente l'icona "lucchetto" nell'interfaccia utente. I browser più paranoici rifiuteranno del tutto di caricare le risorse dipendenti non crittografate. In ogni caso, dovresti pubblicare l'intera pagina di accesso su HTTPS.

  • Non inviare la password nella stringa di query di un HTTP GET. I server Web sono in genere configurati per registrare gli URL delle richieste, che includerebbero 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 il logout è imprevedibile.)

Ah sì, ricordo sempre che GET è una cattiva idea perché è visibile sul sistema client e potrebbe finire nella cronologia del client, ma dimentico che anche i server possono registrare i parametri.
h22
2015-10-27 17:39:55 UTC
view on stackexchange narkive permalink

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

Bug di sicurezza HTTPS si sono già verificati in precedenza (perché le due versioni precedenti non funzionano? E cos'è "goto fail "? Che cos'è" https freak "?).

Non suggerisco di abbandonare HTTPS, ma mettere qualcosa in più sotto non farà male nella maggior parte dei casi. Se puoi già inviare password non crittografate tramite quel canale, probabilmente puoi inviare quello che vuoi.

D.H.
2015-10-28 18:16:09 UTC
view on stackexchange narkive permalink

L'uso di HTTPS non impedisce i tentativi di forzare la password. Quindi, se stai implementando la gestione del tuo account utente, potresti prendere in considerazione funzionalità come la complessità minima della password e il blocco dell'account / numero massimo di tentativi che mitigherebbero tali tentativi.



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