ESPAÑOLES CREAN UN WHATSAPP "INDESCIFRABLE" CUATRO VECES MÁS SEGURO QUE EL DNIE

ESPAÑOLES CREAN UN WHATSAPP "INDESCIFRABLE" CUATRO VECES MÁS SEGURO QUE EL DNIE

La empresa española Hermes Security Communication ha creado la aplicación de mensajería instantánea encriptadaHermes, que hace los mensajes "indescifrables" y proporciona"canal de comunicación seguro", en palabras del director de operaciones de la compañía, Miguel Ángel Lobato.

hermessecur.com

Apple iPhone vulnerabilidad SSL: ¿cómo sucedió, y lo que sigue?

Vulnerabilidad SSL de iPhone, iPad y en Mac OS X apareció en septiembre de 2012 -, pero la causa sigue siendo un misterio tan antiguo empleado llama a la falta de pruebas de "vergonzosa"

• 
• • Charles Arthur
  • theguardian.com , Martes 25 de febrero 2014 10.41 GMT
  • 
    

Vulnerabilidad SSL de Apple todavía está activo en Safari en Mac OS X, como se muestra en el sitio gotofail.com. Fotografía: Dominio público

Apple ha publicado una corrección urgente de una vulnerabilidad en su código (Secure Sockets Layer) SSL, utilizado para crear conexiones seguras a los sitios web a través de Wi-Fi u otras conexiones, para sus dispositivos iPhone, iPad y iPod Touch.

La solución, que ya está disponible tanto para iOS 6 iOS y 7, es un defecto que parece haber sido introducido en un cambio de código hecha antes del lanzamiento de iOS 6.0.

El fallo también afecta a los ordenadores Mac con Mac OSX - para el que no hay aún anunciada revisión, aunque Apple dice uno es "muy pronto".

El error, y su descubrimiento, plantean una serie de preguntas. Esto es lo que sabemos, lo que no sabemos, y lo que esperamos saber. (Apple no quiso hacer comentarios en relación a una serie de preguntas que ponemos sobre la vulnerabilidad.)

¿Cómo puedo comprobar si estoy vulnerable?

Ir a gotofail.com y ver cuál es el mensaje que recibe. Si todo va bien obtendrá un mensaje ecologista. En un dispositivo iOS, obtendrá una advertencia para actualizar. Si estás en un Mac, usted obtendrá ya sea un mensaje verde (su sistema es seguro) o un mensaje de color amarillo (en un navegador seguro señalando que otras aplicaciones podrían ser vulnerables) o un mensaje de color rojo (que le dice que parchear su navegador).

¿Qué debo hacer?

Si utiliza un iPhone, iPad o iPod Touch, actualice su software operativo. Ir a Ajustes -> General -> Actualización de Software. Para los dispositivos que utilizan iOS 7, la actualización a iOS 7.0.6, para los dispositivos de iOS 6, que no se pueden actualizar a iOS 7 (el iPhone 3GS o iPod Touch 4G), la actualización a 6.1.6.

Tenga en cuenta que Apple no está ofreciendo una actualización de iOS 6 para los dispositivos que se pueden actualizar a iOS 7 (iPhone 4, iPad 2, etc). Para aquellos, sus únicas opciones son para actualizar, o vivir peligrosamente.

Si usted está usando un Mac en una versión anterior del sistema operativo, es decir, 10.8 ("León de la Montaña") o una versión anterior, estás a salvo.

Si usted está usando un Mac en el más nuevo OS, 10.9 (también conocido como "Mavericks"), no utilizar Safari para conectarse a sitios web seguros hasta que haya una actualización. Utilice Mozilla Firefox o Chrome de Google: utilizan su propio código para conectarse a sitios web seguros. No se error se ha encontrado que en.

¿Qué hizo el error?

En teoría (y tal vez, en función de que lo sabía, en la práctica) que podría permitir que sus conexiones a sitios seguros para ser espiado y / o sus datos de acceso capturados. Actualización del software impide. El fallo afectó a la conexión cifrada SSL / TLS a sitios remotos.

¿Cuál es la importancia de SSL / TLS?

