Palabras que no se pueden usar en una contraseña: select, insert, update, delete, drop

Restablecimiento de contraseña de identidad digital

• Si olvidaste tu contraseña después de activar la identidad digital, puedes restablecerla a través de esta página.
• Debes ingresar tu información personal en el formulario de abajo y necesitas saber tu nombre de usuario.
• El nombre de usuario es similar a una dirección de correo electrónico, por ejemplo, [e-mail].
• Si olvidaste tanto el nombre de usuario como la contraseña, debes contactar a la mesa de ayuda de la universidad.

Ingreso de información personal

• Se necesita información personal para encontrar la identidad digital en la base de datos.
• Debes ingresar obligatoriamente nombre, apellido, fecha de nacimiento, ID de estudiante y facultad a la que perteneces.
• La selección de facultad incluye varias opciones, como la Academia de Bellas Artes y Diseño, la Academia de Música y la Academia de Teatro, Radio, Cine y Televisión.

Configuración del nombre de usuario y la nueva contraseña

• El nombre de usuario tiene formato de dirección de correo electrónico; por ejemplo, el nombre de usuario de John Smith es [e-mail].
• Debes elegir una contraseña segura que puedas recordar y evitar contraseñas fáciles de adivinar.
• La contraseña debe tener al menos 10 caracteres, no incluir tu nombre y cumplir 3 de estos criterios: mayúsculas en inglés, minúsculas en inglés, números y caracteres especiales (-_.+@).
• La contraseña no debe contener combinaciones de caracteres como script, select, insert, update, delete, drop, --, ', /*, */.
• Debes ingresar la contraseña dos veces para evitar errores tipográficos.

Opinión de GN⁺

• Esta página ayuda a los usuarios que olvidaron la contraseña de su identidad digital a restablecerla fácilmente.
• Las reglas para configurar una contraseña segura cumplen un papel importante en la protección de la información digital del usuario.
• El procedimiento de contactar a la mesa de ayuda de la universidad cuando se olvidan el nombre de usuario y la contraseña ofrece al usuario una vía para recibir ayuda adicional.

[GN⁺]

Comentarios de Hacker News

• Historia de un desarrollador que introdujo cierta cadena por petición de un administrador. Ese sitio no almacena contraseñas y ofrece una interfaz para la gestión de cuentas externas. Hay rumores de que en apps legacy puede existir una validación extraña que impide iniciar sesión con contraseñas que incluyen ciertas cadenas, pero no conoce ejemplos concretos.

• Anécdota de haber hackeado una gran plataforma social en la infancia. Aprovechó un método que simplemente eliminaba palabras prohibidas para inyectar etiquetas HTML válidas y controlar a quienes visitaban la página.

• Opinión de que, en algunos casos, este tipo de requisitos puede ser una buena idea. Mucha gente escribe mal código y mala arquitectura de sistemas, y faltan personas con la capacidad, la autoridad organizacional y el tiempo suficientes para detectar eso y forzar cambios. En EE. UU. quizá tengas que hacer negocios a través de sitios web pésimamente programados. En ese caso, podría ser mejor asumir que la implementación puede ser terrible, como suele pasar, y recomendar mitigaciones en consecuencia.

• Crítica al enfoque de restringir unas cuantas palabras clave y esperar que los hackers no inventen algo que no hayan previsto, en lugar de usar procedimientos almacenados adecuados y técnicas para prevenir por completo la inyección SQL. Ya no estamos en 2005; evitar que la entrada del usuario se mezcle con SQL ya no es ciencia espacial. Guardar contraseñas sin cifrar era una estupidez incluso en 2005.

• Un comentario diciendo que usaría truncate en su lugar.

• Opinión de que esto parece venir de sistemas antiguos. Algunas universidades y bancos usan viejos sistemas mainframe para autenticación centralizada, y en algunos casos almacenan contraseñas en texto plano y las limitan a 8 caracteres y solo mayúsculas. La razón principal para no actualizar esos sistemas es el costo y la complejidad.

• Experiencia de un estudiante según la cual no revisan todas las cadenas prohibidas.

• Historia de alguien que tuvo que crear este tipo de requisito en el trabajo. Se deberían escapar correctamente todas las cadenas y usar consultas parametrizadas para evitar ataques de inyección SQL, pero como defensa en profundidad, también se debería rechazar en todos los campos cualquier código que parezca SQL o HTML.

• Un comentario confiado en que su contraseña jamás sería detectada.

• Una especulación optimista de que este tipo de requisito podría venir de un WAF (firewall de aplicaciones web) demasiado entusiasta.