Le applet Java sono più sicure dei moduli regolari per l'accesso?

Le principali situazioni in cui ho riscontrato applet Java a scopo di autenticazione sono firme . Considera che il server o il client potrebbero essere un attaccante; tipicamente, un sito di banca / borsa online. L'utente può inviare ordini di compravendita e può in seguito provare a fare difetto sui suoi ordini, sostenendo che non li ha mai inviati in primo luogo e che la banca sta cercando di incastrarlo. A quel punto, il cliente e la banca vanno a vedere un giudice.

In una tipica autenticazione password-over-SSL, dal lato tecnico delle cose, la banca perde. In effetti, la banca può essere ragionevolmente certa che il cliente è effettivamente arrivato e ha inviato gli ordini; ma non può dimostrarlo . Per una dimostrazione, è necessaria una firma digitale : il cliente firma l'ordine, con una chiave privata che la banca non conosce. Un certificato client per SSL non è sufficiente, perché la firma del client è quindi sugli elementi della sessione SSL, non sui dati dell'applicazione.

Quindi alcuni codici personalizzati devono essere eseguiti sul computer client. Quel codice deve essere verosimilmente onesto dal momento che il cliente proverà a sostenere che qualsiasi codice inviato dalla banca potrebbe produrre firme senza che lui lo sappia. Javascript non è sufficiente per questo. Ma un'applet Java firmata può fare il trucco: i file .jar verranno memorizzati nella cache sulla macchina del cliente, firmati (quindi la banca non può ripudiarli), e potrebbero essere decodificati (questo è non così difficile per bytecode Java).

Si noti che, analogamente, la firma dell'applet protegge il cliente, poiché qualsiasi crimine dalla banca stessa potrebbe essere scoperto in quel modo; la firma rende le frodi più rischiose, quindi (presumibilmente) meno probabili.

Non sto affermando che questo è ciò che fa il tuo specifico esempio di applet Java, ma almeno è uno scenario in cui le applet Java hanno vantaggi per la sicurezza.

No. Un'applet Java non è notevolmente più sicura dell'autenticazione a due fattori senza Java.

Esistono due principali minacce per il banking online: (a) malware sul lato client e (b) indovinare o rivelare le credenziali della vittima. L'applet Java non aggiunge alcuna protezione contro il malware lato client; poiché l'applet viene eseguita sul client, non offre alcuna protezione contro il malware lato client.

Per quanto riguarda l'ipotesi o la divulgazione delle credenziali, l'applet Java non offre una sicurezza maggiore rispetto, ad esempio, all'autenticazione a due fattori di Google. La difesa primaria contro l'ipotesi o la divulgazione delle credenziali in entrambi i casi è il token fisico, che genera o trasmette un codice casuale una tantum che viene scelto algoritmicamente (quindi non suscettibile a indovinare) ed è specifico della transazione (quindi non suscettibile di divulgazione / phishing) ). Un'applet Java non offre alcuna sicurezza più strong.

Inoltre, l'utilizzo di un'applet Java comporta alcuni costi e rischi. Il rischio principale è che richiede a tutti gli utenti di banking online di avere Java abilitato e installato. Come abbiamo visto di recente, Java ha avuto una serie di vulnerabilità di sicurezza zero-day, alcune delle quali sono state ampiamente sfruttate molto prima che fosse disponibile qualsiasi patch o difesa. Pertanto, costringendo gli utenti di servizi bancari online a eseguire Java, il sistema BankID sta mettendo i propri utenti a maggior rischio e aumentando la probabilità di compromissione del malware lato client, il che potrebbe a sua volta aumentare il rischio di frodi bancarie online.

Inoltre, BankID richiede all'utente di utilizzare un browser compatibile con BankID e rende più difficile effettuare il tuo banking online da Linux. Questo è un costo a sé stante, ed è anche un rischio per la sicurezza, perché significa che non puoi fare facilmente il tuo banking online avviando un LiveCD Linux; spingere gli utenti a Windows per il loro banking online potrebbe aumentare il rischio.

L'autenticazione a due fattori, come fa Google, è abbastanza sicura, dipende però dai PRNG e dall'archiviazione di seed. L'applet è probabilmente solo un modulo e funziona allo stesso modo.

Come per l'accesso alle applet Java, è molto più torbido in termini di benefici per la sicurezza. Argomenti per andare sulla falsariga della sua onnipresente tecnologia conosciuta, non importa quale browser l'utente abbia l'applet che eseguirà lo stesso con lo stesso livello di SSL comunque. Ovviamente questo stesso argomento contro come è la sua onnipresente tecnologia conosciuta e un difetto in esso interesserà tutti coloro che lo usano esattamente allo stesso modo. Ci sono stati attacchi su Java, non è a prova di proiettile e in passato si sono verificati attacchi contro di esso. Infine, a meno che non si resti nell'applet, si deve tornare comunque ai cookie e html per il resto del sito bancario, e questo potrebbe facilmente essere il luogo in cui si manifestano anche i difetti.

Per concludere, non direi che un modo è più o meno sicuro, è solo scambiare alcuni rischi per gli altri.

Da quello che hai descritto, non vedo perché l'applet fornirà più sicurezza su un normale modulo HTML. L'autenticazione multi-factory può essere implementata sia sul modulo che sull'applet. Il processo di crittografia viene gestito dal browser Web e dal server Web per le informazioni sul transito tramite SSL / TLS. Questo processo è indipendente dalla tecnologia underling (applet o modulo HTML).

La banca forse usa "moduli di domanda Oracle" per le loro applicazioni, i clienti generalmente accedono a queste applicazioni tramite un'applet java. Questo potrebbe essere il motivo per cui usano l'applet invece di un modulo HTML.