Questa tecnica è un modo sicuro per confermare i dettagli del conto bancario di un utente, senza richiedere che forniscano le proprie credenziali?

Question

Questa tecnica è un modo sicuro per confermare i dettagli del conto bancario di un utente, senza richiedere che forniscano le proprie credenziali?

#1 da (1 voti)
#2 da (0 voti)

2

Esistono molti servizi finanziari che possono verificare il conto bancario di un utente richiedendo il nome utente e la password e accedendo al loro nome. Alcuni esempi sono Coinbase e TransferWise .

Ho trovato un modo per un utente di verificare i dettagli del proprio conto bancario senza fornire mai il proprio nome utente e password a terzi. Vorrei sapere se ci sono problemi di sicurezza con il seguente protocollo:

Il servizio di terze parti avvia un server proxy che registra tutto il traffico.
L'utente stabilisce una connessione TLS tramite il proxy e verifica il certificato SSL della banca.
L'utente accede usando il nome utente e la password e salva il loro cookie di sessione.
L'utente avvia una nuova connessione TLS tramite il proxy, che utilizza un master segreto diverso.
L'utente utilizza il proprio cookie di sessione corrente per recuperare i dettagli dell'account tramite il proxy.
L'utente firma e annulla il cookie di sessione.
L'utente invia il segreto principale della connessione TLS finale al servizio di terze parti.
Il servizio di terze parti ora è in grado di decrittografare l'HTML e verificare i dettagli dell'utente, come il nome completo, il numero di telefono e il saldo dell'account.

Note:

Se un banco consente l'utilizzo di un cookie di sessione da più indirizzi IP, l'utente può semplicemente accedere e uscire sul proprio computer.
L'utente starebbe visualizzando le pagine con proxy sul proprio computer, quindi funzionerebbe anche con l'autenticazione a due fattori.
Alcuni siti web di banking online potrebbero non invalidare correttamente i cookie di sessione quando un utente si disconnette. Tuttavia, la maggior parte (se non tutte) le banche scadono una sessione dopo 10-15 minuti di inattività, quindi l'utente può semplicemente aspettare che la sessione scada prima di rivelare la chiave privata.
L'HTML della pagina potrebbe perdere più dati del necessario. Ci sarebbero diversi modi per risolvere questo problema per diverse banche. Molte banche forniscono un'API per le loro app mobili, quindi potresti semplicemente proxy alcune richieste API specifiche per rivelare solo le informazioni necessarie.
Invece di inviare la chiave privata e consentire a una terza parte di decrittografare tutti i file HTML e i cookie, potrebbe essere possibile creare un circuito booleano codificato che fornisce una prova a conoscenza zero per la sessione TLS registrata. La terza parte può eseguire un calcolo che verifica l'handshake e il certificato TLS, decrittografa l'URL e l'HTML, quindi verifica la presenza di determinate stringhe per verificare i dettagli dell'account dell'utente. Il risultato del circuito è true o false , e la terza parte non sarebbe in grado di scoprire altre informazioni sulla sessione crittografata. In alternativa, le uscite del circuito potrebbero anche essere le stringhe del tuo nome completo, numero di telefono e saldo del conto corrente. Cercherò di investigare questo approccio con la libsnark biblioteca, perché è un'idea così affascinante!

Un modo per implementare questo potrebbe essere creare un'applicazione browser basata su WebKit che gli utenti possano scaricare e installare. L'app potrebbe configurare un gestore di protocollo nel browser, in modo che l'app si apra ogni volta che l'utente fa clic su un URL come <verification scheme>://domain/path . L'app funzionerebbe con qualsiasi sito Web, ma potrebbe anche utilizzare ricette preconfigurate per banche diverse.

Questo potrebbe anche essere implementato direttamente in Firefox e Chrome, ma non è molto probabile. Ci sono anche molti modi migliori per farlo. Alcuni banchi moderni possono fornire un token OAuth con autorizzazioni di sola lettura limitate. Una banca potrebbe persino utilizzare la crittografia a chiave pubblica per firmare semplicemente i dettagli del tuo account utilizzando la loro chiave privata (forse la chiave privata per il loro attuale certificato SSL.)

