¿Hay alguna razón por la cual ciertos sitios no permiten períodos en las contraseñas?

Me preguntaba por qué ciertos sitios web no permiten otra cosa que letras y números en el campo de contraseña.¿Hay alguna razón por la cual ciertos sitios no permiten períodos en las contraseñas?

¿Existe algún motivo de seguridad o tal vez solo sea una limitación de la DB que están utilizando? Gracias por la info.

Editar: Parece que la base de datos de Oracle no reconoce mayúsculas y minúsculas? ¿Es esto cierto? Me lo dijeron a través de PM. Gracias por la información chicos, esto es realmente útil.

Me pregunto por qué esta pregunta tiene 3 votos para cerrar. No es suficiente jQuery y círculos a mano alzada?

Fuente

2010-10-18 Anonymous

+25

Tiendo a no confiar en los sitios que tienen tal requisito. "¿Cómo está almacenando mi contraseña que tal requisito incluso importaría?" es una reacción común. – David

@David: Estoy de acuerdo, en las aplicaciones que he hecho nunca ha habido un problema al almacenar cualquier personaje que quisiera. Sin embargo, me pregunto si existe alguna razón, solo programo con C#, por lo que es posible que ahora no tenga otras restricciones de idioma. –

... y por qué no puedes escribir código para que no importe. Es divertido usar corchetes angulares ''<>' en contraseñas. Y tengo un número angustioso de contraseñas que hacen eco de pensamientos como "Waddya significa que no puedo usar la puntuación en mi contraseña para tu sitio patético". –

ninguna razón en absoluto, excepto por descuidado DB de codificación en el que permitirían texto sin formato en la base de datos o el uso el DB (no portátil) funciona para cifrar la contraseña y usar una instrucción SQL directa. Esto parece una validación simple de cadenas.

Aparte de eso, desde el punto de vista práctico, la colocación especial de caracteres en un teclado extraño o estrecho es complicada y puede ser más frustrante para los usuarios que viajan (o en el caso más moderno como el teclado en pantalla en el teléfono inteligente). Algunos sitios web pueden incluso empujar el sistema aún más proporcionando su propio teclado en pantalla para iniciar sesión (con varias aleatorizaciones).

No permitir caracteres especiales ayuda al control de calidad y reduce la frustración del usuario de múltiples plataformas.

Y finalmente, permitiendo un juego de caracteres limitado (considerado seguro) (que no solo es puntuacion sino también caracteres más específicos en Unicode), el desarrollador también puede evitar la confusión de codificación entre el navegador y la aplicación del servidor no muy claro en el estándar, y puede ser complicado en algunos navegadores).

Fuente

2010-10-18 14:08:48 dvhh

Permitir caracteres especiales no tiene que significar Requiriendo caracteres especiales. Si el usuario sabe que iniciará sesión en un sistema que hace que sea difícil escribir estos caracteres, la solución sensata es no utilizar esos caracteres. – Graham

En un mundo ideal, el usuario sabría por supuesto, pero en algunos casos muy generales (95% del caso), sería porque el sitio móvil se agrega después, o el usuario no sabía sobre el diseño de teclado extranjero antes de que viajar, por ejemplo. – dvhh

No permitir ciertos caracteres porque * algunos * usuarios * podrían * viajar a sitios que * podrían * no hacer que escribirlos fácilmente (y esos usuarios * podrían * no saber cómo evitarlos) sería extraño. –

¿No es para evitar todo posible SQL injection?

Fuente

2010-10-18 14:00:05

@Goto, ¿cómo '.' estaría en peligro de permitir la inyección de SQL? Las palabras clave '- ','; ','' 'y SQL serían más peligrosas. – Brad

Lo dudo '; Usuarios de DROP TABLE; - – David

@Goto: ¿Por qué un'. ' habilitar la inyección SQL? –

Tienen muerte cerebral y miedo a la puntuación en general, y los puntos se cuentan como signos de puntuación. Es más un caso de 'fuego amigo' que punto siendo peligroso. Dash es bastante inofensivo también.

Una de las preocupaciones es SQL Injection, por supuesto. El otro es la capacidad de programación de la fuerza de trabajo.

Fuente

2010-10-18 14:00:44

En trabajos anteriores donde nuestros propios sistemas tenían requisitos como este (por ejemplo, una vez trabajé en un banco que solo permitía letras y números en las contraseñas de los usuarios), a menudo era una cuestión de "eso es lo que el sistema de terceros/widget/la solución que compramos requiere ". Entonces, a veces, la cuestión de la "competencia" se remonta a quien decidió comprarla (generalmente no a los programadores) y a quien le compraron. – David

Chase es una de esas compañías. Me sorprende cómo un sitio como Stack Overflow me permite configurar una contraseña más segura que mi sitio * banking *. * suspiro * –

Si la puntuación en la contraseña se convierte en un problema de inyección de SQL, ** lo están haciendo mal.** –

-1

