Registro de autenticación Steamy php. Acciones después de restablecer su contraseña

Restringir el acceso a cualquier área del sitio suele parecer así
monótono: cada usuario recibe un nombre de usuario y contraseña o él mismo
los selecciona, y para ingresar a la parte segura del sitio se debe ingresar. Desde un punto de vista técnico, las contraseñas se verifican utilizando
diferentes métodos. Se puede utilizar un formulario HTML para ingresar su nombre de usuario y contraseña.
En este caso, la contraseña se envía al servidor en texto claro en la solicitud POST.
Esto es inaceptable si el usuario es local, cuando sea posible.
usando un rastreador. Para resolver este problema, se inventó un método.
autenticación mediante hashes, en la que la contraseña no se transmite, sino
se transmite una cadena hash, dependiendo de la contraseña, alguna vez
parámetro y, posiblemente, de algunos otros parámetros. Este método también es
llamado desafío/respuesta, porque al usarlo el cliente
recibe una solicitud con un parámetro único y envía una respuesta que contiene el hash. En el nivel del protocolo HTTP 1.1, la autenticación mediante el
Basic, que no es mejor que usar un formulario HTML, y Digest, que
lo veremos en detalle.

Cuando se utiliza el método Digest, como ya se mencionó, la contraseña
no se transmite y no se puede olfatear, pero hay otro lado
problemas. Para verificar la contraseña, el servidor debe calcular
respuesta y compararla con la respuesta del cliente, por lo tanto el servidor debe
almacenar la contraseña o los datos dependientes de ella necesarios para
pasando la autenticación. De ello se deduce que una persona que ha recibido derechos
para leer cuentas (por ejemplo, usando inyección SQL), podrá obtener
acceso a páginas protegidas por el método Digest. Al utilizar el método
Básico, es posible almacenar hashes en lugar de contraseñas, lo que no permite aumentar los derechos,
después de leer estos hashes (veremos a continuación que Digest también puede almacenar hashes,
pero tal que su conocimiento sea suficiente para calcular la respuesta). Por lo tanto, nos enfrentamos a un dilema: o nuestra contraseña será rastreada,
o lo obtendrán a través de una vulnerabilidad web que alguien seguramente encontrará,
porque quien busca siempre encontrará. Existe un método de autenticación sin
Ambas desventajas son el método de autenticación de clave pública:
para verificar necesita una clave pública y para pasar la verificación necesita una clave secreta,
sin embargo, HTTP 1.1 no proporciona dicho método. RFC 2069
recomienda utilizar SSL si la seguridad es tan importante. Sólo se protege la transmisión de la contraseña y el contenido no está cifrado, por lo que
que no tiene sentido proteger los recursos con este método, de donde es el usuario
recibe información secreta. Requieren SSL. Y tiene sentido
proteger, por ejemplo, un foro o cargar contenido en un sitio web. Entonces, si el alojamiento no admite SSL y la autenticación debe
Para estar seguros, usaremos Digest. Apache proporciona el módulo mod_digest. para usarlo
en la configuración (o en .htaccess) escribimos:

Resumen de tipo de autenticación
Archivo de usuario de autenticación
Nombre de autenticación
Requerir usuario_válido

Los archivos de usuario son creados por la utilidad.
htdigest. Hubo un tiempo en que hubo informes sobre mod_digest de que era vulnerable, así que,
Quizás allí aparezcan otros problemas. Es más, cuando
Intenté usarlo en casa y me salió un error.
Error interno del servidor 500. Además, si se deben agregar cuentas
automáticamente, y debería haber muchos de ellos, deberían
almacenado no en la configuración de Apache, sino en MySQL. Solución -
utilizar PHP. PHP no tiene soporte integrado para esto
método, por lo que tendrá que ser implementado. Para ello es necesario estudiar
este método en detalle. Permítanme señalar de inmediato lo que se da en este artículo.
La implementación solo funciona en Apache, ya que el acceso completo a los encabezados
request (función apache_request_headers) funciona solo en Apache, pero en
Es posible que no esté disponible en otros servidores. Sólo necesitamos leer
Encabezado de autorización.