Cuando el dispositivo (portátil o PC) se conecta a un sitio web utilizando el método de SSL / TLS (Secure Sockets Layer / Transport Layer Security), el sitio presenta una cadena de cifrado "certificado" que identifica a sí mismo y la autoridad que emitió el certificado. Su dispositivo ya dispone de una lista de autoridades que gozan de la confianza de emisión, y se comprobará el nombre del sitio y el certificado se presenta con esa autoridad.

Es un proceso de cuatro pasos: 
• Sitio presenta una cadena de certificados 
• Certificado de su dispositivo comprueba del sitio coincide con el nombre del sitio que está en 
• Su dispositivo verifica que el certificado proviene de autoridad emisora ​​válido 
• Su navegador verifica que la firma cadena de certificado coincide con la clave pública del sitio .

En teoría, un certificado que tiene el nombre equivocado para el sitio, o que no ha sido emitido por la autoridad, o que está fuera de fecha, no será de confianza. En este punto, usted obtendrá un aviso en su navegador que le dice que hay algo malo y que no se debe proceder o sus datos podría estar en riesgo.

Un certificado falso podría significar que el sitio que se está conectando realmente está siendo dirigido por alguien que quiere recoger sus datos de acceso de los usuarios - como ha ocurrido en Irán. En 2011, el gobierno de ese país se calcula que han utilizado un certificado expedido por una autoridad certificada subvertido para configurar un sitio que (a través de la desviación DNS) podría pretender ser gmail.com de Google - y capturó los datos de los disidentes que pensaban que estaban ingresando a el sitio .

Así que es importante que el dispositivo puede autenticar certificados SSL correctamente. A veces usted se encontrará con los sitios donde se obtiene una advertencia de certificado, pero que decir que usted debe confiar en él (por ejemplo, porque se trata de una filial con un nombre diferente de la que posee el certificado). Tenga cuidado. No aprobaremos certificados sin ser cauteloso.

¿Cuál fue el error?

Debido a una reiterada línea singe de código en una biblioteca de Apple, casi cualquier intento de verificar un certificado en un sitio tendría éxito - si o no la firma del certificado era válido. Sólo sería un error si el certificado en sí no era válida (debido a ser fuera de fecha, por ejemplo).

El error está en el código de abajo: es la segunda "Ir a fallar;", y se llevará a cabo en todas las circunstancias.

estática OSStatus 
SSLVerifySignedServerKeyExchange (SSLContext * ctx, bool isRsa, SSLBuffer signedParams, 
uint8_t * firma, UInt16 signatureLen) 
{ 
OSStatus err; 
... 
if (! (err = SSLHashSHA1.update (& hashCtx, y serverRandom)) = 0) 
Ir a fallar; 
si ((err = SSLHashSHA1.update (& hashCtx, y signedParams)) = 0!) 
Ir a fallar; 
Goto fallar; 
if ((err = SSLHashSHA1.final (& hashCtx, y hashOut)) = 0!) 
Ir a fallar; 
... 
falte 
SSLFreeBuffer (& signedHashes); 
SSLFreeBuffer (& hashCtx); 
retorno err; 
}

¿Cuándo apareció el error?

En iOS 6.0, que se hizo pública en septiembre de 2012. Todavía no está claro exactamente cuándo apareció el error en Mac OSX, pero es probable que sea a la vez, ya que los sistemas operativos móviles y de escritorio utilizan árboles de códigos comunes. El error no estaba en la versión final de iOS 5, 5.1.1, lanzado 05 2012 . El mismo código, aparentemente se ha llevado adelante a través de iOS en 7 y Mac OSX 10.9, es incluso en las últimas versiones de iOS 7.1 , que aún está en beta.

El diff de las dos versiones de código muestra la adición de la declaración adicional en la línea 62:

SSL / TLS código de verificación de Apple, que muestra las diferencias entre las versiones. Las líneas rojas se eliminaron en la actualización, se añadieron las líneas verdes. El cambio fundamental que se rompió SSL es la línea 62. Fotografía: Dominio público

(Las líneas rojas son eliminados en el código actualizado, se añaden las líneas verdes.)

No es una diferencia obvia, a menos que estés en busca de ella, en cuyo caso, se destaca como un pulgar dolorido para cualquier programador.

