Guía de Referencias sobre Autentificación - Revision history

Jmanico: Redirected page to Authentication Cheat Sheet Español

2015-08-31T20:37:31Z

Redirected page to Authentication Cheat Sheet Español

Show changes

Eugeniabahit at 02:24, 3 August 2015

2015-08-03T02:24:44Z

Eugeniabahit at 23:47, 2 August 2015

2015-08-02T23:47:16Z

Eugeniabahit at 23:26, 2 August 2015

2015-08-02T23:26:59Z

Eugeniabahit at 23:23, 2 August 2015

2015-08-02T23:23:36Z

Eugeniabahit at 23:14, 2 August 2015

2015-08-02T23:14:44Z

Eugeniabahit at 22:48, 2 August 2015

2015-08-02T22:48:06Z

Eugeniabahit at 22:36, 2 August 2015

2015-08-02T22:36:16Z

Eugeniabahit at 22:07, 2 August 2015

2015-08-02T22:07:22Z

Eugeniabahit at 20:58, 2 August 2015

2015-08-02T20:58:31Z

@@ Line 256: / Line 256: @@
 OpenId un protocolo basado en HTTP que utiliza proveedores de identidad para validar que un usuario es quien dice ser. Es un protocolo muy simple que permite a un proveedor de servicios de identidad un camino para el inicio de sesión único (SSO, por las siglas en inglés de "single sign-on"). Esto permite a los usuarios reutilizar una sola identidad dada a un proveedor de identidad OpenId de confianza y ser el mismo usuario en múltiples sitios web, sin la necesidad de proveer la contraseña a ningún sitio Web, exceptuando al proveedor de identidad OpenId.
-Debido a su simplicidad and y a que proporciona protección de contraseñas, OpenId ha sido bien aceptado. Algunos de los proveedores de identidad OpenId bien conocidos son Stack Exchange, Google, Facebook y Yahoo!
+Debido a su simplicidad y a que proporciona protección de contraseñas, OpenId ha sido bien aceptado. Algunos de los proveedores de identidad OpenId bien conocidos son Stack Exchange, Google, Facebook y Yahoo!
-Para entornos no empresariales, OpenId es considerado seguro y frecuentemente, la mejor opción, siempre y cuando el proveedor de identidad es de confianza.
+Para entornos no empresariales, OpenId es considerado seguro y frecuentemente, la mejor opción, siempre y cuando el proveedor de identidad sea de confianza.

@@ Line 179: / Line 179: @@
 === Autentificación TLS ===
-La autentificación TLS, también conocida como autentificación TLS authentication mutua, consiste en que ambos, navegador y servidor, envíen sus respectivos certificados TLS durante el proceso de negociación TLS (''handshaking''). Así como se puede validar la autenticidad de un servidor mediante el certificado y, preguntar a una Autoridad de Certificación conocida (CA, por las siglas en inglés de "Certificate Authority") si la certificación es válida, el servidor puede autentificar al usuario recibiendo un certificado desde el cliente y validándolo contra una CA o su propia CA. Para hacer esto, el servidor debe proveer al usuario de un certificado generado específicamente para él, asignado valores que puedan ser usados para determinar que el usuario debe validar el certificado. El usuario instala los certificados en el navegador y los usa para el sitio Web.
+La autentificación TLS, también conocida como autentificación TLS mutua, consiste en que ambos, navegador y servidor, envíen sus respectivos certificados TLS durante el proceso de negociación TLS (''handshaking''). Así como se puede validar la autenticidad de un servidor mediante el certificado y, preguntar a una Autoridad de Certificación conocida (CA, por las siglas en inglés de "Certificate Authority") si la certificación es válida, el servidor puede autentificar al usuario recibiendo un certificado desde el cliente y validándolo contra una CA o su propia CA. Para hacer esto, el servidor debe proveer al usuario de un certificado generado específicamente para él, asignando valores que puedan ser usados para determinar que el usuario debe validar el certificado. El usuario instala los certificados en el navegador y los usa para el sitio Web.
 Es una buena idea hacer esto cuando:
-*Es aceptable (o incluso preferido) que el usuario sólo tenga acceso a la página web des una sola computadora/navegador.
+*Es aceptable (o incluso preferido) que el usuario sólo tenga acceso a la página web desde una sola computadora/navegador.
-*El usuario no se asusta fácilmente por el proceso de instalación de certificados TLS en su navegador o habrá alguien, probablemente de soporte de TI, que lo hará esto para el usuario.
+*El usuario no se asusta fácilmente por el proceso de instalación de certificados TLS en su navegador o habrá alguien, probablemente de soporte de TI, que hará esto para el usuario.
 *El sitio web requiere un paso adicional de seguridad.
 *El sitio Web es de la intranet de una compañía, empresa u organización.
-Por lo general, no es una buena idea utilizar este método para la mayor parte de los sitios Web de acceso público que tendrán un usuario promedio. Por ejemplo, no será una buena idea implemenetar esto en un sitio Web como Facebook. Si bien esta técnica puede evitar que el usuario tenga que escribir una contraseña (protegiéndola así contra el robo desde un keylogger promedio), aún se considera una buena idea emplear el uso de una contraseña combinada con la autentificación TLS.
+Por lo general, no es una buena idea utilizar este método para la mayor parte de los sitios Web de acceso público que tendrán un usuario promedio. Por ejemplo, no será una buena idea implementar esto en un sitio Web como Facebook. Si bien esta técnica puede evitar que el usuario tenga que escribir una contraseña (protegiéndola así contra el robo desde un keylogger promedio), aún se considera una buena idea emplear el uso de una contraseña combinada con la autentificación TLS.

@@ Line 137: / Line 137: @@
-== Implementar un mecanismo de recuperación de contraseña seguro ==
+== Implementar un mecanismo seguro de recuperación de contraseña ==
-Es común que una aplicación tenga un mecanismo que provea al usurio un medio para acceder a su cuenta en caso de que olvide su contraseña. Por favor, para más detalles sobre esta característica, vea [[Forgot Password Cheat Sheet]] (en inglés).
+Es común que una aplicación tenga un mecanismo que provea al usuario un medio para acceder a su cuenta en caso de que olvide su contraseña. Por favor, para más detalles sobre esta característica, vea [[Forgot Password Cheat Sheet]] (en inglés).
@@ Line 154: / Line 154: @@
 Si no se utiliza TLS u otro transporte fuerte para la landing page de inicio de sesión, se permite a un atacante modificar el ''action'' del formulario de inicio de sesión, generando que las credenciales del usuario sean enviadas a una ubicación arbitraria.
-Si no se utiliza TLS u otro transporte fuerte para las páginas autentificadas que se habilitan luego del inicio de sesión un atancante puede ver la ID de sesión sin cifrar y comprometer la sesión autentificada del usuario.
+Si no se utiliza TLS u otro transporte fuerte para las páginas autentificadas que se habilitan luego del inicio de sesión, un atacante puede ver la ID de sesión sin cifrar y comprometer la sesión autentificada del usuario.

@@ Line 119: / Line 119: @@
 === Información adicional ===
-*Asegúrese de que todos los caracteres que el usuario tipea están realmente incluidos en la contraseña. Hemos visto sistemas que truncan la contraseña a una longitud inferior de la que el usuario provee (ej., truncada a los 15 caracteres cuando se han ingresado 20).
+*Asegúrese de que todos los caracteres que el usuario escribe están realmente incluidos en la contraseña. Hemos visto sistemas que truncan la contraseña a una longitud inferior de la que el usuario provee (ej., truncada a los 15 caracteres cuando se han ingresado 20).
 **Esto es manejado usualmente al establecer la longitud de TODOS los campos de contraseña exactamente como la longitud máxima de la contraseña. Esto es particularmente importante si su longitud máxima de contraseña es corta, como 20-30 caracteres.
@@ Line 125: / Line 125: @@
 Si la aplicación requiere políticas de contraseña más complejas, será necesario ser muy claro sobre cuáles son esas políticas.
 *La política requerida necesita ser indicada explícitamente en la página de cambio de contraseña