Descripción del método

La descripción completa del método se puede leer en RFC 2069, y si
En resumen, el método funciona así. Cuando el servidor recibe una solicitud relacionada con el área protegida,
arroja el error 401 Autorización requerida y encabezado de solicitud
autenticación de este tipo:

Autenticación WWW: Digest domain="área segura", nonce="123456123456"

reino es el nombre del área protegida, y nonce es un uso único
significado. También hay parámetros opcionales que discutiremos.
no lo haremos. El cliente repite la solicitud y agrega un encabezado como este:

Autorización: Resumen reino="área segura", nombre de usuario="123", uri="/index.php", nonce="123456123456", respuesta="1234567890abcdef1234567890abcdef"

El parámetro uri debe coincidir con el URI de la solicitud y la respuesta es
la respuesta, que se calcula así:

respuesta = H(H(A1) + ":" + nonce + ":" + H(A2))
H - función hash, MD5 predeterminado
A1 = iniciar sesión + ":" + reino + ":" + contraseña
A2 = método de solicitud + ":" + URI
El método de solicitud es GET, POST, etc.

Como podemos ver, A1 no depende ni de la solicitud ni de la única
valores, por lo que el servidor no puede almacenar una contraseña, sino
H(A1). Así es exactamente como se implementa en mod_digest en Apache.
Sin embargo, los mismos datos son suficientes para el cliente. El atacante, habiendo recibido
este hash puede calcular la respuesta usando las fórmulas anteriores y
generar una solicitud HTTP, por ejemplo, usando el programa
AccessDriver y su herramienta HTTP
Depurador. Este proceso se mostrará con más detalle a continuación. El servidor debe comprobar si el valor es un nonce
el que fue emitido previamente al cliente y si está desactualizado.
Si la respuesta coincide con el parámetro nonce, pero el valor de ese parámetro
no es relevante, la respuesta descrita anteriormente con el código 401 se emite solo porque
la diferencia es que el parámetro se agrega al encabezado WWW-Authenticate
obsoleto = verdadero, lo que indica que el acceso está denegado solo por este motivo,
y debería intentarlo nuevamente sin pedirle al usuario una nueva contraseña. Esto, en mi humilde opinión, es un inconveniente, porque si surge tal situación
al realizar una solicitud POST o PUT con un gran bloque de datos, el cliente tendrá que
transmitir todos los datos dos veces. Para evitar esto, la norma establece
Encabezado de información de autenticación, en el que el servidor puede responder a
Solicitud exitosa para decirle al cliente el próximo nonce.
La sintaxis es la misma que WWW-Authenticate, excepto que el nonce
es reemplazado por nextnonce. Sin embargo, a juzgar por los resultados de mi
experimentos, Opera ignora este encabezado. Otra solución: según
RFC 2068 (HTTP/1.1), el servidor puede responder antes de que se complete la solicitud,
para que el cliente interrumpa la transferencia de datos innecesaria, pero en Apache+PHP esto es
no está implementado, ya que el script comienza a ejecutarse solo después
cómo Apache recibirá y analizará completamente la solicitud.

Almacenamiento de datos entre solicitudes

Hay un punto sutil en la implementación del método de desafío/respuesta en PHP.
Se genera un parámetro único y se emite al cliente en una respuesta, y
se comprueba en otra sesión del script.
Es decir, se debe guardar de una llamada de script a otra, y para ello tendrás que
utilizar archivos o base de datos. Mi ejemplo usa archivos llamados
correspondientes a valores únicos, y los propios archivos contienen
Direcciones IP de los clientes a quienes se emiten. La colección no está implementada en el ejemplo.
basura: es necesario eliminar periódicamente los archivos antiguos.

análisis de código

Este script solo verifica la contraseña y funciona independientemente de
acceso Dependiendo del éxito de la verificación, se dan respuestas sencillas.