“Ahora puedes eliminar por completo la contraseña de tu cuenta de Microsoft”, escribió Vasu Jakkal, vicepresidente corporativo de Seguridad, Cumplimiento e Identidad de la compañía, en una entrada de blog.

En lugar de contraseñas, Microsoft (MSFT) permitirá a los usuarios iniciar sesión en estos servicios con la aplicación Authenticator de la empresa, que produce un código de inicio de sesión único y numerado cada pocos segundos, o con Windows Hello, que permite a los usuarios iniciar sesión mediante el reconocimiento facial, una huella dactilar o un pin único.

Los usuarios de Microsoft también pueden comprar una llave de seguridad externa, como una unidad USB con información de inicio de sesión almacenada en ella, o registrar un número de teléfono al que Microsoft envía un código de verificación.

El cambio de Microsoft se produce tras el aumento de los ciberataques en el último año. Con la mayoría de los empleados de las empresas trabajando desde casa debido a la pandemia de coronavirus, los hackers tienen muchas más vías para infiltrarse en los sistemas de una empresa, y comprometer las contraseñas en una de sus estrategias más comunes. (Microsoft también ha tenido su cuota de problemas de seguridad en los últimos meses, con sus servicios vinculados a múltiples hackeos y violaciones de alto perfil).

Las contraseñas suelen acabar a la venta en la web oscura, donde se compran y se utilizan para piratear aún más servicios. Los piratas informáticos han ido incluso a por los gestores de contraseñas que pretenden hacer más seguros los datos de inicio de sesión, con el popular servicio LastPass hackeado en 2015.

Según Microsoft, cada segundo se producen 579 ataques a contraseñas, lo que suma 18.000 millones de ataques al año. Y los expertos en ciberseguridad han dicho que el eslabón más débil es el comportamiento humano: nuestra tendencia a reutilizar la misma contraseña en todas las cuentas para que sea fácil de recordar, o a crear patrones para diferentes contraseñas que son fáciles de adivinar para los hackers.

“Las contraseñas débiles son el punto de entrada de la mayoría de los ataques a las cuentas de empresas y consumidores”, afirma Jakkal.

Microsoft parece predicar con el ejemplo en su esfuerzo por ser pionero en un futuro sin contraseñas. Según Jakkal, casi todos los empleados de la empresa se conectan ahora a sus cuentas corporativas sin contraseñas.

Otras empresas, como Google y Apple, también ofrecen alternativas a las contraseñas –enviando una notificación a otro dispositivo para verificar la identidad, por ejemplo–, pero esas soluciones aún no han sustituido por completo la necesidad de teclear una contraseña.

Fuente: CNN

Muchos propietarios de sitios web usan certificados EV porque creen que las señales de la interfaz de usuario EV y la información de identidad (nombre, país) que se muestran en la barra de URL proporcionan una herramienta para ayudar a proteger a sus clientes y su marca de sitios de phishing falsos. Los datos de identidad incluidos en un certificado EV también son utilizados por otros, como el software antiphishing, para proteger a los usuarios.

Sin embargo, Google y Mozilla creen que los usuarios no toman decisiones de seguridad basadas en la interfaz de usuario EV en la barra URL, por lo que planean eliminarlo de sus navegadores. Esto significa que después de la eliminación de la interfaz de usuario de EV, los sitios web EV que tienen información de identidad y sitios web anónimos protegidos por certificados de dominio validado (DV) aparecerán inicialmente iguales para los usuarios de Chrome y Firefox; no habrá forma de mostrar a los usuarios de manera proactiva la identidad de su organización oficial a menos que el usuario haga clic en el símbolo de candado y busque sus datos de identidad. 

En Chrome 77:

En Firefox 70:

Si desea soporte técnico con respecto a este comunicado, mandar un correo a: soporte.bm@bmtech.pe o llamar al número (01) 246 1991.

Fuente: CA Secutiry Council

A inicios del 2020, los grandes navegadores(Chrome, Edge, Firefox, Safari) dejarán de soportar de soportar TLS 1.0 y TLS 1.1