-** asegúrese de enumerar cada carácter especial que permite, para que sea evidente para el usuario
+** asegúrese de enumerar cada caracter especial que permite, para que sea evidente para el usuario
 Recomendación:
 *Lo ideal, sería que la aplicación indicara al usuario cómo escribir su nueva contraseña y cuánto de la directiva de complejidad de su nueva contraseña cumple
-**De hecho, el botón de envío debería verser atenuado hasta que la nueva contraseña reúna los requisitos establecidos en la política de complejidad de contraseña y la segunda copia de la nueva contraseña coincida con la primera. Esto hará que sea mucho más fácil, para el usuario, entender la política de complejidad y cumplirla.
+**De hecho, el botón de envío debería verse atenuado hasta que la nueva contraseña reúna los requisitos establecidos en la política de complejidad de contraseña y la segunda copia de la nueva contraseña coincida con la primera. Esto hará que sea mucho más fácil, para el usuario, entender la política de complejidad y cumplirla.

@@ Line 95: / Line 95: @@
 === Complejidad de la contraseña ===
-Las aplicaciones deberían imponer reglas de complejidad de contraseñas para evitar las contraseñas fáciles de adivinar. Los mecanismos de contraseñas deberían permitir al usuario, poder tipear casi cualquier caracter como parte de su contraseña, incluyendo el caracter de espacio. La contraseñas deberían, obviamente, ser sensibles a mayúsculas y minúsculas a fin de incrementar la complejidad de las mismas. Ocasionalmente, encontramos sistemas donde las contraseñas no son sensibles a mayúsculas y minúsculas, frecuentemente debido a problemas de sistemas heredados como los viejos ordenadores centrales que no tenían contraseñas sensibles a mayúsculas y minúsculas.
+Las aplicaciones deberían imponer reglas de complejidad de contraseñas para evitar las contraseñas fáciles de adivinar. Los mecanismos de contraseñas deberían permitir al usuario, poder tipear casi cualquier caracter como parte de su contraseña, incluyendo el caracter de espacio. Las contraseñas deberían, obviamente, ser sensibles a mayúsculas y minúsculas a fin de incrementar la complejidad de las mismas. Ocasionalmente, encontramos sistemas donde las contraseñas no son sensibles a mayúsculas y minúsculas, frecuentemente debido a problemas de sistemas heredados como los viejos ordenadores centrales que no tenían contraseñas sensibles a mayúsculas y minúsculas.
@@ Line 107: / Line 107: @@
 *al menos 10 caracteres
 *no más de 128 caracteres
-*no más de 2 caracteres indénticos consecutivos (ej., 111 no está permitido)
+*no más de 2 caracteres idénticos consecutivos (ej., 111 no está permitido)

@@ Line 43: / Line 43: @@
 Cambios recientes generaron que el número de falsos negativos se viera incrementado, particularmente debido a:
 * El aumento de popularidad de las sub-direcciones de proveedores como Gmail (comúnmente usando <tt>+</tt> como token en la parte local para afectar la entrega)
-* Nuevos gTLDs con nombres largos (muchas experesiones regulares comprueban el número y longitud de cada etiqueta en el dominio)
+* Nuevos gTLDs con nombres largos (muchas expresiones regulares comprueban el número y longitud de cada etiqueta en el dominio)
 Siguiendo el RFC 5321, las mejores prácticas para la validación de una dirección de correo electrónico deberían ser:
@@ Line 52: / Line 52: @@
 Para asegurarse que una dirección de entrega sea verídica, la única forma es enviar un correo electrónico al usuario y que éste deba tomar alguna acción para confirmar que lo ha recibido.
-Más allá de confirmar que la dirección de correo electrónico es válida y reciba los mensajes, esto también proporciona una confirmación positiva de que el usuario tiene acceso al buzón de correo y es probable esté autorizado a usarlo. Esto no significa que otros usuarios no tengan acceso al mismo buzón de correo, cuando por ejemplo el usuario utiliza un servicio que genera una dirección de correo electrónico deshechable.
+Más allá de confirmar que la dirección de correo electrónico es válida y reciba los mensajes, esto también proporciona una confirmación positiva de que el usuario tiene acceso al buzón de correo y es probable que esté autorizado a usarlo. Esto no significa que otros usuarios no tengan acceso al mismo buzón de correo, cuando por ejemplo el usuario utiliza un servicio que genera una dirección de correo electrónico desechable.