¿Cómo surgió el error llegar?

Aquí tenemos dos teorías divergentes: accidente o conspiración. O es un error estúpido en el interior de manzana, o es un plan nefasto por la NSA (o los demás?) Para atrapar a las comunicaciones objetivos "mediante la plantación de una puerta trasera en una pieza clave del código.

Argumentando en contra del plan de la conspiración es el hecho de quede Apple publica este código en su página de código abierto . Sobre la base de que "muchos ojos hacen bichos poco profunda", y que toda la Internet ha sido capaz de mirar a esta epopeya "Ir a fallar" para las edades. Si la NSA pone sus puertas traseras secretos al descubierto de esta manera, lo que espera de ellos que se pueden encontrar mucho más rápido.

Argumentando por conspiración infame es - bueno, no mucho. Apple debería haber encontrado, pero no lo hizo, ya sea de sus compiladores (GCC y Clang) debería haber tirado un error, pero las pruebas de otros ha demostrado que no tiene a menos que usted tenga una bandera de advertencia en particular (por "código inalcanzable" ) establecido. Un compilador que apuntaba a "código inalcanzable" (es decir, un segmento de código que nunca se activó porque se encuentra debajo de una desviación de código que se aplica siempre) habría cogido.

Un ex empleado de Apple que trabajó en Mac OSX dijo a The Guardian que es "muy poco probable, al menos en circunstancias normales" que la falla se añadió maliciosamente. "Hay muy pocas personas en cualquier equipo dado a Apple, y así conseguir cambios perdidos en la confusión sería difícil. La otra cara es que no hay fuertes controles de consistencia / integridad internas sobre la base de código, así que si alguien era lo suficientemente inteligente como para subvertir los procesos normales no habría maneras fáciles pulg "

Pero, el programador agregó, "este cambio no destaca especialmente como maliciosos por naturaleza." La forma es casi seguro que pasó es que fue un error de copiar / pegar, o un problema de fusión (entre dos ramas de código) que pasó desapercibida - "dos cambios similares podrían causar un conflicto" (donde el código tiene un flujo lógico) "y en la resolución de este conflicto un ingeniero podría haber cometido un error."

¿Qué dicen los programadores?

Un ex empleado de Apple que trabajó en Mac OSX, incluyendo actualizaciones de envío y las actualizaciones de seguridad, dijo a The Guardian que Apple va a ser capaz de identificar quién hizo el check-in de código que crea el error. "Si bien la gestión de código fuente está sobre una base del equipo por equipo (no hay política en toda la compañía), casi todos los equipo utiliza algún sistema ( Git o SVN ) que sería capaz de seguir se compromete a [cambios en el código que están "comprometidos" para su uso] y asignar la culpa ".

La explicación más probable es que se produjo a través de la fusión de las dos ramas de código (cuando dos o más personas estaban trabajando en el segmento de código). Fusión de código es completamente común en la programación profesional, la conciliación de los conflictos entre las distintas ramas tiende a hacerse a mano, utilizando editores que se mostrarán "diffs" (diferencias) entre el viejo, nuevo y alternativo nuevo código.

Adam Langley, que trabaja en la seguridad para el navegador Chrome de Google (pero no ha trabajado para Apple), dice :

Esta especie de sutil error profundo en el código es una pesadilla. Creo que es sólo un error y me siento muy mal por quien podría haber resbalado en un editor y creado.

El hecho de que Apple está arreglando el agujero ahora sugiere que no es inspirada por la NSA. Aunque como John Gruber ha señalado , es perfectamente posible que la NSA descubrió este orificio para iOS 6 fue liberado y sabía que podía explotarla.

Un dato curioso: si la NSA era consciente de este agujero de seguridad, no parece que le dijo el Departamento de Defensa de EE.UU., que pasó iOS 6 para su uso en el gobierno 05 2013.

¿Cuándo Manzana encontrar el error?

A principios de enero. El 8 de enero se puso en contacto CVE, la base de datos de vulnerabilidades y errores (utilizado por los principales desarrolladores de software) para reservar el número de errores CVE 2014-1266 para la vulnerabilidad descubierta recientemente, aunque CVE no sabía lo que era la vulnerabilidad.

