Google archivos - Pablo Alejandro Fain

Usando CSP para incrementar la seguridad de tu sitio web

enero 4, 2019enero 3, 2019 por Pablo Alejandro Fain

Hacía ya algún tiempo venía manejando la idea de implementar CSP en mi blog de WordPress. CSP -o Content Security Policy, por sus siglas en inglés- es un estándar que define un conjunto de orígenes pre-aprobados desde los que un navegador puede cargar recursos cuando visita un sitio web. Ayuda a prevenir ataques de Cross Site Scripting (XSS), data injection, entre otros. Cuando el navegador visita un sitio web tiene que cargar fuentes, hojas de estilo, imágenes, scripts, etc. Por ejemplo, este blog utiliza la fuente Open Sans de Google por lo que cada vez que alguien lo visite su navegador estará haciendo una llamada hacia el dominio fonts.googleapis.com. También utiliza las fotos de perfil de Gravatar, a través de secure.gravatar.com. Y así con el resto de los recursos. Para habilitar CSP, el sitio web debe enviar un encabezado HTTP especial llamado Content-Security-Policy (también conocido como X-Content-Security-Policy). Como alternativa al encabezado HTTP se puede implementar CSP utilizando la etiqueta <meta>. Por ejemplo: Podríamos decir que CSP es una suerte de lista blanca de orígenes y, por ende, una forma de prevenir ataques por inyección de código malicioso. Cada plataforma web tiene su forma de manejar los encabezados HTTP. Para WordPress, por ejemplo, …

Atacantes lograron eludir la autenticación multifactor

diciembre 19, 2018diciembre 19, 2018 por Pablo Alejandro Fain

Cuando de buenas prácticas para la protección de nuestra presencia en línea se trata, ustedes saben que mi principal recomendación es habilitar la autenticación multifactor (doble factor de autenticación, o autenticación de dos pasos). Pero los atacantes siempre se las ingenian, y esta vez lograron engañar a los usuarios para hacerse del código temporal (token) necesario para completar la autenticación multifactor. Un reporte publicado hace apenas algunas horas por Aministía Internacional muestra en detalle cómo se dieron estos ataques a cuentas de usuarios de Gmail y Yahoo, incluso a aquellos con autenticación multifactor habilitada. Las víctimas eran dirigidas a un sitio apócrifo, idéntico al de inicio de sesión de Gmail o de Yahoo, técnica conocida como phishing. Una vez que el usuario ingresaba su dirección de e-mail y contraseña, la misma infraestructura en la que el sitio falso estaba almacenada realizaba el intento de inicio de sesión en el servicio real. Si éste requeria la utilización de un factor adicional, lo notificaba al sitio apócrifo para que éste se lo requiriera al usuario. Una vez que la víctima ingresaba el token, el atacante obtenía acceso a la cuenta real. En algunos casos se detectó incluso que el atacante había generado …

Las cuentas Microsoft ahora soportan autenticación sin contraseña mediante dispositivos FIDO 2

diciembre 6, 2018noviembre 24, 2018 por Pablo Alejandro Fain

Microsoft y Yubico anunciaron esta semana que los usuarios de cuentas Microsoft (aquellas con dominio terminado en msn.com, hotmail.com, outlook.com, etc.) podrán iniciar sesión sin necesidad de ingresar una contraseña. Simplemente deberán insertar un dispositivo compatible con el estándar FIDO2/WebAuthn, como la YubiKey 5. Los usuarios de Office 365 deberán esperar unos meses más. Hace ya algunos años que Microsoft viene trabajando en su estrategia de inicio de sesión sin contraseñas -passwordless-. La aprobación de inicio de sesión a través de las notificaciones push de su aplicación Microsoft Authenticator son un gran ejemplo. El usuario ingresa su dirección de e-mail, presiona Siguiente y aprueba el inicio de sesión desde su teléfono o wearable. Pero ahora le llegó la oportunidad a las llaves de autenticación. En este post hablaba sobre las diferentes formas de autenticación multifactor y mencionaba las dos llaves de autenticación más populares, la YubiKey y la Titan -de Google-. Estas llaves trabajan con el estandar U2F, entre otros. Cuando conectamos por primera vez una llave U2F -o Universal Second Factor, por sus siglas en inglés- para asociarla con un sitio, ésta genera una clave pública y una privada (encriptada). La clave pública es enviada al proveedor de autenticación …

¿Cómo funciona la autenticación multifactor?

enero 11, 2019agosto 18, 2018 por Pablo Alejandro Fain

