¿Los applets de Java son más seguros que los formularios normales para iniciar sesión?

Las situaciones principales en las que me he encontrado con applets de Java para fines de autenticación son firmas . Tenga en cuenta que el servidor o el cliente podría ser un atacante; Por lo general, un sitio de banca / bolsa en línea. El usuario puede enviar pedidos de compra y venta, y puede intentar más tarde el incumplimiento de sus pedidos alegando que nunca los envió en primer lugar, y que el banco está tratando de enmarcarlo. En ese momento, el cliente y el banco van a ver a un juez.

En una autenticación de contraseña sobre SSL típica, en el aspecto técnico de las cosas, el banco pierde. De hecho, el banco puede estar razonablemente seguro de que el cliente vino y envió los pedidos; pero no puede probarlo . Para obtener una prueba, se necesita una firma digital : el cliente firma el pedido, con una clave privada que el banco no conoce. Un certificado de cliente para SSL no es suficiente, porque la firma del cliente se encuentra en los elementos de la sesión SSL, no en los datos de la aplicación.

Por lo tanto, algún código personalizado debe ejecutarse en la máquina cliente. Ese código debe ser demostrablemente honesto , ya que el cliente intentará reclamar que cualquier código enviado por el banco podría estar haciendo firmas sin que él lo sepa. Javascript no es suficiente para eso. Pero un applet de Java signed puede hacer el truco: los archivos .jar se almacenarán en caché en la máquina del cliente, estarán firmados (por lo que el banco no los podrá repudiar), y podrían ser de ingeniería inversa (esto es no es tan difícil para el código de bytes de Java).

Tenga en cuenta que, de manera similar, la firma del applet protege al cliente, ya que cualquier delito grave del propio banco podría ser descubierto de esa manera; la firma hace que los fraudes sean más riesgosos, por lo tanto (probablemente) menos probables.

No estoy afirmando que esto sea lo que hace su ejemplo específico de applet de Java, pero al menos es un escenario en el que los applets de Java tienen beneficios para la seguridad.

No. Un applet de Java no es apreciablemente más seguro que la autenticación de dos factores sin Java.

Hay dos amenazas principales para la banca en línea: (a) malware del lado del cliente y (b) adivinación o divulgación de las credenciales de la víctima. El applet de Java no agrega ninguna seguridad contra el malware del lado del cliente; ya que el applet se ejecuta en el cliente, no ofrece seguridad contra el malware del lado del cliente.

En cuanto a la adivinación o la revelación de credenciales, el applet de Java no ofrece mayor seguridad que, por ejemplo, la autenticación de dos factores de Google. La principal defensa contra la adivinación o revelación de credenciales en cualquier caso es el token físico, que genera o transmite un código aleatorio único que se elige algorítmicamente (por lo tanto, no es susceptible de adivinar) y es específico de la transacción (por lo tanto no es susceptible de divulgación / phishing). ). Un applet de Java no ofrece ninguna seguridad más fuerte.

Además, el uso de un applet de Java conlleva algunos costos y riesgos propios. El riesgo principal es que requiere que todos los usuarios de banca en línea tengan habilitado e instalado Java. Como hemos visto recientemente, Java ha tenido una serie de vulnerabilidades de seguridad de día cero, algunas de las cuales han sido ampliamente explotadas mucho antes de que hubiera algún parche o defensa disponible. Por lo tanto, al obligar a los usuarios de banca en línea a ejecutar Java, el sistema BankID pone a sus usuarios en mayor riesgo y aumenta la posibilidad de que el malware del cliente los comprometa, lo que a su vez puede aumentar el riesgo de fraude bancario en línea.

Además, BankID requiere que el usuario use un navegador que sea compatible con BankID, y hace que sea más difícil hacer sus operaciones bancarias en línea desde Linux. Este es un costo propio y también es un riesgo para la seguridad, porque significa que no puede hacer fácilmente su banca en línea al arrancar desde un LiveCD de Linux; empujar a los usuarios a Windows para su banca en línea puede aumentar su riesgo.

La autenticación de dos factores como lo hace Google es bastante segura, sin embargo, depende de los PRNG y el almacenamiento de información. El applet es probablemente solo un formulario y, por lo tanto, funciona de la misma manera.

En cuanto al inicio de sesión del applet de Java, es mucho más turbio en términos de beneficios de seguridad. Los argumentos a favor de las líneas de su tecnología ubicua conocida, no importa qué navegador el usuario tenga el applet se ejecutará igual con el mismo nivel que SSL de todos modos. Por supuesto, este mismo argumento en contra como es su tecnología conocida y omnipresente y una falla en ella afectará a todos los que la usan exactamente igual. Ha habido ataques en Java, no es a prueba de balas y en el pasado se han producido ataques contra él. Finalmente, a menos que uno permanezca en el applet, de todos modos hay que volver a las cookies y html para el resto del sitio bancario, y esto podría ser fácilmente donde surjan fallas también.

Para concluir, no diría que una forma es más o menos segura, es simplemente cambiar algunos riesgos por otros.

Por lo que describió, no veo por qué el applet proporcionará más seguridad en un formulario HTML normal. La autenticación de múltiples fábricas puede implementarse tanto en el formulario como en el applet. El proceso de cifrado es manejado por el navegador web y el servidor web para la información sobre el tránsito a través de SSL / TLS. Este proceso es independiente de la tecnología subyacente (applet o formulario HTML).

El banco tal vez esté utilizando "formularios de aplicación de Oracle" para sus aplicaciones, los clientes generalmente acceden a estas aplicaciones a través de un applet de Java. Esta puede ser la razón por la que utilizan el applet en lugar de un formulario HTML.