Penso che la tecnica descritta sopra potrebbe essere utile, dal momento che può funzionare per qualsiasi sito Web (non solo bancario.) Ma per favore fatemi sapere se è possibile individuare eventuali problemi di sicurezza qui. Sono sicuro di aver frainteso qualcosa su TLS, o forse c'è un modo ancora più semplice per farlo.

banks tls

posta ndbroadbent 08.12.2017 - 19:48

fonte

2 risposte

Leggi altre domande sui tag banks tls

Rimozione della stringa di cookie di Google Analytics dall'URL: buco di sicurezza? Apple Mac Security - Cosa devo sapere?

score 1 · Answer 1

Penso che il meccanismo potrebbe in teoria funzionare, a condizione che l'utente possa fidarsi della propria banca che il proprio sito è configurato in modo tale che nessuna informazione sensibile venga trasferita all'interno della sessione "proof". Ciò significa che almeno l'informazione pertinente alla dimostrazione è inclusa nella sessione di prova, che l'ID della sessione HTTP non può essere usato dalla terza parte e che non viene fatto il riutilizzo della sessione TLS, cioè che la stessa chiave non è usata per proteggere le sessioni TLS precedenti o successive.

Ciò significa che non solo l'utente ha bisogno di un software speciale per creare la sessione di prova, ma anche che la banca deve essere configurata in modo da supportare in modo sicuro questa dimostrazione. A mio avviso, questo concetto rende questo concetto troppo complesso e inaffidabile nella pratica.

score 0 · Answer 2

Vedo una potenziale vulnerabilità, anche se non sono sicuro di poter essere effettivamente eseguita. Il rischio non è dal lato del cliente, ma dal lato di terze parti. In effetti, avevo prima aggiunto un commento, che ho eliminato in seguito, perché mi sono reso conto che avevo torto, e questo mi ha fatto pensare a questa vulnerabilità. Il commento che ho cancellato era che non avevi bisogno del proxy di terze parti, ma che potevi, come utente, registrare il flusso TCP da solo, e poi inviare questo record del flusso TCP come un file zippato, insieme alla chiave stretta di mano di stabilimento, a terzi, come una "prova della sessione passata". Ma poi mi sono reso conto che non è una prova, perché il contenuto effettivo della sessione è crittografato in TLS con una chiave simmetrica, quindi tu, come utente, potresti modificarlo come vorresti, perché anche tu hai la chiave simmetrica. Puoi anche calcolare tutti i tipi di MAC con quella chiave. Se la tua banca ti ha inviato che sei in ritardo sul saldo negativo durante la sessione, puoi modificarlo in un conto con 5 milioni di dollari sul tuo conto. Il certificato proviene dalla banca, la chiave simmetrica negoziata è vera, ma il contenuto può essere determinato non solo dalla banca, ma anche da te. Così ho cancellato il mio erroneo suggerimento.

Tuttavia, penso che si possa fare la stessa cosa attraverso il proxy. Se tu, come utente, configura una presa web falsa su una delle tue macchine e invece di contattare la banca tramite il proxy di terze parti, contatta la tua macchina, che funge da secondo proxy, e contatterà la banca, tu può eseguire un attacco MITM sulla propria sessione TLS con quel proxy, perché si conosce la chiave simmetrica e si modifica a piacere il contenuto, proprio come nel mio commento cancellato. Se la banca ti dice che sei in ritardo, puoi modificarlo al volo nel tuo proxy e mostrare un saldo del conto di 5 milioni di dollari, che è lo stream TCP che la terza parte decodifica.

Naturalmente, se la terza parte è attenta, può vedere che l'indirizzo IP a cui sei andato, non corrisponde a un indirizzo IP della banca. Ma avrà un certificato corretto e una corretta negoziazione delle chiavi.