it-swarm-eu.dev

HTTPS e autenticazione di base sono sufficientemente sicuri per i servizi Web bancari (RESTful)?

Ho letto su SSL/TLS negli ultimi giorni e sembra che non sia mai stato praticamente rotto.

Dato che SSL/TLS viene utilizzato per tutte le comunicazioni tra l'applicazione client e il server e che la password/chiave API è casuale e sicura e archiviata in modo sicuro sul lato server (scritto, salato), pensi che l'autore di base sia abbastanza sicuro, anche per i servizi bancari?

Vedo che a molte persone non piace l'idea di username/password che vengono inviate in rete ad ogni richiesta. È questo un vero punto debole di Basic Auth (anche con SSL/TLS usato) o è solo per paura irrazionale?

26
dnang

L'autenticazione di base HTTP non è molto utilizzata nelle connessioni browser-server perché comporta, sul lato browser, un popup di accesso controllato dal browser che è invariabilmente brutto. Questo ovviamente non si applica alle connessioni server-server, dove non esiste alcun utente umano che possa osservare bruttezze, ma contribuisce a un clima generale di sfiducia e disuso per l'autenticazione di base.

Inoltre, negli anni '90, prima dei tempi di SSL, l'invio di password in chiaro via cavo era considerato un'offesa di tiro e, nella loro follia, le persone consideravano che protocolli di risposta alla sfida come HTTP Digest erano sufficienti per garantire la sicurezza. Ora sappiamo che non è così; indipendentemente dal metodo di autenticazione, il traffico completo deve essere almeno crittograficamente collegato all'autenticazione per evitare il dirottamento da parte di aggressori attivi. Quindi è richiesto SSL . Ma quando SSL è in vigore, l'invio della password "così com'è" nel tunnel SSL va bene. Quindi, per riassumere, l'autenticazione di base in SSL è abbastanza forte per scopi seri, inclusi codici di lancio nucleari e persino questioni relative al denaro.

Bisogna comunque sottolineare che la sicurezza si basa sull'impossibilità di attacchi Man-in-the-Middle che, nel caso di SSL (come è comunemente usato) si basa sul certificato del server. Il client SSL (un altro server nel tuo caso) DEVE convalidare il certificato del server SSL con grande cura, incluso il controllo dello stato di revoca scaricando il CRL appropriato. Altrimenti, se il client viene reindirizzato a un server falso, il proprietario del server falso imparerà la password ... In tal senso, l'utilizzo di qualcosa come HTTP Digest aggiunge un ulteriore livello di mitigazione nel caso in cui la situazione fosse già abbastanza marcita, perché anche con HTTP Digest, un server falso che esegue un MitM può comunque dirottare la connessione in qualsiasi momento.


Se andiamo un po 'oltre, possiamo notare che quando si utilizza l'autenticazione basata su password, in realtà vogliamo un'autenticazione reciproca basata su password . Idealmente, il client SSL e il server SSL dovrebbero autenticarsi a vicenda in base alla loro conoscenza della password condivisa. I certificati sono una complicazione non necessaria; teoricamente, client e server SSL dovrebbero usare TLS-PSK o TLS-SRP in quella situazione, ed evitare del tutto il business dei certificati X.509.

In particolare, in SRP, ciò che il server memorizza non è la password stessa ma una sua derivata (un hash con una struttura matematica aggiuntiva). Si noti un punto importante: nel caso di un'API Web, sia il client che il server sono macchine senza coinvolgimento umano. Pertanto, la "password" non deve essere abbastanza debole da essere ricordata dai sacchetti di carne. Quella password potrebbe essere, diciamo, una sequenza di 25 caratteri casuali, con un'entropia attraversata il tetto. Ciò rende inutili i soliti metodi di hashing delle password (hashing lento, sali). Vogliamo ancora evitare di archiviare nel database del server (quindi in preda a potenziali iniezioni di SQL) le password "così come sono", ma, in quel caso , sarebbe sufficiente un semplice hash.

Ciò indica quanto segue: idealmente, affinché un'API RESTful venga utilizzata da un server per comunicare con un altro, con l'autenticazione basata su un segreto condiviso (fat), la comunicazione deve utilizzare TLS con SRP. Nessun certificato, solo hash memorizzati sul server. Non è necessaria l'autenticazione di base HTTP o qualsiasi altra autenticazione basata su HTTP, poiché tutto il lavoro sarebbe già avvenuto a livello SSL/TLS.

Sfortunatamente, l'attuale stato di implementazione delle implementazioni SSL/TLS che supportano SRP di solito significa che non è ancora possibile utilizzare SRP. Invece, dovrai utilizzare un SSL/TLS più banale con un certificato X.509 sul lato server, che il client convalida debitamente. Finché la convalida viene eseguita correttamente, non vi è alcun problema nell'invio della password "così com'è", ad es. come parte dell'autenticazione di base HTTP.

35
Thomas Pornin

Un problema principale con l'autenticazione HTTP è che non c'è modo di disconnettersi, se non quello di chiudere il browser. E poiché la password corrisponde a ogni richiesta, l'autenticazione è senza stato. Ad esempio, non è possibile disconnettere gli utenti dopo 20 minuti di inattività.

I siti ad alta sicurezza come le banche in genere (sempre?) Forniscono non solo un mezzo per disconnettersi manualmente da un utente, ma anche disconnettono l'utente dopo un periodo di inattività. Questo aiuta a prevenire una serie di attacchi opportunistici.

6
tylerl

In realtà ho visto queste richieste inviate dalla mia banca. Tuttavia usano ancora identificatori di sessione invece di inviare il nome utente e la password ogni volta (questo non è davvero riposante, lo so). Il motivo per cui non usano solo nome utente e password ma una sessione è perché richiedono un secondo fattore di autenticazione. Ciò significa che dovrai inserire nuovamente la risposta alla sfida per ogni ricarica della pagina.

Se la tua banca utilizza solo nome utente e password, sinceramente non mi importerebbe. Ma a mio avviso, qualsiasi applicazione bancaria che si rispetti dovrebbe usare una forma di autenticazione a due fattori: tramite SMS, lettori di carte, token, ...

2
Lucas Kauffman