¿SSH authorized_keys viola el principio de "volver a autenticar antes de cambiar la contraseña"?

Question

¿SSH authorized_keys viola el principio de "volver a autenticar antes de cambiar la contraseña"?

#1 de gowenfawr (2 votos)

4

Se acepta generalmente que los mecanismos de cambio de contraseña deben solicitar al usuario su contraseña anterior (por ejemplo, OWASP ) La razón es que un atacante que tiene acceso temporal a la sesión de un usuario (ya sea a través de XSS, la computadora que haya iniciado sesión, lo que sea) solo tendrá acceso a esa sesión.

Es de suponer que este principio debería extenderse a otros mecanismos de autenticación: certificados, tokens, etc. (aunque nunca he visto esto discutido)

Sin embargo, considera cómo funciona SSH authorized_keys. Si tiene acceso a la sesión de inicio de sesión de un usuario, pero no a sus claves (por ejemplo, dejaron su computadora conectada), puede modificar el archivo authorized_keys. Puede agregar su propia clave al archivo, para poder acceder a la cuenta en el futuro. También puede eliminar las claves legítimas para bloquear el propietario de la cuenta.

Entonces, ¿deberían los diseñadores de SSH buscar formas de restringir esto? ¿Y qué enfoques podríamos tomar para detener esta vulnerabilidad?

password-management certificates ssh

pregunta paj28 06.06.2014 - 13:17

fuente

1 respuesta

Lea otras preguntas en las etiquetas password-management certificates ssh

Mensaje terminado extraño en TLS configuración del Firewall DMZ

score 2 · Accepted Answer

Sí, estás en lo correcto, las claves autorizadas SSH permiten cambios de autenticación sin verificación si un oponente obtiene (o roba) acceso a la shell una vez (o tiene suficiente acceso a archivos).

Voy a arriesgarme aquí y sugeriré que SSH authorized_keys fue diseñado como una mejora del paradigma .rhosts. Una forma de permitir el acceso sin interrupciones entre los hosts, pero con más que confianza. Entonces, desde esa perspectiva, authorized_keys es de hecho una gran mejora en la seguridad. Eso no es para excusar el problema que está describiendo, sino para ponerlo en contexto.

El único enfoque que realmente abordará este problema es centralizar la autenticación de claves. En lugar de usar archivos de claves dispares, exija a los usuarios enviar claves a un repositorio del sistema, del mismo modo que envían sus contraseñas al repositorio / etc / shadow a través de programas intermedios. Eso significará problemas de código, propiedad y protección de archivos, y el reemplazo de un simple control de edición de archivos con una interfaz de manipulación de bases de datos más estructurada y probablemente más difícil (una que requiere autenticación para permitir la manipulación).

¿Se puede hacer? Ciertamente. ¿Fácil? No, será un poco de trabajo. ¿Probable? Probablemente no; Esta área de debilidad ha sido conocida y aceptada durante mucho tiempo, sin un nuevo impulso, no veo a nadie presionando para solucionarlo.