Apple parece entonces haber empezado a trabajar en la revisión y la manera de extenderla. Lo curioso es que a pesar de encontrar la vulnerabilidad a continuación, no se soluciona en dos versiones beta de iOS 7.1 que se publicaron después de ese tiempo. Una posibilidad - aunque la compañía no confirmará esto - es que se descubrió la falta de autenticación de certificado en enero, pero hubo que esperar hasta ahora para reducir la pieza defectuosa de código - aunque, dada la rapidez con que se llevó el resto de la web para hacer lo mismo (una cuestión de unas pocas horas), esto parece poco probable.

¿Por qué Apple no detectar el error antes?

Sus pruebas no lo encontraron. La compañía no dirá qué métodos utiliza - si las pruebas unitarias (en el que trozos de código individuales se prueban individualmente) o pruebas de regresión . donde el nuevo código se prueba con pruebas conocidas 
El ex programador no dice "Apple no tiene una fuerte cultura de la prueba o desarrollo basado en pruebas. De Apple se basa excesivamente en 'dogfooding' [por sus propios productos] para los procesos de calidad, lo que a la situación de seguridad no es apropiado. 
"Desde un punto de vista de la buena ingeniería de software, este tipo de problema se debería haber encontrado. Es una vergüenza que no se están ejecutando análisis de código estático en absoluto (y mucho menos de forma automática) en dichas bases de código importantes "El problema con el análisis estático de código es que puede generar falsos positivos -. advertencias sobre fallas que no son - lo que llevó a varios equipos rechazando la idea, aunque no está claro si el equipo de seguridad era uno de ellos.

¿Cómo encontrar el error de Apple?

Parece haber sido de una revisión línea por línea de código, casi con toda seguridad provocado por las revelaciones publicadas por el Guardián de los esfuerzos de la prisma de la NSA - y sus otros reclamos para tener SSL agrietada . En un momento se especuló con que la revisión del código fue instigada por Kristin Paget, quien fue hasta hace poco a cargo del núcleo de seguridad de OS X de Apple, que se unió en septiembre de 2012.

Pero Paget (quien acaba de comenzar a trabajar para Tesla) ha desatado un virulento ataque a Apple en su blog para liberar la solución para iOS, pero tampoco un parche en el escritorio al mismo tiempo:

LO QUE LA F ** K siempre amorosa, MANZANA???!!¿Sabía usted seriamente sólo tiene que utilizar una de sus plataformas para colocar un 0 días SSL en su otra plataforma? Mientras estoy aquí sentado en mi mac Soy vulnerable a esta y no hay nada que pueda hacer, porque no se podía lanzar un parche para ambas plataformas al mismo tiempo? Usted sabe que hay un montón de intentos de explotación de trabajo en vivo para este en el medio silvestre en estos momentos, ¿no?

Como ella señala, el propio sistema de actualización de seguridad de Apple utiliza SSL - por lo que podría ser hackeado por un "hombre en el medio" ataque a plantar software malicioso?

¿Qué hay de tu sistema de actualización en sí - es tan vulnerable?

Venga el infierno en la Apple. Usted acaba de caer un 0 días feos [vulnerabilidad de día cero] en nosotros y luego se fue a casa para el fin de semana - Ir fallan en verdad.

FIX. TU. LA MIERDA.

¿Por qué Apple no soluciona el bug para Mac OSX, al mismo tiempo que lo hizo para iOS?

Sin duda, debe tener, como Paget señala. Otro ex empleado de Apple está de acuerdo, al parecer, Apple ha decidido en lugar de desplegar el arreglo para Mavericks como parte de su actualización de software 10.9.2 y no como una actualización de seguridad por separado (que lo ha hecho antes). Pero otros insectos se encontraron en 10.9.2, retrasando su lanzamiento - y la reducción de la seguridad de los usuarios de Mac.

¿Se han producido errores como esto antes?

Los errores abundan en software - y los errores de codificación son sorprendentemente fáciles de hacer. En mayo de 2011, un investigador de seguridad señaló que las cuentas de usuarios de WhatsApp podrían ser secuestrados porque no estaban codificadas en absoluto, hasta septiembre de 2011, se produjo una falla en la misma aplicación que permiten a las personas enviar mensajes falsos que fingen ser de nadie.