@@ Line 23: / Line 23: @@
 === Dirección de correo electrónico como ID de usuario ===
-Muchos sitios utilizan la dirección de correo electrónico como identificador de usuario, lo cual es un buen mecanismo para segurar un identificador único por cada usuario sin agregarle a éstos la carga de tener que recordar un nuevo nombre de usuario. Sin embargo, muchas aplicaciones Web no tratan correctamente las direcciones de correo electrónico, debido a conceptos equivocados sobre lo que constituye una dirección de correo electrónico válida.
+Muchos sitios utilizan la dirección de correo electrónico como identificador de usuario, lo cual es un buen mecanismo para asegurar un identificador único por cada usuario sin agregarle a éstos la carga de tener que recordar un nuevo nombre de usuario. Sin embargo, muchas aplicaciones Web no tratan correctamente las direcciones de correo electrónico, debido a conceptos equivocados sobre lo que constituye una dirección de correo electrónico válida.
 En concreto, es completamente válido tener una dirección correo electrónico que:
@@ Line 35: / Line 35: @@
 Al momento de estar escribir este artículo, el RFC 5321 es el estándar actual que define el protocolo SMTP y lo que constituye una dirección de correo electrónico válida.
-Por favor, tenga en cuenta que las direcciones de correo electrónico deberías ser consideradas datos públicos. En aplicaciones de alta seguridad, podrías asignarse los nombres de usuario y ser secretos en lugar de ser datos públicos definidos por el usuario.
+Por favor, tenga en cuenta que las direcciones de correo electrónico deberían ser consideradas datos públicos. En aplicaciones de alta seguridad, podrían asignarse los nombres de usuario y ser secretos en lugar de ser datos públicos definidos por el usuario.
 ==== Validación ====
-Muchas aplicaciones Web contienen expresiones regulares informáticamente muy costosas e inexactas contain computationally expensive and inaccurate regular expressions para intentar validar las direcciones de correo electrónico.
+Muchas aplicaciones Web contienen expresiones regulares informáticamente muy costosas e inexactas para intentar validar las direcciones de correo electrónico.
 Cambios recientes generaron que el número de falsos negativos se viera incrementado, particularmente debido a:

@@ Line 25: / Line 25: @@
 Muchos sitios utilizan la dirección de correo electrónico como identificador de usuario, lo cual es un buen mecanismo para segurar un identificador único por cada usuario sin agregarle a éstos la carga de tener que recordar un nuevo nombre de usuario. Sin embargo, muchas aplicaciones Web no tratan correctamente las direcciones de correo electrónico, debido a conceptos equivocados sobre lo que constituye una dirección de correo electrónico válida.
-Specifically, it is completely valid to have an mailbox address which:
+En concreto, es completamente válido tener una dirección correo electrónico que:
 * Es sensible a mayúsculas y minúsculas en la parte local
 * Tiene caracteres no alfanuméricos en la parte local (incluyendo + y '''@''')

← Older revision		Revision as of 20:58, 2 August 2015
Line 284:		Line 284:

	El manejo de sesiones está directamente relacionado a la autentificación. Las '''Directrices generales para el manejo de sesiones''' previamente disponibles en esta Hoja de referencias de Autentificación de OWASP han sido integradas en [[Session Management Cheat Sheet]] (NdT: hoja en proceso de traducción).		El manejo de sesiones está directamente relacionado a la autentificación. Las '''Directrices generales para el manejo de sesiones''' previamente disponibles en esta Hoja de referencias de Autentificación de OWASP han sido integradas en [[Session Management Cheat Sheet]] (NdT: hoja en proceso de traducción).
		+

	= Gestión de contraseñas =		= Gestión de contraseñas =