¿Por qué la mayoría de los sitios web solo admiten nombres de usuario en ASCII? ¿Hay consideraciones de seguridad si un administrador decide comenzar a aceptar nombres de usuario Unicode?¿Se debe permitir Unicode en los nombres de usuario?
Diría que una razón importante es la falta de soporte para Unicode en la mayoría de las instalaciones de PHP. No es fácil trabajar con él, entonces, ¿por qué permitirlo cuando las posibilidades en ASCII son suficientes para cubrir toda la base de usuarios?
La pregunta no es sobre PHP, por lo que la debilidad de ese lenguaje no debería ser un argumento. – Crozin
@Crozin: Muchas aplicaciones web están escritas en PHP, por lo que puede ser un argumento para ellas. Ese lenguaje en particular tiene una historia larga y triste de la mejor compatibilidad para Unicode junto a LaTeX. – Joey
@[email protected] Johannes_Rössel: ¿Siguiendo este argumento, la web solo debe estar poblada con caracteres latinos? Para dar seguimiento a sus respuestas, aunque diga que PHP no es compatible con Unicode, encontrará muchos sitios web con contenido Unicode, ** excepto ** cuando obliguen a sus usuarios a elegir nombres de usuario y contraseñas ASCI. – banx
ASCII simple es raro, diría yo. A menudo es solo que nadie piensa en ello, ya que en Europa occidental es suficiente el latín 1 y también para los EE. UU. Algunas bases de datos establecen distinciones entre el texto en conjuntos de caracteres heredados y Unicode (varchar frente a nvarchar) o para otras bases de datos se debe establecer un juego de caracteres especial.
Especialmente en los EE. UU., Muchas personas ni siquiera notan que ASCII no será suficiente. Algunos intentan encontrar excusas con "Los usuarios tienen que ingresarlo" o similares, que en su mayoría son falsos.
Para responder a su pregunta, dudo de que haya consideraciones de seguridad, excepto tal vez para suplantar los nombres de otras personas con diferentes guiones (un aspecto idéntico, pero uno es latino, uno es cirílico; esto ya se hizo con URL) . En general, lo veo como un descuido de los desarrolladores que probablemente deberían saberlo mejor.
Homoglyph attacks. El usuario 'cat' y 'сat' son cadenas de Unicode diferentes aunque tienen el mismo aspecto. La primera letra en el segundo 'сat' es en ruso 'с' - "CYRILLIC SMALL LETTER ES" para ser exactos. El sistema no puede decir fácilmente que está falsificando el nombre de otro usuario; para la computadora, las mellas son diferentes.
Editar: La prevención de secuencias de comandos mixtas no resuelve el problema. Por ejemplo, 'сосо' es puro Cyryllic y puede usarse para suplantar ascii 'coco'.
También, anulación de izquierda a derecha (y amigos). Déjelos sin ser optimizados y arruinarán toda su página.
Bueno, * puede * decir fácilmente si está mezclando scripts y no los admite. Los navegadores web siguen una regla similar para revertir los IDN a la pantalla de Punycode. – Joey
No siempre es necesario * mezclar * scripts. Algunas palabras all-ascii se pueden recrear usando cirílico solo, por ejemplo 'coco'. Entonces debes lidiar con eso también. –
Los ataques de homoglifo también son posibles en ASCII; "0" y "O" son indistinguibles en muchas fuentes, como "|", "I", "l" y "1"; ".com", "corn", entre otros. –
¿Autenticación HTTP? Puede haber algunos problemas al enviar el nombre de usuario (y/o contraseña) Unicode a través de los protocolos existentes. Un caso con el que me he encontrado antes es con la autenticación básica. No hay una forma bien definida de manejar el envío de estos nombres de usuario o contraseñas Unicode en los encabezados básicos de autenticación.
[UTF-7] (http://en.wikipedia.org/wiki/UTF-7) le permite transmitir puntos de código Unicode como ASCII. – dreamlax
Pero con utf-7 o cualquier otra codificación, necesita tener el cliente y el código del servidor para asegurarse de que decodificarán correctamente los datos. – Mike
Esta fue la mejor respuesta en la página para mí porque estaba buscando un motivo que aún se aplica incluso si un administrador asigna todos los nombres de usuario de forma controlada. De hecho, seguimos usando autenticación BÁSICA ... Supongo que esto nos da una razón para dejarlo caer en el futuro. – Trejkaz
Mientras puede continuar y permitir el Unicode, comprenda que algunos nombres de usuario no funcionarán como se esperaba gracias a diferentes culturas que aplican reglas diferentes a los mismos caracteres.
Consideremos el caso básico para romper caso sensivitity: En Turquía, los nombres de usuario "ID1" y "ID1" son diferentes (en turco existen dos diferentes es decir, uno con un punto y otro sin él, lo que resulta en 2 captial y 2 letras pequeñas que no coinciden con las mismas reglas de captura que el inglés). Entonces, si cualquier persona turca puede ingresar su nombre en su propio idioma, el programa no tratará su nombre como lo esperan, sino que experimentará una extraña transformación al inglés mutante.
Los caracteres latinos especiales en idiomas europeos tienen superposiciones similares, por lo que es aparentemente aleatorio en cuanto al idioma en el que se introducen. Otras regiones del mundo tienen caracteres compartidos similares donde las reglas de uso difieren; en algunos casos nacionales y culturales odios podría resultar en algunas personas enojadas muy cuando los personajes que componen su nombre de usuario son tratados como si estuvieran escritos en el idioma de su odiado enemigo (debido a que es la configuración predeterminada de los sistemas operativos para esos caracteres extranjeros).
Entonces, necesitamos PSP (programación sensible a la política). Lástima del consorcio Unicode por no haberlo resuelto todo. ☺ –
Su observación no siempre es verdad.Y, la elección de ASCII es en gran parte factores humanos en lugar de cuestiones técnicas o de seguridad.
En la mayoría de los casos, es solo por la facilidad de programación. Un programador nunca sabe que todos los software, bibliotecas, utilidades en el sitio web se romperán o no con algunos personajes. ¿Por qué arriesga el desarrollo del sitio web mientras ASCII funciona bien? Además, algún software web empaquetado dificultaría el uso de Unicode en el nombre de usuario. Esto contribuye al problema de que muchos sitios web solo admiten nombres de usuario en ASCII.
Teóricamente, todo el software actual puede manejar bien los datos de 8 bits. No hay problema en el almacenamiento o la transmisión hoy en día. Incluso si algunos protocolos no, pueden traducir en UTF-7 o con otros esquemas de transformación.
Hay algunos problemas con Unicode. Está más del lado del procesamiento de datos. Puede ser visualización, fuentes, preparación de bibliotecas de software y software para caracteres que no sean BMP, intercalación, comparación, métodos de entrada, instrucciones para escribir. Los administradores pueden no tener el conocimiento suficiente para manejarlos. Dependiendo de la naturaleza del sitio web, podría ser un problema, pero la mayoría no.
Por razones de administración, no es fácil escribir algunos caracteres exóticos. Hace que el administrador sea difícil de buscar usuarios. También es difícil para un administrador mantener los nombres de usuario ofensivos en idiomas extranjeros fuera del sitio web.
Sin embargo, no es raro que los nombres de usuario chinos se utilicen en el sitio web chino. Puede que no siempre esté en ASCII. También lo hacen otras culturas e idiomas. Algunos proyectos globales aceptan casi todos los tipos de caracteres Unicode. Wikipedia es un ejemplo.
O, simplemente podríamos dejar de dar una mierda sobre cómo es un nombre de usuario, y si podemos pronunciarlo/recordarlo. Esa debería ser la preocupación de los USUARIOS. Si nadie te recuerda, esa es tu pérdida. Y, en cuanto a la suplantación de nombres, eso es casi inevitable en cualquier caso. Y, sin embargo, rara vez oyes hablar de spoofs de nombre de usuario.
Imagina un foro, imagina a alguien publica con una cuenta que se ve idéntica a la tuya. Te metes en problemas, di que no lo hiciste, publicas un enlace a tu historial, ves que la publicación no está allí. Haga clic en el perfil del hombre que REALMENTE lo publicó, y bam, usted tiene su perfil. Él ahora es bannable.
Tener el mismo nombre no significa que tenga los mismos datos de usuario. Cualquier aplicación que no le facilite la diferenciación de dos usuarios similares es, de todos modos, pobre y necesita ser reescrita.
Esto no responde la pregunta. Sería mejor como un comentario en una de las otras respuestas. –
Si bien es cuestionable por qué debería haber siempre un nombre de usuario y no solo una 'contraseña' para identificar a un usuario, creo que no hay ninguna razón para rechazar los nombres de usuario Unicode.
Lo que es más importante, es que la contraseña se valide como lanuguage-agnostic: debe tratar las claves independientemente de la configuración del teclado del usuario. Esto significa que "שלום" y "akuo" serían la misma contraseña. Esto es importante, porque el usuario a menudo no ve los caracteres de la contraseña que está escribiendo, y se enojan severamente si el CAPSLOCK está activado.
Esto suena bastante increíble, pero me gustaría ver un sistema que pueda hacer esto de manera confiable ... digamos si su IME es uno que puede convertir las cosas de manera irreversible. Por ejemplo, 缶 用 で て て て s? S? – Trejkaz
Yo voto esto debería ser wiki de la comunidad. Parece que algunas buenas discusiones están comenzando. – jtbandes
si le importa la seguridad de su código, no debe permitir el uso de unicode en ningún lugar (a menos que sea un masoquista ** y ** un experto en Unicode ** y ** usted es el único que tendrá que mantener su código) –
@ L̳o̳̳n̳̳g̳̳p̳o̳̳k̳̳e̳̳, en realidad el último punto debe ser "** y ** los mantenedores también califican (1) y (2)". – Pacerier