En navigator.hardwareConcurrency explican una forma de estimar el número de cores del procesador del ordenador del usuario desde el navegador, a la hora de enviarle trabajos de cálculo, si es que tenemos interés en hacerlo.
Curioso.
Casi a título de inventario y para que no se me pierda, una referencia a un estudio sobre este conocido ERP, [PDF] SAP Security in figures – a global survey 2007-2011.
Como resumen, a partir de 2009 parece que empieza a despegar el interés de los investigadores por esta plataforma y tiene sus fallos, como no podía ser de otra forma.
Aunque no tengo muy claro que ha pasado con él me pareció interesante el borrador: [PDF] Draft. Anonymisation code of practice. Sobre todo porque es algo en lo que no siempre se piensa y puede tener sus consecuencias negativas. Más ahora en la que las políticas de datos abiertos podrían tener en algunos casos consecuencias inesperadas.
This code describes ways of assessing and mitigating the risks that may arise, particularly in terms of assessing whether other information is available that is likely to facilitate re-identification.
Los motivos son claros:
As explained above, it can be difficult to assess the risk of reidentification by a member of the public because different members of the public – and indeed different organisations – have access to different information resources, potentially much richer ones, than the general public.
Eso es, no sabemos quién hay ‘ahí afuera’ mirando los datos.
El tamaño importa:
It is clear, though, that the more complete a postcode – or the more precise a piece of geographical information – the more possible it becomes to analyse it or combine it with other information, resulting in personal data being disclosed. The approach you should take to postcodes and other spatial information will also be guided by the size of the dataset you have; in some cases you can consider the position on a postcode by postcode basis.
…
. The larger the number of properties or occupants in a mapping area, the lower the privacy risk.
Cuidado con la información estadística:
The situation becomes more complex where statistical information is involved, because there may be various statistical data sets publicly available which, if matched in a particular way, could result in reidentification. Pen-testing for this type of vulnerability can require a great deal of specialist knowledge and cannot be described fully in this code of practice.
Se presentan algunos ejemplos prácticos de técnicas de anonimización, que
incluyen el borrado de variables (columnas de datos), filas (registros
fáciles de identificar), recodificación de los datos (por ejemplo, pasar de
valores concretos a rangos), eliminación de datos concretos (para registros
que podrían identificarse de manera única, eliminar algún dato
conflictivo), microagregación (sustituir datos de algunas columnas por la
media -sería parecido a los rangos, pero fijando un valor-), intercambio de
datos (por ejemplo entre dos registros, la edad, u otro valor),
aleatorización (para algún campo concreto), añadir ruido (cambiar los
valores por otros parecidos pero que no permitan asociarlos a nadie
concreto porque no son exactos); yendo más allá, se puede estudiar la
distribución y generar valores que la sigan sustituyéndolos luego en el
conjunto de datos.
Es un problema conocido desde hace tiempo, en Computer Security and Statistical Databases podemos ver una descripción más ligera del problema.
Pero siempre viene bien recordarlo.
La versión moderna sería la desanonimización de datos en la red a través de análisis de redes sociales y otras cuestiones relacionadas, hemos hablado de vez en cuando de ello: Sobre la desanonimización de la gente en internet.
Lo guardaremos.
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.
Mbpfernand0's Blog 