En Internet, 20 años es una eternidad. TLS 1.0 cumplirá 20 años en enero de 2019. Este protocolo ha protegido miles de millones de conexiones de ataques cibernéticos. 

El Internet Engineering Task Force (IETF) no recomienda el uso de las versiones TLS antes mencionadas. Este documento describe las razones técnicas con más detalle.

Se desactivará TLS 1.1 al mismo tiempo. TLS 1.1 solo aborda una limitación de TLS 1.0 que puede abordarse de otras maneras. Datos de la telemetría de Firefox indican que solo el 0.1% de las conexiones usan TLS 1.1.

El gráfico indica que muchos sitios ya usan TLS 1.2 o superior. TLS 1.2 es un requisito previo para HTTP / 2, que puede mejorar el rendimiento del sitio. Recomendamos que los sitios usen un perfil moderno de TLS 1.2 a menos que tengan necesidades especializadas.

Para los sitios que necesitan actualizarse, el TLS 1.3 recientemente lanzado incluye un diseño de núcleo mejorado que los criptógrafos han analizado rigurosamente. TLS 1.3 también puede hacer conexiones más rápidas que TLS 1.2. Firefox ya hace muchas más conexiones con TLS 1.3 que con TLS 1.0 y 1.1 combinados.

Entendemos que actualizar algo tan fundamental como TLS puede llevar algún tiempo. Este cambio afecta a una gran cantidad de sitios. Es por eso que estamos haciendo este anuncio antes de la fecha de eliminación en 2020 de TLS 1.0 y TLS 1.1.

Para mayor información ingresar al sitio de soporteSSL

Si desea soporte técnico con respecto a este comunicado, mandar un correo a: soporte.bm@bmtech.pe o llamar al número (01) 246 1991.

Fuente: Blog Mozilla

¿Su sitio web se abre automáticamente a la versión HTTP en lugar de HTTPS y muestra el mensaje No Seguro en la barra de direcciones?

Este problema se debe a una mala configuración en el servidor, el cual cuenta con dos protocolos de comunicación con el cliente, uno para HTTP (generalmente por el puerto 80) y otro para HTTPS (generalmente por el puerto 443). Lo recomendable sería que solo se pueda ingresar al sitio por HTTPS, debido a que esta comunicación está cifrada de extremo a extremo y los datos e información sensible no podrían ser descifrados por posibles atacantes.

Imagen ilustrativa:

Ejemplo práctico:

Supongamos que nuestra casa es el servidor de nuestro sitio web. Hay dos formas de ingreso a nuestro domicilio, la puerta(HTTPS) y la ventana(HTTP). Si la ventana está abierta el atacante podrá ingresar a la casa y robar nuestras pertenencias por más que tengamos la puerta cerrada.

Conclusión: De nada sirve tener instalado un certificado SSL en nuestro sitio web, si existen otras vías de comunicación no seguras.

Para mayor información ingresar al sitio de soporteSSL

Si desea soporte técnico con respecto a este inconveniente, mandar un correo a: soporte.bm@bmtech.pe o llamar al número (01) 246 1991.

Fuente: S.M.E. Instituto Nacional de Ciberseguridad de España

La SUNAT emitió un comunicado el día 21/05/2019 informando sobre la actualización o cambio del certificado digital SSL de todos sus servicios web.

Aquí se puede apreciar el nuevo certificado instalado en el webservice de facturación y en los demás subdominios de sunat.gob.pe 

¿Pero, por qué sugiere actualizar las Autoridades de Certificación (CA) ?

Los certificados mostrados fueron emitidos en el año 2000 por lo que el 100% de trustores de java, php u otro lenguaje de programación los contienen.

Certificado raíz:

Certificado intermediario 1:

El certificado mostrado es un Sectigo emitido el año 2018; por lo tanto, debe asegurarse que aparezca en la almacén de certificados de confianza.

En el caso de Java, el almacén de confianza es un archivo que contiene los certificados raíz para las Autoridades de Certificación (CA).

El almacén de confianza viene incluido con el JDK / JRE y se llama cacerts.jks y se encuentra en las librerías del java en la carpeta security. Este archivo debe contener el certificado de la SUNAT.

