Yo creía que a estas santas alturas de la evolución de los lenguajes de programación todo estaba ya más que trillado. La teoría de compiladores que estudiábamos en la Universidad permitía que un autómata programable pasara de un estado a otro al encontrarse con la siguiente entrada. Todo parecía indicar que el autómata tiene que estar siempre en algún estado, aunque dicho estado sea el "estado de error", que puede ser causado por un fallo en la sintaxis o en los valores autorizados de una entrada.
Hoy he descubierto que esto no es cierto para el lenguaje ActionScript 3 (AS3)
En este lenguaje, como en muchos otros, una variable puede tener un valor conocido, o bien un valor null que indica que el valor es desconocido.
Esperaba que un valor null se evaluara a falso en una asignación a una variable booleana.
Esperaba que un valor null se evaluara a falso en una expresión condicional.
Esperaba que un valor null, evaluado a falso, se pudiera comparar con otro valor constante o con otra variable, dando como resultado una falsedad.
...
Esperaba en vano, quizá confiado en los resultados de otros lenguajes como el C.
Y debo admitir que AS3 tiene razón: NO ES EVALUABLE A VERDADERO O FALSO UN VALOR NULO, NO ES ASIGNABLE UN VALOR NULO A UNA VARIABLE LOGICA, NI SE PUEDE CONOCER EL RESULTADO LOGICO DE UNA COMPARACION CON UN VALOR NULO.
Pero, por favor, LOS PROGRAMADORES NECESITAMOS QUE NULL Y SUS COMBINACIONES EN EXPRESIONES LÓGICAS SE EVALUEN A "ALGO", A LO QUE SEA, A NULL, POR EJEMPLO.
Me parece increíble que, al día de hoy, el Flash Player 11 (la última versión) y el plugin para todos* los navegadores se quede parado, sin emitir ningún mensaje de error, cuando se necesita evaluar una comparación con un valor null. No puedo creer que cosas como ésta sucedan hoy en día.
Enfin, paciencia. Ahora que ya lo sé, o mejor dicho, ahora que ya lo sabemos, podremos escribir mejores códigos.
* (he probado con las últimas versiones de Internet Explorer, Firefox y Google Chrome, y algunas otras versiones anteriores de éstos)
sábado, 2 de junio de 2012
jueves, 19 de enero de 2012
GENERADOR DE CONTRASEÑAS SEGURAS
Por supuesto que 2000, José Antonio, Almería, Madrid, tu nombre o el nombre de tu pueblo, o una palabra que exista en el diccionario, o una palabra corta que contenga solo letras minusculas son ejemplos de contraseñas inseguras. Eso ya lo sabemos. También sabemos que es inseguro usar la misma contraseña para todos los sitios. ¿De qué servirá que Google, Facebook o algun otro de los "grandes" tengan complejos sistemas para gestionar tus contraseñas, si luego usas la misma para otro sitio web que no dedica tanto esmero en mantenerlas a salvo? Como una cadena es tan fuerte como el más débil de sus eslabones, cualquier ataque que consiguiera romper la seguridad de ese sitio web débil conseguiría dar acceso al atacante a los otros sitios más fuertes.
Pero es que en los momentos actuales tenemos que recordar tantas contraseñas que nos tienta a usar siempre la misma, o a usar la misma con leves diferencias, como JOSEANTONIOFACEBOOK, JOSEANTONIOGMAIL, JOSEANTONIOCAJAMAR, ... Al final hay tantas que se torna difícil recordarlas todas.
Usar un programa para recordarlas... va a ser que no. Es como tener una caja fuerte para guardar todas las llaves. Pasaría a ser el primer lugar que intentarían atacarnos. Máxime si resulta que el programa es de fuente abierta. ¡Encima con pistas sobre cómo está hecha la caja fuerte!. (-Es que el código fuente lo que implementa es Rijndael, que incluye dentro de sus características el ser un método de cifrado de fuente pública ¿Qué más dá que dejemos ver el código? -Pues que los códigos fuente son pistas innecesarias como las que daba el entorno de desarrollo de fuente abierta de Flex para facilitar los ataques XSS del pasado mes de diciembre. A pesar de ello sigo recomendando el software libre y el Flashdevelop como entorno de desarrollo AS3 para Flash. El agujero de seguridad ya ha sido corregido en la versión actual.)
Para mí siempre será más práctico usar las iniciales de una frase que tenga que ver con el sitio web. Por ejemplo, FaceBook es importante para mi porque me permite leer lo que publica mi hermano que está en Barcelona. La contraseña podría ser MPLLQPMHQEEB, que son las iniciales de las palabras "Me Permite Leer Lo Que Publica Mi Hermano Que Está En Barcelona". Lo podemos combinar con un par de números, por ej. el ordinal de la ultima letra de la contraseña (2 para la B de Barcelona) y el ordinal de la primera letra del sitio web, (6 para la F de Facebook). Quedaría PLLQPMHQEEB26. Le ponemos un simbolo gráfico por medio, por ejemplo un dólar $, un guión - o un porciento %, y quedaría MPLLQPMHQEEB$-%26. Esto daría la friolera de 13 trillones de años para encontrar la clave usando la capacidad de cómputo de un ordenador personal, según dicen en http://howsecureismypassword.net/ .
Incluso la simple clave MPLLQPMHQEEB llevaría 12 años para encontrarla, y con solo añadirle un guión al final, MPLLQPMHQEEB-, llevaría 117 mil años.
Es importante la longitud porque JOSE- llevaría 0.46 segundos, pero JOSEANTONIO- llevaría 2000 años.
Es obvio que ésto son solo ejemplos, válidos claro está, siempre que sea fácil recordar la frase de la que se obtienen las iniciales. Espero vuestros comentarios.
Pero es que en los momentos actuales tenemos que recordar tantas contraseñas que nos tienta a usar siempre la misma, o a usar la misma con leves diferencias, como JOSEANTONIOFACEBOOK, JOSEANTONIOGMAIL, JOSEANTONIOCAJAMAR, ... Al final hay tantas que se torna difícil recordarlas todas.
Usar un programa para recordarlas... va a ser que no. Es como tener una caja fuerte para guardar todas las llaves. Pasaría a ser el primer lugar que intentarían atacarnos. Máxime si resulta que el programa es de fuente abierta. ¡Encima con pistas sobre cómo está hecha la caja fuerte!. (-Es que el código fuente lo que implementa es Rijndael, que incluye dentro de sus características el ser un método de cifrado de fuente pública ¿Qué más dá que dejemos ver el código? -Pues que los códigos fuente son pistas innecesarias como las que daba el entorno de desarrollo de fuente abierta de Flex para facilitar los ataques XSS del pasado mes de diciembre. A pesar de ello sigo recomendando el software libre y el Flashdevelop como entorno de desarrollo AS3 para Flash. El agujero de seguridad ya ha sido corregido en la versión actual.)
Para mí siempre será más práctico usar las iniciales de una frase que tenga que ver con el sitio web. Por ejemplo, FaceBook es importante para mi porque me permite leer lo que publica mi hermano que está en Barcelona. La contraseña podría ser MPLLQPMHQEEB, que son las iniciales de las palabras "Me Permite Leer Lo Que Publica Mi Hermano Que Está En Barcelona". Lo podemos combinar con un par de números, por ej. el ordinal de la ultima letra de la contraseña (2 para la B de Barcelona) y el ordinal de la primera letra del sitio web, (6 para la F de Facebook). Quedaría PLLQPMHQEEB26. Le ponemos un simbolo gráfico por medio, por ejemplo un dólar $, un guión - o un porciento %, y quedaría MPLLQPMHQEEB$-%26. Esto daría la friolera de 13 trillones de años para encontrar la clave usando la capacidad de cómputo de un ordenador personal, según dicen en http://howsecureismypassword.net/ .
Incluso la simple clave MPLLQPMHQEEB llevaría 12 años para encontrarla, y con solo añadirle un guión al final, MPLLQPMHQEEB-, llevaría 117 mil años.
Es importante la longitud porque JOSE- llevaría 0.46 segundos, pero JOSEANTONIO- llevaría 2000 años.
Es obvio que ésto son solo ejemplos, válidos claro está, siempre que sea fácil recordar la frase de la que se obtienen las iniciales. Espero vuestros comentarios.
miércoles, 4 de enero de 2012
ROOTKITS Y LA LUCHA DEL BIEN CONTRA EL MAL
Un rootkit es un programa que está oculto o enmascarado en el sistema, y puede acceder a partes de éste de un modo privilegiado de modo que es difícil de detectar y más difícil aún de eliminar mientras está en ejecución.
Hasta este momento nada he dicho sobre su naturaleza o sobre su comportamiento. Este recurso puede ser empleado para bien y para mal, como las armas, internet, los libros, las palabras y tantas otras facetas cotidianas.
Por ejemplo, lo ideal es que un programa antivirus permanente funcione como un rootkit benigno:
Para conseguir estar activo y en ejecución, un rootkit debe formar parte del sistema operativo como si se tratara de un servicio o módulo en ejecución del núcleo del sistema. Y claro, ésto solo se consigue arrancándose y poniéndose en ejecución con el propio sistema, es decir, arrancando con el nucleo del sistema. El núcleo es la primera parte que se carga en memoria cuando una partición formateada y activa toma el control del arranque de la máquina. Lo primero que se carga son los drivers o controladores de dispositivos, en particular el driver del disco duro. Si enmedio de alguno de esos códigos estuviera un trozo de código rootkit (infectado e insertado por algún medio vírico, troyano, gusano, etc...) este código permanecería activo y en ejecución todo el tiempo que la máquina estuviera encendida. Porque el driver del disco duro siempre está usándose. Si mientras que está activo se le intentara detectar o eliminar mediante otro programa, pongamos un antivirus, este propio antivirus tendría que usar el driver del disco duro para borrar el rootkit, pero el código del rootkit está enmedio del código del driver del disco duro, así que podría enmascararse para ser detectado, o aparentar su borrado. En efecto, el antivirus trata de ver el mundo con unas gafas pero las gafas le dejan ver todo menos lo importante: las propias gafas.
Hasta este momento nada he dicho sobre su naturaleza o sobre su comportamiento. Este recurso puede ser empleado para bien y para mal, como las armas, internet, los libros, las palabras y tantas otras facetas cotidianas.
Por ejemplo, lo ideal es que un programa antivirus permanente funcione como un rootkit benigno:
En general, no obstante, se asocia un rootkit con un comportamiento maligno.
- oculto, que no se pueda detectar, o sea, que los programas virus no puedan detectarlo
- enmascarado en el sistema, o sea, que el sistema siga funcionando y que el antivirus aparentemente sea como cualquier otro programa residente y activo del sistema
- que pueda acceder a partes del sistema de modo privilegiado, es decir, que se ejecute con más privilegios que cualquier programa virus, para que pueda imponerse a éstos, pararlos, borrarlos de memoria, borrarlos de disco duro, sin tener que pedir constantemente permisos para hacer estas tareas privilegiadas.
- que sea muy difícil de eliminar, para que los programas virus no puedan borrarlo de disco duro, parar su ejecución o borrarlo de la memoria.
Para conseguir estar activo y en ejecución, un rootkit debe formar parte del sistema operativo como si se tratara de un servicio o módulo en ejecución del núcleo del sistema. Y claro, ésto solo se consigue arrancándose y poniéndose en ejecución con el propio sistema, es decir, arrancando con el nucleo del sistema. El núcleo es la primera parte que se carga en memoria cuando una partición formateada y activa toma el control del arranque de la máquina. Lo primero que se carga son los drivers o controladores de dispositivos, en particular el driver del disco duro. Si enmedio de alguno de esos códigos estuviera un trozo de código rootkit (infectado e insertado por algún medio vírico, troyano, gusano, etc...) este código permanecería activo y en ejecución todo el tiempo que la máquina estuviera encendida. Porque el driver del disco duro siempre está usándose. Si mientras que está activo se le intentara detectar o eliminar mediante otro programa, pongamos un antivirus, este propio antivirus tendría que usar el driver del disco duro para borrar el rootkit, pero el código del rootkit está enmedio del código del driver del disco duro, así que podría enmascararse para ser detectado, o aparentar su borrado. En efecto, el antivirus trata de ver el mundo con unas gafas pero las gafas le dejan ver todo menos lo importante: las propias gafas.
Suscribirse a:
Entradas (Atom)