Pregunta

Tenemos una aplicación basada en navegador en la que queremos que el usuario vuelva a autenticarse cuando ingresa. Entonces, cuando acceden a esa URL, queremos que se les presente el PIN para que tengan que volver a autenticarse. ¿Hay alguna forma razonable de hacer eso?

Información adicional: Esto es para una tarjeta CAC y las estaciones de trabajo tienen ActivIdentity y Tumbleweed en ellas. Además, podría agregar un servicio a las estaciones de trabajo si fuera necesario. Los navegadores son todos IE7. El servidor web es IIS 6 y las páginas están escritas en ASP.NET (principalmente).

¿Fue útil?

Solución

Hay algunas piezas diferentes de software involucradas aquí.

Primero está la tarjeta en sí. Para realizar una firma digital, el CAC tiene que estar en un " verificado " estado, lo que significa que se ingresó un PIN después de insertar la tarjeta. Más allá de eso, cada clave en la tarjeta tiene una bandera que indica si se debe ingresar el PIN cada vez que se usa la clave. No lo he comprobado, pero creo que esto está configurado para el " correo electrónico " par de llaves en un CAC. Por lo tanto, necesitaría encontrar qué teclas tienen esto '' siempre verificar '' establece el indicador y configura el validador de ruta en el servicio para aceptar solo esas claves. Es posible que pueda requerir un OID en particular en el uso de claves extendidas, o excluir algunos de los certificados intermedios de DoD de la creación de rutas (quizás los marque como revocados).

El middleware en la máquina que habla con la tarjeta también podría almacenar en caché el PIN y proporcionarlo a la tarjeta siempre que la tarjeta indique que requiere un PIN antes de completar una operación. Creo que ActivClient estaba haciendo esto con su función de almacenamiento en caché de PIN a través de la versión 6, pero en la versión 7, esta opción parece haberse perdido. No he encontrado nada como esto en el soporte PIV incorporado de Windows. Esta " característica " podría comprometer la seguridad, por lo que supongo que se eliminó deliberadamente y no habría ningún pirateo del registro o de otro modo para restaurar el comportamiento. Esto es algo sobre lo que no tendría control, a menos que administre las máquinas de los usuarios; no hay encabezado HTTP u opción TLS que pueda usar para forzar la entrada de PIN. Pero, con los sistemas más nuevos, no debería ser un problema.

En el lado del servidor, debe darse un apretón de manos completo para que el cliente realice la autenticación. La autenticación del cliente no se realizará si hay una sesión TLS válida. Por lo tanto, deberá encontrar una forma de invalidar la sesión TLS (no la sesión de la aplicación, que probablemente esté vinculada a una cookie HTTP) antes de solicitar la autenticación, o dirigir la solicitud de autenticación a otra interfaz que no tenga sesiones habilitadas.

Otros consejos

Hay dos formas de realizar la autenticación de cliente de tarjeta inteligente en la web: TLS / SSL estándar o complementos personalizados para el navegador. Supongo que está hablando de navegadores web estándar (IE / FF / Safari) y autenticación SSL.

Hay dos cosas importantes para las solicitudes de PIN:

  • sesión SSL y caché de sesión SSL de el navegador
  • estado de autenticación en tarjeta de la clave privada relacionada
  • la forma en que se implementa el middleware.

Al final, desde la perspectiva de seguridad, es la tarjeta la que sabe cuándo " pedir & # 8221; un PIN: algunas tarjetas y claves requieren un PIN para cada operación con la clave, algunas tarjetas están bien para obtener un PIN una vez y dejar las claves en estado autenticado hasta que una aplicación lo retire del lector o lo restablezca.

Si la sesión en el caché del navegador no se puede reutilizar o cuando se establece la conexión, el middleware de tarjeta inteligente (PKCS # 11 en Linux, módulo CryptoAPI / BaseCSP en Windows o Tokend en OSX) necesita hablar a las llaves de la tarjeta. Si el estado de autenticación en la tarjeta requiere que se ingrese un PIN, el navegador generalmente activa una devolución de llamada. O si el middleware sabe que necesitará el PIN, lo solicitará antes de hablar con la tarjeta.

No existe una relación 1: 1 entre ingresar un PIN y volver a autenticar los derechos de acceso a la clave privada y volver a autenticar la sesión SSL.

Con SSL estándar, usted depende de la forma en que se implementa SSL en los navegadores y no puede tener una "autentificación 100% confiable" ingresando PIN " en el lado del cliente.

Si está utilizando Linux, entonces con OpenSC (que AFAIK puede usar tarjetas CAC) puede configurar " transaction_reset " en opensc.conf a verdadero, lo que hace que la tarjeta se restablezca después de cada transacción (cada negociación de sesión SSL) y de esta manera puede estar seguro de que cada vez que abra una nueva sesión SSL, el usuario debe ingresar el PIN nuevamente. Sin embargo, esta es una configuración del lado del cliente, no una función iniciada por el servidor.

Puede usar la función de JavaScript para que el navegador olvide el caché SSL existente en algunos navegadores:

function logout() {
    // clear browser authentication cache
    // IE specific
    try
    {
        document.execCommand("ClearAuthenticationCache", "false");
    }
    catch(e)
    {
        // do nothing
    }

    // clear for firefox or any browser that supports window.crypto API
    if (window.crypto && typeof window.crypto.logout === "function") {
        window.crypto.logout();
    }
}

Puede usar el método Javascript setTimeout para llamar a la función de cierre de sesión anterior y posiblemente redirigirlos a la página logout.aspx para obligar al cliente a ingresar un nuevo PIN.

Pero usa JavaScript y el código depende del navegador y no funciona para todos los navegadores.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top