Inicio de sesión basado en web utilizando la clave pública/privada ssl?

Question

¿Es posible crear un proceso de inicio de sesión que requiera una clave pública/privada a través de un navegador web? La clave pública se almacenaría en el servidor y el usuario conservaría (y cifraría) la clave privada.

Básicamente quiero hacer algo similar a lo que hace SSH, pero a través de la web. Tal vez un método personalizado de Autenticación HTTP (que no sea "Resumen").

Sé que no es posible hacerlo con un navegador de stock, por lo que las extensiones para que esto funcione son aceptables (Chrome/Firefox).

Las claves idealmente se cifrarían en una memoria USB. Cuando el dispositivo USB se desenchufa debe ser imposible de iniciar sesión (no desea que el navegador lo guarde en caché).

Esto se usará internamente.

Editar: Certificados de cliente sería lo que estoy buscando, pero ¿cómo puedo almacenar estos certificados en una memoria USB? Además, ¿hay información sobre cómo autenticar a un usuario que usa PHP?

Answer 1

Esto es autenticación de cliente a través de certificados.
Su servidor debe estar configurado para requerir un certificado de cliente y también debe configurarse con un almacén de confianza.
Todos los navegadores admiten esto.
Solo tiene que importar el almacén de claves del cliente que tiene la clave privada y el certificado al conjunto de certificados de la máquina.
Para Windows está en las opciones de Internet

Answer 2

Dudo que pueda hacer esto con una aplicación web. El navegador tiene una zona de pruebas del sistema operativo y no podrá hacer que la aplicación web detecte la presencia de un dispositivo USB ni podrá leer datos con la aplicación web. Por lo tanto, necesitaría que el navegador lo haga por usted, y no están diseñados para funcionar de esa manera.

Cuando carga un certificado de cliente en el navegador, se carga en el almacenamiento de certificados. Esos son diferentes dependiendo del navegador y el sistema operativo. En OSX van a KeyChain. En Windows, algunos entrarán en el almacén de claves del sistema operativo y algunos entrarán en el propio almacén de claves de los navegadores (creo que Firefox funciona de esta manera). Pero ninguno de ellos le permitirá definir un almacén de claves externo y luego cifrar y descifrar la clave que está tratando de proteger a medida que lee y escribe desde esa unidad.

Lo que estás haciendo solo sería posible si escribes tu propia aplicación de escritorio (esencialmente tu propio navegador) que hizo esto por ti.

Es posible que pueda hacerlo con una aplicación Adobe AIR. Adobe AIR admite lectura y escritura desde una unidad USB, admite bases de datos encriptadas (criptografía AES/CBC de 128 bits con SQLite) donde puede almacenar los datos que intenta proteger, y es multiplataforma.

Con cualquiera de estas soluciones es probable que se detenga ante la necesidad de asegurarse de que la llave USB esté enchufada. Eso es muy difícil de hacer. ¿Cómo evitaría que el usuario simplemente copie los archivos de la llave USB al disco duro y luego use la llave desde allí para que no necesiten usar la llave USB?

Para llegar a ese nivel de control es posible que deba considerar una solución verdaderamente nativa. C++, Objective-C o Java. Java será el único que le ofrece una solución multiplataforma.

Si la llave USB es una comodidad para el usuario final en lugar de un requisito, entonces Adobe AIR sería una solución sólida. Si no es así, entonces es hora de repasar sus habilidades de desarrollo de software de escritorio.

Answer 3

Los certificados de cliente son la respuesta. La mayoría de los navegadores importan estos certificados de cliente como PKCS # 12 (.p12, .pfk).

Puede convertir un certificado x509 existente en un archivo PKCS # 12 con la clave pública (.crt), la clave privada (.key) y el certificado CA (.crt). Usted puede hacer esto con OpenSSL con el siguiente comando:

openssl pkcs12 -export -out client.p12 -inkey client.key -in client.crt -certfile ca.crt 

Si autofirmada sus certificados es importante asegurarse de que la serie del certificado es diferente de otros certificados. Si son iguales, puede experimentar errores al intentar importar el archivo .p12 (de modo que tenga cuidado con -set_serial en ejemplos de openssl).