El almacén de confianza se utiliza siempre que nuestro código Java establece una conexión a través de SSL.

Para PHP, cURL utiliza un solo archivo con todas las CA en él. Para agregar una nueva CA a cURL / PHP, debe obtener un paquete completo, agregar el certificado de la SUNAT al paquete y luego decirle a PHP que use el paquete personalizado. Edite el archivo cacert.pem y agregue su nueva clave pública de CA en la parte inferior.

Si está ejecutando al menos php 5.3.7, puede editar el php.ini agregando la linea

openssl.cafile = {Ruta}/cacert.pem

La validación de la cadena de certificados  y la omisión de algún certificado de esta podría generar errores a la hora de realizar la conexión.

Problemas del Facturador Sunat. Después de haber importado un certificado digital en el Facturador SUNAT, al momento de generar un comprobante, podríamos obtener el siguiente error:

Lo más lógico sería pensar, que el certificado digital es incorrecto, o no es compatible con el Facturador Sunat. En la Consola de Administración de Certificados de Microsoft, se puede apreciar que el certificado es conforme.

En el ejemplo mostrado, el alias o nombre descriptivo del certificado es “ar superadmin” y por lo tanto, tiene un espacio en blanco.

Este mensaje se debe a que el SFS tiene un bug (error) cuando se importa un certificado; ya que al parecer, no permite la importación de certificados digitales con un alias que contenga espacios en blanco.

El problema reside en el método siguiente:

pe.gob.sunat.servicio2.registro.service.BandejaDocumentosServiceImpl#importarCertificado

Exactamente en la parte resaltada: aliasPfx

El problema estaría resuelto si se agregaran comillas dobles al inicio y final de aliasPfx

Un equipo de investigadores ha revelado un nuevo ataque criptográfico esta semana que puede interrumpir el tráfico TLS cifrado, lo que permite a los atacantes interceptar y robar datos que antes se consideraban seguros.

Este nuevo ataque de degradación, que no tiene un nombre elegante como la mayoría de los ataques de criptografía, funciona incluso contra la última versión del protocolo TLS, TLS 1.3, lanzado en agosto del 2018 y considerado seguro.

El nuevo ataque criptográfico no es nuevo, en sí. Es otra variación del ataque original ‘Bleichenbacher Oracle’.

El ataque original recibió su nombre del criptógrafo suizo Daniel Bleichenbacher, quien en 1998 demostró un primer ataque práctico contra sistemas que utilizan el cifrado RSA en concierto con la función de codificación PKCS # 1 v1.

A lo largo de los años, los criptógrafos han desarrollado variaciones en el ataque original, como en 2003, 2012, 2012, 2014, 2014, 2014, 2015, 2016(DROWN), 2017 (ROBOT) y 2018.

El motivo de todas estas variaciones de ataque se debe a que los autores del protocolo de cifrado TLS decidieron agregar contramedidas para hacer que los intentos de adivinar la clave de descifrado RSA sean más difíciles, en lugar de reemplazar el inseguro algoritmo RSA.

Estas contramedidas se han definido en la Sección 7.4.7.1 del estándar TLS (RFC 5246), que muchos proveedores de hardware y software a lo largo de los años han malinterpretado o no han cumplido con la ley.

Esta falla en la implementación de las mitigaciones adecuadas ha hecho que muchos servidores, enrutadores, firewalls, VPN y bibliotecas de codificación compatibles con TLS sigan siendo vulnerables a las variaciones de ataques de Bleichenbacher, que detectaron y explotaron problemas en los procedimientos de mitigación incorrectos.

Las últimas variaciones de los ataques de Bleichenbacher se describieron en un documento técnico publicado el miércoles de esta semana, y titulado “The 9 Lives of Bleichenbacher’s CAT: New Cache ATtacks on TLS Implementations.”.

Siete investigadores de todo el mundo encontraron otra forma de romper RSA PKCS # 1 v1.5, la configuración RSA más común utilizada para cifrar las conexiones TLS en la actualidad. Además de TLS, este nuevo ataque Bleichenbacher también funciona contra el nuevo protocolo de cifrado QUIC de Google.