En general, es una mala práctica limitar las contraseñas a números y letras. Sin embargo, ayuda a proteger el código de la "inyección de código" donde un hacker pasa algunas instrucciones como parte de la contraseña para obtener acceso al sistema. Una contraseña como `Apple; * Delete * from users;" 'podría terminar haciendo daño si el desarrollador no se ocupó adecuadamente de evitar la entrada del usuario.

Otro problema es el uso de caracteres especiales que pueden causar conflictos en el código detrás del sitio. O caracteres especiales que dependen del conjunto de caracteres específico/codificación que se utiliza en la base de datos. Las letras como ë, è, ï, î e ì son todos caracteres especiales que se pueden usar, si se permiten. Pero a veces terminan siendo traducidos por el camino equivocado.

Otro problema es que algunas personas tienden a olvidar fácilmente su contraseña, que se vuelve un poco más compleja de recordar si se les permite usar caracteres especiales. Al restringir la contraseña a menos combinaciones, también hace que las contraseñas sean más fáciles de recordar.
Lamentablemente, también hace que sea más fácil hackear ...

Y a menudo es solo una política establecida por la administración de ciertas compañías que simplemente no saben mejor. La restricción podría ser sólo una decisión de gestión, sin ninguna explicación lógica de gestión de contraseñas con ganas de ser almacenada de esa manera ...

Fuente

2010-10-18 14:06:58

Entonces, la esencia de esto es que los sitios solicitan contraseñas de números de letras porque algunos desarrolladores pueden no tener defensas configuradas en caso de ataques de inyección SQL. –

En realidad, más porque solo temen los ataques de inyección, a pesar de que el código mismo podría ofrecer una protección completa contra aquellos. Para empeorarlo, no tiene que ser código SQL. Podría ser código JavaScript con la esperanza de que se ejecute en el servidor. O código PHP. O código ASP. O el código ColdFusion. Depende de los idiomas utilizados para crear el sitio y su vulnerabilidad a este tipo de ataques. –

Código JavaScript ejecutado en el servidor? – dreamlax

Trabajé en un lugar que quería poder leer contraseñas por teléfono (así se hizo el soporte). Las personas de soporte no conocían todos los nombres de símbolos (hash, bang, pipe, ampersand/y, asterisco/estrella) y otros problemas (¿a qué conjunto de palabras se refiere, qué cita, etc.)? Entonces no permitieron ningún tipo de puntuación.

No es una buena razón (soporte no debe saber mi contraseña), pero no le preguntó por sólo buenas razones :)

Fuente

2010-10-18 14:31:17 user479383

Esta es una buena razón, y una válida para eliminar algunos símbolos. No solo cualquier persona de apoyo debe tener su contraseña, pero cuando alguien puede acceder a sus datos de facturación (número de CC, dirección de facturación), modificar su cuenta o tener acceso físico a su máquina (o una máquina que aloja su contenido/servicios), ' Ya les he confiado mucho más de lo que protege la contraseña de su cuenta. Dicho esto, la mayoría de los sitios nunca necesitan hacer esto, porque interactuar por teléfono o en persona es una rareza extrema. –

(¿Debo mencionar que nunca debe usar la misma contraseña en varios lugares?) –

@Roger Pate: utilizo un buen sistema donde el cuerpo central de la contraseña es el mismo, pero los extremos son diferentes según el sitio web. Funciona muy bien y duda de que alguien note un patrón de inmediato. –

Acerca de mayúsculas/minúsculas: si almacena la contraseña en texto plano, a continuación, eso podría ser un problema. No estoy seguro acerca de Oracle, pero SqlServer considera que 'Contraseña' y 'contraseña' son idénticos.

Si almacena la contraseña como hash, entonces la carcasa del original no es un problema: la contraseña actúa distingue entre mayúsculas y minúsculas.

Fuente

2010-10-18 15:49:17

Gracias no lo sabía. –

Hay no posible razón. Ellos son simplemente incompetentes. Cualquier preocupación sobre la inyección SQL o cualquier otra cosa es simplemente incorrecta. Eso solo le dice que están preocupados por una posible inyección de seguridad porque no están procesando ni cifrando su contraseña.

Fuente

2010-10-18 16:16:02

Hay otras preocupaciones que técnicas. Vea el comentario user479383 para ver un ejemplo. En general, usted está haciendo una declaración general que necesita pruebas, no solo ejemplos para casos que se puedan presentar. – egaga

OWASP es bastante claro en el tema. Su primera pieza de orientación en el OWASP Passwood Storage Cheat Sheet es:

No limitar el carácter longitudes máx largos fijados y establecidos para las credenciales Algunas organizaciones restringen 1) tipos de caracteres especiales y 2) la longitud de las credenciales aceptadas por los sistemas ya de su incapacidad para evitar la inyección de SQL, scripts de sitios cruzados, inyección de comandos y otras formas de ataques de inyección. Estas restricciones, aunque son bien intencionadas, facilitan ciertos ataques simples como la fuerza bruta.

No permita contraseñas cortas o sin longitud y no aplique juego de caracteres o restricciones de codificación en la entrada o almacenamiento de credenciales. Continúe aplicando la codificación, el escape, el enmascaramiento, la omisión directa y otras mejores prácticas para eliminar los riesgos de inyección.

Una longitud de contraseña larga razonable es 160. Las políticas de contraseña muy largas pueden conducir a DOS en determinadas circunstancias 1.

Fuente

2015-12-09 18:55:13 ssabey

¿Hay alguna razón por la cual ciertos sitios no permiten períodos en las contraseñas?

Respuesta

Cuestiones relacionadas