Desafortunadamente, la única forma multiplataforma de hacer certificados móviles/extraíbles es usar una tarjeta inteligente (usando PKCS # 11).

En Mac OS X, Safari y Chrome acceden a sus certificados desde el llavero. En realidad, puede crear un llavero personalizado en una unidad flash USB (Archivo -> Nuevo llavero). Después de haber creado el llavero, simplemente puede arrastrar su archivo .p12 a su Llavero. Lo bueno de esto es que puedes controlar el acceso a la aplicación que tiene acceso a los certificados, y puedes hacer que el llavero se bloquee luego de una cierta cantidad de inactividad.

Con Safari, esto funciona muy bien. Si desenchufa la unidad flash, deja de enviar ese certificado después de unos segundos. Si lo vuelve a enchufar, lo recoge inmediatamente. Si bloquea el certificado con "Acceso a Llaveros", solicita la contraseña. Le impide expulsar correctamente la unidad flash mientras está en uso, pero después de un minuto Safari libera su bloqueo.

Chrome es meticuloso. Almacena el certificado en caché durante varios minutos. Si bloquea el llavero, continúa usando la versión en caché. Si intenta desmontar correctamente la unidad flash, verá que Chrome la está utilizando hasta que la cierre. Si enchufa la unidad flash mientras Chrome se está ejecutando, no la recogerá.

Parece ser que Safari es el único navegador que lo admite. Firefox y Opera tienen sus propias tiendas clave.

Si desea ocultar su llavero personalizado en la unidad de memoria flash, puede crear una carpeta invisible, prefijarla con un punto (como "./.keys"). Al crear su llavero, puede ver la carpeta invisible en la ventana de diálogo presionando Comando + Mayús + ".".

Answer 4

La respuesta a su pregunta es "hoy no es posible".

La tecnología existe hoy en forma de certificados que ya se admiten en todos los navegadores. Pero para obtener lo que desea, los navegadores deberían permitir que los certificados se agreguen y administren en la parte del administrador de contraseñas de su interfaz de usuario. La gente querría sincronizarlos entre dispositivos, etc.

Además, los sitios web necesitarían cambios similares para que los usuarios puedan administrar las claves públicas almacenadas en el sitio web, en lugar de administrar su contraseña.

El beneficio de este tipo de sistema sería que en realidad nunca tiene que enviar su contraseña (clave privada) al sitio web al que está ingresando. Pero, de lo contrario, todavía tiene todas las actividades de administración que tiene hoy con contraseñas.

Answer 5

Aquí es cómo lo hice de inicio de sesión basado en la web utilizando la clave RSA pública/privada en php:

• En el registro, el servidor guarda la clave pública del usuario y da al usuario un ID
• El inicio de sesión, el usuario se le pide que ingrese su ID y clave privada

El registro es muy simple.

Pero inicio de sesión se realiza de esta manera:

• Server genera una cadena que contiene algunos datos: cadena aleatoria, la hora actual, IP del usuario
• Esa cadena es encriptado dos veces con AES con dos contraseñas: nonce1 = pass2(pass1(string))
• misma cadena está cifrado con AES nuevo con dos contraseñas, pero en orden inverso: nonce2 = pass1(pass2(string)) y el resultado se cifra con la clave pública del usuario: nonce2encrypted = encryptPubKeyRSA(userPubKey, nonce2)

P.S. La cadena está encriptada con dos contraseñas, para ser más difícil de hacer un ataque de fuerza bruta.

El formulario de inicio de sesión contiene tres entradas ocultas: nonce1, nonce2encrypted, y nonce2 sin valor.

A continuación, se le pide al usuario que introduzca su clave privada en un área de texto que se encuentra fuera <form> etiqueta (para asegurarse de que no va a ser enviado al servidor en el formulario de envío), un javascript descifrará nonce2encrypted y conjunto de descifrado valor a nonce2. Luego, el área de texto con clave privada se elimina de html con javascript, solo para asegurarse de que no se almacene en algún lugar del navegador ni se envíe al servidor. El servidor recibe nonce1 y nonce2 y los descifra con esas dos contraseñas. Si los valores descifrados son los mismos, el usuario recibe una cookie y está conectado.

P.S. Esa cookie también contiene algunos datos cifrados, por ejemplo, usuario ip. Esto no permite que alguien que robó esta cookie inicie sesión desde otra ip.

Puede view this method in action (project on github)