Un error común es el uso de conexiones por defecto que se dejan activa: millones de routers de todo el mundo tienen ID de usuario y contraseñas por defecto (a menudo "admin" y "admin") que pueden ser explotadas por los hackers.

Un error de codificación similares bricked Zune de Microsoft en el último día de 2008 - que, como la suerte lo tendría, era un año bisiesto. Hubo unerror de codificación en el software para el chip temporizador que no permitiría que se muestre una fecha equivalente al día 366 del año.

Apple también ha hecho algunos errores flagrantes similares - principalmente en tener alarmas que no se adaptaron al horario de veranohizo, y así mantuvo despertar a la gente, ya sea una hora antes o después.

Google también tuvo un error en la versión 4.2.0 de su software Android : no se podría agregar los cumpleaños de las personas nacidas en diciembre a sus contactos, ya que ese mes no se incluyó.

Más en serio, las versiones de Android de Google hasta la versión 4.2 pueden ver las conexiones realizadas a través de Wi-Fi abierta secuestrados y código malicioso inyectado , laboratorios de MWR en el Reino Unido, dijo en septiembre de 2013. No está claro si eso todavía no se ha parcheado, millones de dispositivos Android siguen utilizando versiones 4.2 a continuación. Ars Technica, informando que falla, señaló que "si bien la debilidad en gran medida se puede prevenir en Android 4.2, los usuarios están protegidos sólo si los desarrolladores de cada aplicación siguen las mejores prácticas."

Y Microsoft tenía un defecto de larga ejecución en Windows 95 y Windows 98, que significa que si el equipo había estado funcionando continuamente durante poco menos de 50 días, sería repentinamente colgar - y usted tendría que reiniciar el sistema. ¿Por qué? Debido a que mide "tiempo de actividad" con un registro de 32 bits, lo que incrementa cada milisegundo. Después de 2 ^ 32 milisegundos (también conocido como 49 días y 17 horas), el registro fue de todos los 1 - y la única manera de restablecer se estaba convirtiendo la alimentación. Eso es muy aparte de las muchas fallas explotadas en su software de ActiveX para instalar programas maliciosos en equipos Windows en las llamadas "instalaciones drive-by".

¿Qué lecciones hay de esto?

En las palabras de Arie Van Deursen , profesor de ingeniería de software en Universidad Tecnológica de Delft en los Países Bajos,

Al ver por primera vez el código, que fue capturado una vez más, por lo increíblemente frágil es la programación. Sólo añadir una sola línea de código puede llevar un sistema al borde del desastre.

No sólo eso - pero el código defectuoso se ha utilizado tanto y publicado por 18 meses, y probado por una organización de seguridad del gobierno que fue aprobada para su uso. Los errores de software pueden ser perniciosa - y pueden estar al acecho en las áreas más esenciales. E incluso las empresas que han estado escribiendo software durante décadas pueden caer mal de ellos.

Pero el ex empleado de Apple dice que a menos que la compañía presenta mejores regímenes de pruebas - Análisis de código estático, pruebas unitarias, pruebas de regresión - "No estoy sorprendido por esto ... que sólo será cuestión de tiempo hasta que otra bomba como esta impacta. "La única - minimal - consuelo:" Dudo que sea malicioso ".

theguardian.com/technology

Telegram, alternativa de Whatsapp crece en España a un ritmo de 150.000 usuarios al día!

Telegram, alternativa de Whatsapp crece en España a un ritmo de 150.000 usuarios al día

Ayer martes, 4 de febrero, España se despertaba con Telegram en el puesto número uno de las aplicaciones gratis más descargadas en la App Store. La historia de Telegram y su muy reciente popularización son curiosas: un nuevo (pero no tan nuevo) startup encabezado por Pavel Durov, emprendedor mejor conocido por ser el fundador de VK, la red social más popular de Rusia.

