Un sistema informático moderno es una pesadilla desde el punto de vista de dónde están realmente nuestros datos (cachés, swaps, páginas, memorias, discos …). Por eso conviene recordarlo: de cara a que nuestros datos sensibles estén el menor tiempo posible por ahí en claro; y también por tratar de evitar mediante las facilidades que tengamos disponibles que esos datos terminen escritos donde no conventa. De eso hablaban en
En Encryption and the loss of patient data (si alguien no tiene acceso y tiene interés, seguro que conoce a alguien que se lo puede proporcionar ;) ) hablan del tema del cifrado de los datos de los pacientes:
This paper presents some of the first empirical evidence about the extent to which firms’ adoption of encryption software limits how likely firms are to experience publicized instances of customer data loss.
Curiosamente, el cifrar los datos no parece favorecer su conservación ni su pérdida:
Surprisingly, we find empirical evidence that the use of encryption software does not reduce overall instances of publicized data loss. Instead, its installation is associated with an increase in the likelihood of publicized data loss due to fraud or loss of computer equipment. Speculatively, this may occur because firms are less careful at controlling access internally to encrypted data and employees are less careful with computer equipment when they believe that data are encrypted.
Por lo tanto, habría que tener cuidado también con los empleados:
Our research suggests that policymakers should expand the breadth of security measures to encompass other technologies such as user-access controls that are better able to address the insider threat.
Y tener en cuenta que la digitalización puede incrementar los problemas, sobre todo si no se tiene el cuidado necesario:
The empirical findings of this paper also suggest that digitization of patient records may increase the likelihood of data breaches.
No estamos hablando de los casos en los que las aplicaciones envían datos de tu agenda, actividad con el teléfono, etc. sino de otro tipo de espionaje: Según iPhone Accelerometer Could Spy on Computer Keystrokes el acelerómetro de nuestro teléfono (iPhone o cualquier otro, no creo que haya gran diferencia en ese aspecto), tranquilamente reposando sobre nuestra mesa podría estar ‘sintiend0 nuestros tecleos en el ordenador (no en el teléfono, sino en el teclado que no tiene nada que ver con el aparatito) y captar con una probabilidad alta (teniendo en cuenta las vibraciones, frecuencias, la forma del teclado, etc.) lo que hemos ido tecleando.
Me parece bastante curioso y me ha recordado la historia aquella del espionaje a través del reflejo de la pantalla en la pared: Spying on Computer Monitors Off Reflective Objects.
También otros modos en los que nuestro teléfono tiene información sobre nosotros y nuestro entorno, claro: Lo que tu teléfono sabe de ti… Y para qué podría servirte, Lo que tu teléfono sabe de ti (II) o, por ejemplo, Sensores con nosotros: ¿nos harán la vida algo mejor?.
Internet está lleno de datos esperando a que los busquemos y les demos sentido (también los malos, claro). En Companies Using Secure Protocols in an Insecure Manner podemos leer sobre un sondeo basado en preguntar directamente a los servidores (en lugar de a los responsables de la empresa).
First step, I found companies listed in this year’s Fortune 500. This was pretty straightforward; I entered something like “Fortune 500” in Google and found they are listed on: http://money.cnn.com/magazines/fortune/global500/2011/full_list/index.html.
Then I had to find these companies primary website, and that wasn’t too hard either. At the url mentioned above, you just click a company’s name in the index and the company’s website is mentioned on the next page. This way I discovered the 500 websites for all companies listed in this years Fortune 500.
Next thing was to find which of those sites could be visited using the https-protocol. Again, no rocket science here. 259 hosts were listening on port 443 /tcp, the default port for https. It turned out that 3 of them did not talk https on that port, or at least not to me… Another 20 servers did not provide me their (public) SSL certificate details (most of them would probably have provided the details if I had been more persistent, but I wasn’t).
From the remaining 236 systems, these are the (anonymized) facts:
109 systems were willing to exchange data using SSL version 2
149 systems were willing to use encryption keys of 56 bits or less
160 systems were willing to use either SSLv2 or short encryption keys
7 systems were willing to use 0 bit encryption keys (meaning no encryption)
129 certificates had public keys of 1024 bits or less (one as short as 512 bits)
12 certificates were expired (one as old as May 2008)
9 certificates will expire after more than 3 years (one as late as in August 2023)
Como dice el autor, seguramente los datos no son tan precisos como deberían. Pero pintan un buen (mal) panorama que, además, cualquier intersado puede encontrar por su cuenta.
En The science of password selection un (otro) informe sobre las claves que se obtienen de diversas maneras de usuarios reales en la red.
De mis notas.
¿Cómo eligen las claves los usuarios?
En este caso los datos vienen de varias fuentes:
The data I’m going to analyse comes from a variety of sources including the Sony and Gawker breaches I referenced in the previous post as well as other LulzSec releases including pron.com and a collection of their random logins.
Se usan nombres (un 14% de claves, derivadas de nombres):
I also suspect they feature heavily when someone reaches into the recesses of their mind to come up with a password. Now of course the name is not necessarily the name of the account holder; it could be a spouse, the kids or even the family dog. Furthermore, it could be a first name, a middle name or a last name.
Un 25% son palabras del diccionario (incluyendo la palabra ‘password’)
A huge 25% of passwords are derived directly from dictionary words. In
reality, it’s probably somewhat higher than this as my dictionary had less
than a couple of hundred thousand words. And they’re all only English
language.Top among the dictionary favourites are:
password (oh dear)
monkey
dragon
Las claves numéricas tienen en su mayoría (83%) cuatro, seis u ocho dígitos, pero hay un buen número de longitud uno, por ejemplo.
Why is this interesting? Well firstly, within a spread of numeric password lengths which range from 1 (yes, 1, and there’s a heap of ‘em) to 21, 83% of the passwords are either four, six or eight digits long. Is this a propensity for even numbered password lengths or something else?
Los de cuatro podrían corresponder al PIN del cajero automático.
Los de seis serían fechas donde el año tiene dos cifras.
Los de ocho serían fechas con el año completo.
Las claves con dos palabras repetidas (blabla) serían menos del 3%, pero es un patrón que utiliza la gente.
También hay quien utiliza frases cortas del estilo de: ‘dejameentrar’ o similares.
Naturalmente, he hecho una selección según mis gustos y sesgos, pero vale la pena leerlo todo para hacerse una idea.
En Error-Based SQL Injection in Oracle 11g una entrada bastante técnicas sobre el tema de inyección SQl en el conocido gestor de bases de datos. Me pareció intersante por el detallado proceso de ir buscando fallos, indicios de que algo puede ir mal y, finalmente, la forma de atacar a la base de datos en ese caso concreto, saltándose la comprobación en la autentificación.
En seguridad siempre hay que ponerse en lo peor (aunque sea difícil). Sobre todo, si es fácil evitar los problemas que podrían ocurrir. Algo que solemos comentar es que cuando se lea una clave se haga lo que sea con ella y la eliminemos de la memoria lo antes posible (para evitar problemas con escrituras a disco por diversos motivos: el ‘swapping’ del sistema operativo, volcados de memoria ante fallos, …
Son ese tipo de cosas que suenan más teóricas que realistas pero en el ‘mundo real’ ™ Passwords left in memory using SSH keyboard-interactive auth podemos ver como realmente alguien las toma en serio. En este caso, los desarrolladores de Putty.
En muchas empresas ya es bastante habitual disponer de políticas de seguridad sobre los datos (se cumplan o no) pero en las universidades parece que no lo es tanto. Supongo que tiene que ver con la naturaleza de su trabajo (avanzar el conocimiento, experimentar, …). En Cornell se han preocupado por el tema y han creado la University Data Cleanup and Inventory Initiative:
Overview
The University Data Cleanup and Inventory is a campus-wide initiative, undertaken at the behest of President Skorton, that requires units to:
- Establish business practices for handling confidential data.
- Discover where confidential data is being stored electronically.
- Remove confidential data that is no longer needed.
- Secure any confidential data that must be retained.
- Maintain awareness of where confidential data continues to be held.
Y pistas como: Sources of Confidential Data.
Interesante.
En [PDF] “These Aren’t the Droids You’re Looking For”: Retroffiting Android to Protect Data from Imperious Applications un estudio bastante interesante sobre aplicaciones Android para los teléfonos y su ‘hambre’ de datos.
First, we provide the deepest study to date (to our knowledge) of information exposure by Android applications in terms of types of information investigated, forms of exposure including encryption, and exposure patterns to advertisign and analytics servers
De las 110 aplicaciones estudiadas, 31 envían el IMEI del dispositivo. De ellas 14 lo envían a servidores de analítica y publicitarios.
Como resultado de la investigación, también ofrecen AppFence: Protecting User Data from Android Applications, una aplicación que sustituye datos sensibles por otros para que las aplicaciones los envíen y, además, bloquea transmisiones de red que contienen datos del usuario que han sido marcados como de uso exclusivo por el usuario en el dispositivo.
No la he probado.
Por la posibilidad de hacerlos y porque, al final, llevan un trabajo no desdeñable me gustan mucho este tipo de estudios. Por algún motivo lo había dejado aparcado y lo traigo ahora aquí: Study of HTTPOnly and Secure Cookie Flags for the Top 1000 Websites.
Como el título sugiere, se eligen los 1000 sitios más importantes (según alexa, en este caso) y se observa el resultado de alguna característica de seguridad. En este caso los flags HttpOnly y Secure cookie: se trata de hacerse una idea del uso que dan estos sitios a esas características de seguridad.
Unique Domains Responding: 162
Domains responding to https://www.: 141
Domains responding to https://: 88Total Cookies Gathered: 559
Cookies from https://www.: 373
Cookies from https://: 186HTTPOnly Flag
Total unique count of cookies using secure flag: 26
Cookies from https://www.: 25
Cookies from https://:11
Note: 10 of the 11 sites from https:// were duplicated within the
https://www. resultsSECURE Flag
Total unique count of cookies using secure flag: 15
Cookies from https://www.: 15
Cookies from https://: 0Session Cookies
Cookies containing the word “session”: 91
Total unique count of these cookies marked HTTPOnly: 12
Total unique count of these cookies marked SECURE: 8
Total unique count of these cookies marked SECURE & HTTPOnly: 1
(https://www.clickbank.com)HTTPOnly & SECURE
Total number of cookies marked HTTPOnly & SECURE : 7
6 from https://www.paypal.com
1 from https://www.clickbank.comRaw data can be found at the following link.
La metodología tiene sus debilidades: puede ser que se utilicen estas cosas, pero no en la página que se mira, o algún error temporal, pero da una idea …
Ya hemos comentado otras veces estudios ‘numerológicos’ similares, por ejemplo en Claves y usabilidad o en Contraseñas, usabilidad y uso.