Esta es la tercera de una serie de entregas dedicadas a temas de seguridad en Internet y cómo incrementar nuestro escudo protector cuando estamos en línea. En la primera hablamos sobre los administradores de contraseñas y en la segunda sobre las -cada vez más populares- violaciones de datos. Hoy vamos a hablar sobre el doble factor de autenticación, también conocido como two factor authentication, 2FA, o MFA -multi factor authentication-, por sus siglas en inglés. El concepto de doble factor de autenticación (aunque algunos lo llaman autenticación de dos pasos, pero eso lo vamos a hablar más adelante) dice que el usuario debe ser “desafiado” a utilizar dos mecanismos de autenticación entre los siguientes tres: Algo que sabés Algo que tenés Algo que sos Algo que sabés suele ser tu contraseña, y este es el primer factor de autenticación que usamos en todos lados. Algo que sos podría ser tu huella digital, reconocimiento facial, de retina, entre otros. Pero vamos a hablar del segundo mecanismo de autenticación más utilizado en el mundo: algo que tenés. Algo que tenés puede ser una tarjeta inteligente –smart card-, una llave de autenticación (como las YubiKey) o un token (físico o virtual). Para que …

Todos necesitamos un administrador de contraseñas

enero 4, 2019febrero 24, 2018 por Pablo Alejandro Fain

Esta es la primera de una serie de entregas dedicada a temas de seguridad en Internet y cómo incrementar nuestro escudo protector cuando estamos en línea. No es nada nuevo que quienes trabajamos en IT, y en especial aquellos que nos enfocamos en cuestiones de ciberseguridad o seguridad informática insistamos en la necesidad de usar un administrador de contraseñas. Siempre que hablo con alguien sobre ciberseguridad y cómo proteger los sistemas de una organización (aunque aplica perfectamente a la computadora que Mabel, de 80 años, usa para hablar por Skype con sus nietos que viven en el interior), insisto en que la responsabilidad principal recae sobre el usuario. El usuario que está frente a su computadora o celular es, en una gran cantidad de casos, la primer barrera que debe atravesar un atacante para obtener acceso a los sistemas. Suplantación de identidad (phishing), ingeniería social, malware, y la lista podría seguir. Todos tienen como principal punto de interés al usuario. Pero algo que muchos pasan por alto es el tema de las contraseñas. Tenemos tan asimilado el proceso de iniciar sesión en los sitios que utilizamos a diario que nos olvidamos de la importancia de las contraseñas. La contraseña es …

Cómo planea bloquear el acceso a Uber el gobierno argentino

enero 4, 2019abril 19, 2016 por Pablo Alejandro Fain

En la tarde de ayer, lunes 18 de abril, el Ministerio Público Fiscal solicitó al Ente Nacional de Telecomunicaciones (ex CNC) que ordene a los operadores de telefonía móvil y de servicios de Internet el bloqueo de todas las plataformas digitales de la compañía estadounidense. Esta medida se efectua, según el diario local La Nacion, en el marco de una investigación que acusa a Uber por el uso indebido del espacio público con fines de explotación comercial. Pero… ¿Cómo se bloquea el acceso a un sitio o aplicación en un país entero? Existen dos mecanismos que se utilizan habitualmente para estos casos. El primero está relacionado con el bloqueo a nivel DNS. La infraestructura de DNS, por sus siglas en inglés de Domain Name System, es la encargada de “traducir” las direcciones URL que escribimos en nuestros navegadores en direcciones IP. Para ponerlo en un ejemplo práctico, imaginen que si no existieran los DNS deberíamos escribir 64.233.169.99 en lugar de www.google.com para realizar una búsqueda, o 132.245.70.98 en lugar de www.outlook.com para acceder a nuestro correo electrónico. Cada vez que escribimos alguna dirección URL en nuestro navegador, o cada vez que utilizamos una aplicación en el teléfono móvil, nuestro dispositivo realiza una “consulta” a los servidores de DNS que tiene configurados y …

Google comenzará a penalizar a sitios no compatibles con dispositivos móviles

enero 4, 2019marzo 18, 2015 por Pablo Alejandro Fain

Los rumores comenzaron a circular hace algunos meses, cuando el gigante de las búsquedas en Internet adaptó su página de resultados identificando a los sitios compatibles con dispositivos móviles con la frase Mobile-friendly: Días atrás Google puso fin al misterio, asegurando que a partir del 21 de abril próximo pondrá en marcha un nuevo algoritmo de búsqueda que planea “penalizar” a los sitios que no sean compatibles con dispositivos móviles. Mediante un artículo publicado en el blog oficial de webmasters, amplían los detalles de esta decisión indicando que el nuevo algoritmo tomará como señal de ranking si el sitio tiene una versión compatible con dispositivos móviles o no. En caso que si, el sitio tendrá mejor posicionamiento en la página de resultados de búsqueda. Para los administradores de web, sigue vigente la sección Usabilidad móvil que permite identificar los errores detectados por Google en los intentos de rastreo de su motor de búsqueda y la nueva herramienta de verificación de compatibilidad con dispositivos móviles que, en caso de detectar que el sitio no es compatible con estos dispositivos, ofrecerá algunas sugerencias para mejorar su visualización: En el pasado, Google ya había modificado su algoritmo priorizando en los resultados de búsqueda a aquellos sitios que operen bajo protocolo de transferencia seguro (HTTPS). ¡Hasta la …