“El ataque aprovecha una fuga de canal lateral a través de los tiempos de acceso de caché de estas implementaciones para romper los intercambios de claves RSA de las implementaciones TLS”, dijeron los investigadores.

Incluso la versión más reciente del protocolo TLS 1.3, donde el uso de RSA se ha mantenido al mínimo, puede ser degradado en algunos escenarios a TLS 1.2, donde funciona la nueva variación de ataque de ‘Bleichenbacher Oracle’.

“Probamos nueve implementaciones TLS diferentes contra ataques de caché y se encontró que siete eran vulnerables: OpenSSL, Amazon s2n, MbedTLS, Apple CoreTLS, Mozilla NSS, WolfSSL y GnuTLS”, dijeron los investigadores.

Las versiones actualizadas de todas las librerías afectadas se publicaron simultáneamente en noviembre de 2018, cuando los investigadores publicaron un borrador inicial de su trabajo de investigación.

Para obtener más detalles, se han asignado los siguientes identificadores de CVE a los errores de seguridad que habilitan este nuevo ataque Bleichenbacher: CVE-2018-12404, CVE-2018-19608, CVE-2018-16868, CVE-2018-16869 y CVE-2018- 16870.

Las dos librerías que no eran vulnerables eran BearSSL y BoringSSL de Google.

Fuente: ZD Net

Los cibercriminales están al acecho; por eso no es raro escuchar sobre incidentes relacionados con robo de credenciales, contraseñas, instalación de malware desde fuentes en la web e incluso ransomware.

Todas estas brechas en la seguridad se deben mayormente a la ingeniería social – cuando hacemos clic a un enlace desconocido o cuando descargamos contenido de dudosa procedencia. Es un error común de cometer, especialmente cuando el sitio web parece legítimo, todo lo mencionado anteriormente se puede evitar, si es que sabemos el significado de SSL.

Si lo pensamos bien, probablemente hemos notado una barra verde en el sitio web de algún banco, y siempre lleva el nombre del mismo.

Este es un tipo de certificado SSL conocido como Validación Extendida (EV) y es el que asegura a sus clientes no ser víctimas de nefastos hackeos.

En este artículo, se explicará qué significa SSL, y su importancia en el rubro de la seguridad de la información.

¿Qué es SSL, y cómo trabaja?

SSL (Secure Sockets Layer) es la implementación estándar para establecer una segura y encriptada conexión entre dos puntos en la internet: su ordenador y un servidor web.

SSL ha sido destituido por SSL/TLS o Secure Sockets Layer/Transport Layer Security, pero se le sigue conociendo como SSL por simplicidad. También es la base para el HTTP seguro o HTTPS, es básicamente un sitio web transportado a través de un protocolo de transferencia de hipertexto que pasa por una conexión segura y cifrada.

En el diagrama anterior, el cliente busca la autenticación y la identificación del servidor web, el cual presenta a través de su certificado SSL. En este caso, el sitio web no puede simplemente decir “BM Cert”; necesita un proveedor de certificados de confianza para establecer esta identidad. En realidad, esto toma la forma de un protocolo de enlace SSL, que es una comunicación de ida y vuelta para establecer una conexión e identificación antes de que el navegador web realmente solicite la información necesaria.

¿Puedo adquirir un certificado SSL de un proveedor barato o gratuito?

No todos los certificados SSL son hechos de la misma manera.

Existen certificados gratuitos como los de Let’s Encrypt, que no ofrecen ningún tipo de beneficio adicional al certificado y tienen un período de vigencia de 90 días.

Sin embargo, BM Cert ofrece los certificados de Entrust, la cual es una entidad certificadora de confianza reconocida a nivel mundial, y sus certificados tienen un período de validez máximo de 2 años. Además, cuenta con un software sofisticado llamado SiteLock, el cual, analiza su sitio web a diario, detectando códigos dañinos, malware u otros ataques maliciosos que podrían amenazar, interrumpir o cerrar su sitio web.

En conclusión

