La inseguridad de Android

Buenas tardes:
Si bien el otro día hablaba de la poca seguridad física que ofrece WhatsApp, hoy le toca a Android en general. Recordemos que habíamos comentado cuando hablábamos del WhatsApp, que en Android las aplicaciones usaban SQLite como motor de almacenamiento de ajustes y datos, y que esto provocaba que pudiésemos recuperar de ellas, datos que en principio no deberían constar, por haber sido borrados.
La siguiente pregunta es, pro tanto, es esto un problema exclusivo de esta aplicación o lo es también de cualquier otra aplicación?. La respuesta es que de TODAS (o al menos la inmensa mayoría).
La raíz del problema viene indicada (entre líneas) en la FAQ de SQLite:

When you delete information from an SQLite database, the unused disk space is added to an internal "free-list" and is reused the next time you insert data. The disk space is not lost. But neither is it returned to the operating system.

Cuando borras información de una base de datos SQLite, el espacio en disco libre se añade a una lista libre interna, de donde toma el espacio que necesita la próxima vez que añades información. El espacio en disco no se pierde, pero tampoco se devuelve al sistema operativo.

De aqui que de igual modo que podemos acceder a mensajes borrados del WhatApp, lo podemos hacer a sms o mms borrados, llamadas eliminadas del historial, o incluso, a contraseñas de acceso a determinados servicio, como por ejemplo Twitter o Facebook, que las mantienen en esta base de datos, cifrados en md5.

¿Como solucionar esto? Debemos tener en cuenta que son dos los problemas que hemos mencionado: la posibilidad de recuperar datos que ya no debían figurar, y y la posibilidad de acceder a datos sensibles como contraseñas.

Para el primer caso, a priori la manera sería muy sencilla, y consistiría en hacer una llamada al comando VACUUM, que básicamente reconstruye la base de datos con la información actual, reduciendo su tamaño y haciendo así más complicada la recuperación de estos datos que no deberían figurar.

Para el segundo, lo más correcto, sería habilitar la compresión, que en el caso de SQLite se puede hacer con AES de hasta 256 bits a través de la Extensión de Encriptado de SQLite.

Esperemos que los desarrolladores de aplicaciones para Android empiecen a tener estos pequeños detalles en cuenta a la hora de desarrollar sus aplicaciones, sobre todo aprovechando que la mayor parte de ellos están rediseñando las mismas para adaptarlas al framework de Android Ice Cream Sandwich

Deja un comentario