Agregando perfiles sociales a los resultados de búsqueda de Google

enero 4, 2019enero 20, 2015 por Pablo Alejandro Fain

Hace algún tiempo Google publicó las instrucciones para vincular los resultados de búsqueda de los sitios en los que publicamos contenido con nuestra información de autor y foto de perfil. Tiempo más tarde, sin embargo, se arrepintió y decidió revertir este cambio ya que, según indicaron, los resultados que mostraban la información del autor vieron reducida su cantidad de clicks. Ahora han decidido dar un paso más en la personalización de los resultados de búsqueda, permitiendo agregar los perfiles de redes sociales a los resultados de búsqueda relacionados con cada usuario. El proceso es bastante sencillo, y requiere que los usuarios u organizaciones que deseen mostrar sus perfiles sociales en los resultados de búsqueda de Google agreguen un pequeño script en sus páginas/blogs. En el siguiente ejemplo podemos observar el script para una organización: { “@context” : “http://schema.org”, “@type” : “Organization”, “name” : “Nombre de la organización”, “url” : “http://www.your-site.com”, “sameAs” : [ “http://www.facebook.com/perfil”, “http://www.twitter.com/perfil”, “http://plus.google.com/perfil”] } Y a continuación el script para un usuario: { “@context” : “http://schema.org”, “@type” : “Person”, “name” : “Nombre del usuario”, “url” : “http://www.your-site.com”, “sameAs” : [ “http://www.facebook.com/perfil”, “http://instagram.com/perfil”, “http://www.linkedin.com/in/perfil”, “http://plus.google.com/perfil”] } El script puede ser ubicado en cualquier lugar de la página de la organización o el usuario, como el encabezado o el cuerpo. …

Todo lo que necesitas saber acerca de POODLE

enero 4, 2019octubre 16, 2014 por Pablo Alejandro Fain

Hace algunos días fue confirmada una vulnerabilidad de la que se habían oído rumores tiempo atrás. Se trata de POODLE (Padding Oracle On Downgraded Legacy Encryption, por sus siglas en inglés), un fallo en el protocolo SSL 3.0 que podría permitir ataques del tipo MitM (Man in the Middle) en los que un atacante podría leer y modificar la información intercambiada entre dos equipos sin generar ninguna sospecha.

El fallo, registrado bajo el identificador CVE-2014-3566, fue descubierto por Bodo Möller, Thai Duong and Krzysztof Kotowicz del equipo de Seguridad de Google y publicado en el blog de la compañía.

Si bien la vulnerabilidad no es tan seria como sí lo fueron Heartbleed o Shellshock, debe ser tenida en cuenta y mitigada por los administradores de sistemas. SSL 3.0 ya cumplió 18 años, pero aún es utilizado por los navegadores para “escapar” de algunos errores que impedirían el correcto uso de protocolos más recientes. De esta manera, un atacante podría forzar el uso de SSL 3.0 para explotar sus deficiencias.

Usuarios hogareños

Para el caso de los usuarios hogareños u organizaciones que quieran proteger a sus usuarios de esta vulnerabilidad y evitar que un atacante intercepte la información intercambiada con un servidor que aún no ha mitigado el fallo, alcanza con deshabilitar el protocolo SSL 3.0 en los navegadores de internet.

It’s time to replace SHA-1 certificates

enero 4, 2019octubre 7, 2014 por Pablo Alejandro Fain

It has been 20 years since SHA-1, the world’s most used encryption method, was released.

SHA-1 is an encryption method developed by the National Security Agency of the United States and is considered a federal information processing standard for the Government of that country. The method of output of SHA-1 produces a 160 bits (20 bytes) secure hash value, equivalent to an hexadecimal number of 40 digits long.

In 2005 were published two investigations in which big vulnerabilities in this mechanism were demonstrated. It happens that the hashes have a natural enemy called “collisions”. Collisions are the possibility of encountering an identifier that is notunique, i.e. that a same SHA-1 represent two different incoming data flows through brute force attacks.

By definition, we could say that there is 1 chance in 1208925819614629174706176 (2⁸⁰) of generating collisions in SHA-1. However, at the beginning of 2005, a group of Chinese researchers reduced the number of attempts to 2⁶⁹. Finally, researches of the Macquarie University of Australia were able to reduce it to 2⁵²(about 2000 times faster than expected).

As a result, the CA/Browser Forum recommended in 2011 start to leave SHA-1 as soon as possible. In fact, the Government of the United States stopped using this mechanism in 2010.

Usuarios hogareños

About SHA-2