SSL es ciertamente el mínimo para garantizar la seguridad de las transacciones y las comunicaciones entre clientes y servidores. Ningún sitio web o aplicación debe estar sin él, y usted, como usuario, debe desconfiar del envío de información a través de conexiones no seguras.

Fuente: thenextweb

Google ha anunciado sus planes de castigar a Symantec por sus certificados no confiables, debido a que esta última ha sido encontrada emitiendo de forma indebida 30.000 certificados de Validación Extendida (EV, Extended Validation) en los últimos años.

El estado de Validación Extendida de todos los certificados emitidos por las autoridades de Symantec ya no será reconocido por Google Chrome durante al menos un año, hasta que la compañía de seguridad informática corrija los errores (según Google) en la emisión de sus certificados con el fin de que puedan ser de nuevo confiables. El movimiento de considerar los certificados de Symantec como no confiables en Google Chrome procede de Ryan Sleevi, un ingeniero que forma parte del equipo tras el desarrollo del conocido navegador web.

Los certificados de Validación Extendida ofrecen supuestamente el nivel más alto de confianza y autenticación. Antes de ser emitidos, la autoridad certificadora tiene que verificar si las peticiones de las entidades son legales en existencia e identidad. Una de las partes más importantes del ecosistema de SSL es la confianza, si una autoridad certificadora no verifica correctamente la existencia e identidad legal de una entidad antes de emitir los certificados de Validación Extendida para sus dominios, la credibilidad de esos certificados podría verse comprometida.

El equipo de Google empezó la investigación el pasado 19 de enero y encontró que las políticas de emisión de certificados de Symantec en los últimos años era deshonesta y podría amenazar la integridad del sistema TLS, el cual es utilizado para autenticar y asegurar los datos de conexiones en Internet.

Viendo la situación, Google ha propuesto seguir los siguientes pasos como castigo a Symantec:

1. Los certificados de Validación Extendida emitidos por Symantec serán devaluados a certificados de dominios validados menos seguros. Esto significa que Google Chrome dejará de mostrar el nombre del dominio validado en la barra de direcciones durante un periodo de un año.
2. Para minimizar los riegos de una mayor emisión indebida de certificados, los nuevos certificados que se vayan a emitir tienen que tener períodos de validez no superiores a 9 meses para ser confiables en Google Chrome.
3. Google propone una desconfianza incremental, disminuyendo gradualmente el tiempo máximo de funcionamiento de los certificados de Symantec en las distintas versiones de Google Chrome, requiriendo de volver a emitir y validar los certificados una vez superado el periodo de tiempo establecido por Google.

Este sería el calendario que aplicaría el equipo de Google Chrome a los certificados de Symantec:

• Chrome 59 (Dev, Beta, Stable): 33 meses de validez (1023 días).
• Chrome 60 (Dev, Beta, Stable): 27 meses de validez (837 días).
• Chrome 61 (Dev, Beta, Stable): 21 meses de validez (651 días).
• Chrome 62 (Dev, Beta, Stable): 15 meses de validez (465 días).
• Chrome 63 (Dev, Beta): 9 meses de validez (279 días).
• Chrome 63 (Stable): 15 meses de validez (465 días).
• Chrome 64 (Dev, Beta, Stable): 9 meses de validez (279 días).

Esto significa que Google Chrome solo confiará en los certificados con hasta nueve meses de validez (279 días) a partir de Chrome 64 en todos los canales de desarrollo. Además, el gigante de Mountain View espera que los desarrolladores web sean conscientes de los riesgos que entrañan los certificados de Symantec.

La reacción de Symantec

La compañía de seguridad informática y autoridad certificadora ha respondido a Google diciendo que su reacción ha sido “exagerada y engañosa.”

Además de irresponsable, Symantec ha acusado al gigante del buscador de tener especial fijación sobre ella, debido a que “mientras que todas las grandes autoridades certificadoras han tenido eventos de mala emisión de certificados, Google ha señalado solo a la autoridad certificadora Symantec en su propuesta, incluso habiendo identificado eventos de mala emisión de otras autoridades certificadoras en la publicación del blog de Google.”

Fuente: The Hacker News