Telegram apunta a competir contra WhatsApp atacando tres de sus puntos más débiles: mucha mayor seguridad, más y mejores herramientas para asegurar la privacidad de los usuarios y una plataforma open source con API (bien documentado) que permite la creación de clientes multiplataforma (inclusive no oficiales como ya sucede con la versión para OS X, Windows Phone o web.

Puede ser un golpe de suerte, puede ser que las ofertas de seguridad o de activar la auto-destrucción de mensajes, su flexibilidad o que es gratuito hayan sido motivos suficientes para calar en las preferencias de los usuarios pero estos días Telegram está creciendo y muy rápido.

En una conversación con Pavel Durov nos reveló datos sumamente interesantes. En España, el crecimiento de Telegram es vertiginoso: 150 mil usuarios nuevos cada día. En el caso de Latinoamérica, el ritmo también se está acelerando notablemente pero a menor medida: 20 mil usuarios nuevos al día, siendo México, Argentina, Colombia y Chile los países más importantes en número de usuarios de la región.
La eterna competencia a WhatsApp

Estos días parece ser que Telegram se perfila como la “aplicación alternativa a WhatsApp”, un puesto que hasta hace poco parecía ocuparlo LINE. En el mundo de la tecnología los gigantes tienen pies de barro y quien era un rey hoy será un desconocido mañana.

Siendo realistas, destronar a WhatsApp como la aplicación de mensajería en dispositivos móviles parece ser muy difícil, al menos durante los próximos 3 años. Sobre todo considerando que por sus redes circulan 50 mil millones de mensajes diarios y tienen más de 400 millones de usuarios activos.

Pero WhatsApp necesita que le compitan, necesita tener a alguien cerca que haga trabajar a la compañía y esforzarse en ofrecer un mejor producto, en hacer que su servicio sea más seguro, en dar alternativas para mantener la privacidad. Eso hoy no existe realmente (podemos decir que el único competidor real es el SMS). ¿Telegram se perfila como una de las alternativas? Sí. No es perfecto, tiene fallos y le hacen falta muchas mejoras. Es posible que en un año ya nadie lo recuerde, pero de mantener y aumentar esos ritmos de crecimiento podríamos estar frente a un verdadero candidato para ser esa competencia que tanto se necesitaba.

Alt1040

Razones por las que tu Mobil podría explotar si no lo manejas correctamente

Algunas razones por las que tu iPhone podría explotar si no lo manejas correctamente

Cualquier dispositivo portátil con batería de iones de litio es propenso a explotar en algunas circunstancias. Pero ¿cuáles son esas circunstancias y cómo podemos evitarlas?

Seguramente todo el mundo ha oído noticias sobre iPhones que han explotado. Algunos señalan que estos reportes son comunes porque la marca Apple es muy popular y hacen buenos titulares.

En medio de los reportes de varias unidades de iPhone 3GS que explotaron, Apple emitió un comunicado en agosto de 2009 (tras investigar algunos de estos casos).

“De momento, no hay ningún incidente confirmado de calentamiento de las baterías en los iPhones 3GS y el número de reportes que estamos investigando es de dígitos únicos”.

“Los iPhones con cristales rotos que hemos analizado hasta la fecha muestran en todos los casos el vidrio roto debido a una fuerza externa que les fue aplicada”.
Sin embargo, la realidad es (o ha sido, desde 2009) que algunos iPhones pueden explotar de repente, no sólo después de ser manejados incorrectamente. Por eso, uno puede culpar al diseño, al fabricante de la 

batería o a todo lo demás.

Siempre hay varios factores que pueden contribuir a la combustión espontánea de un iPhone, y Apple simplemente no puede hacer un seguimiento de todos estos casos cuando solicita la producción de millones de unidades.

Además, la gente normalmente no admite las condiciones extremas a las que sometieron sus teléfonos, y casi siempre suelen culpar al fabricante.

En cada batería de iones de litio hay algunas advertencias para no pinchar ni doblar la celda porque puede dejar de funcionar.

Así que, al poner tu iPhone en el bolsillo trasero del pantalón y al sentarte sobre él, es posible que el móvil acabe explotando en ese momento o en un momento posterior.

Tampoco hay que sobrecargar la batería, ya que puede llevar al sobrecalentamiento de la misma.

No utilices cargadores de imitación, y no te sorprendas si el móvil acaba explotando después de haberlo soltado en el inodoro y haberlo secado con un radiador.

Asimismo, no lo utilices en ambientes con temperaturas bajo cero, para luego llevarlo rápidamente a temperaturas tan altas como para conseguir bronceados. La condensación puede causar un cortocircuito en la batería.

Todos estos son simples consejos de sentido común. No hay nada demasiado especial. Evita todo esto y tu iPhone estará bien.

Descargo de responsabilidad
Este artículo sólo refleja la opinión personal del autor sobre cuestiones relacionadas con Apple y/o productos asociados con la marca Apple. Este artículo no debería considerarse como la postura oficial de Softpedia en asuntos relacionados con Apple.

news.softpedia.es

Usar cualquier terminal de telefonía mobil con algo de coherencia, leer las instrucciones de uso, controlar y limitar el uso a menores, hacer uso responsable de las nuevas tecnologías ahorra disgustos.

10 cosas que, por seguridad, nunca deberías hacer con tu smartphone

Iván Martín | 2 febrero 2014 15:20 | 6 comentarios

La seguridad es uno de esos problemas que más nos deberían preocupar, sobre todo cuando en los últimos tiempos ypor culpa de nuestros smartphones llevamos aplicaciones de todo tipo que, si alguien pudiera entrar en ellas, nos provocarían un agujero de cuidado. Ya sabéis, que si bancos, redes sociales, correo electrónico, fotos, eshop, etc.

Así que para que nos concienciemos todos de los peligros que entrañan algunas cosas que hacemos con el teléfono, osvamos a enumerar los 10 errores más comunes que llevamos a cabo en el uso de nuestro móvil y que son un riesgo más que evidente para la seguridad y su integridad. Por lo que esperamos que, tras leer estas líneas, todos pongamos nuestro granito de arena para evitar que ‘los malos’ nos roben nada. Por cierto, aquí no hay diferencias entre Android, Windows Phone o iOS ya que deberíamos estar alerta tanto si usamos el sistema operativo de Google como el de Microsoft o Apple.

Lo que os mostramos a continuación es el resultado de un estudio realizado por la firma aseguradora Protect Your Bubble en la que de primeras, afirma que diariamente se envían más de 156 millones de correos electrónicos que tienen que ver con actividades de ‘phising’. Así que ya sabéis, si queréis realizar un uso seguro de vuestro terminal, atentos a este Top 10 de cosas que NO deberíais hacer.

1– No proteger tu smartphone con contraseña. El 62% no lo hace y eso se traduce en un 33% más de probabilidades de sufrir un robo de identidad.

2– Tener aplicaciones que realicen logueos automáticos en nuestras cuentas, sobre todo si son aplicaciones bancarias o financieras. El 32% guardan sus contraseñas privadas en el móvil.

3– Hacer, mandar y guardar fotos con desnudos en nuestro móvil. El 20% de los adolescentes lo hacen y es se trata de una práctica muy peligrosa.

4– Hacer clic en enlaces fraudulentos de mails que recibimos y en los que no confiamos. El 4% de los fraudes se producen por esta vía.

5– Publicar fotos en redes sociales mientras estamos de vacaciones. Y es que el 75% de los que asaltan casas en fechas estivales, buscan a sus víctimas en redes sociales.

6– Publicar fotos con el tag de localización activado, por la misma razón que el punto anterior. Para evitar que sepan donde NO estamos.

7– Dar nuestros datos a personas que dicen pertenecer a servicios bancarios a través de llamadas telefónicas que recibimos. El 27% de los robos de identidad se producen por este método.

8– Usar nuestro smartphone sin una funda. El 25% no lo hacen y se acaban arrepientiendo a la menor caída que sufren.

9– Conectarse a redes Wifi inseguras o de las que no podamos saber si son de fiar. El 52% de los smartphones lo han hecho alguna vez.

10– No tener un móvil sin asegurar, al menos para que en caso de caídas podamos tener una manera de arreglarlo sin coste alguno.

Fuenter: Protect you Bubble

...

Una joven china muere electrocutada mientras hablaba por su iPhone

Un Samsung Galaxy 4 explota e incendia un apartamento