Cita

"Those who are willing to pay a penny of security for a penny of usability will eventually have neither"

28 marzo 2015

Control de accesos


Con el control de acceso, dada una petición de recursos, se permite o deniega el acceso según ciertas políticas. Incluye mecanismos de autenticación, autorización y auditoría. Las políticas de acceso son un conjunto de reglas que determinan las acciones que un sujeto puede hacer sobre un objeto (lectura, escritura, modificación, borrado, ejecución).

Los tipos de control de acceso son: control de acceso obligatorio, control de acceso discrecional, control de acceso basado en roles y control de acceso basado en atributos.

En el control de acceso obligatorio o Mandatory Access Control (MAC) las políticas son evaluadas de forma centraliza (por ejemplo, en el núcleo del sistema) y el acceso a un determinado objeto dependerá de la sensibilidad de la información contenida en él y de la autorización formal que tenga el sujeto para acceder a ese nivel de sensibilidad.

El control de acceso discrecional o Discretionary Access Control (DAO) consiste en un conjunto de reglas de acceso que son definidas por los propietarios de los objetos. Entonces, las políticas lo que regulan son los procesos de gestión de privilegios entre los sujetos. Los privilegios se pueden representar mediante tablas de autorización, listas de control de acceso (ACL) o listas de capacidades.

Con el control de acceso basado en roles o Role-Based Access Control (RBAC) la gestión se simplifica, ya que, una vez asignados los permisos a roles, después solo habrá que asignar correctamente los roles a los distintos usuarios que se vayan incorporando al sistema. Aunque es el más utilizado actualmente, tiene algunas limitaciones que son solventadas por el control de acceso basado en atributos. Por lo que lo más probable es que este último se acabe imponiendo.

La ventaja del control de acceso basado en atributos o Attribute Based Access Control (ABAC) con respecto a los anteriores es que, además del rol, toma en cuenta otros atributos más dinámicos, como pueden ser: la relación de los usuarios con las distintas fuentes de información, el momento del acceso (fecha/hora), o la IP de origen. La políticas de acceso se definen estableciendo relaciones entre varios atributos. Este modelo refleja mejor la realidad, que puede ser cambiante.

Relacionado con ABAC está XACML, un estandar basado en XML que describe un access control framework y que proporciona un lenguaje para definir las políticas de acceso, el diálogo mantenido durante el control de acceso y la arquitectura formada por los diversos componentes que lo forman.

Más información:


Picadillo y sal para la seguridad de tus contraseñas


 


Hoy voy a explicar algunas maneras de proteger las contraseñas almacenadas y los métodos de ataque más frecuentes.
 
Un sistema que use «shadow passwords» (típicamente, Linux) no almacena la contraseña en el /etc/passwd, sino que guarda un hash de la misma en el /etc/shadow. En el primer fichero se almacerán datos como el nombre de usuario, su grupo, etc. Y tendrán acceso en modo lectura todos los usuarios. Mientras que al segundo podrán acceder solo los usuarios con más privilegios.

El hash, o resumen, es el resultado de aplicar a la contraseña una función unidireccional (MD5, blowfish, SHA256 i SHA512); de manera que a partir de la contraseña se puede calcular el resumen, para comprobar que la contraseña de acceso al sistema introducida es la correcta; però la inversa no es posible; por lo que aunque un atacante se hiciera con el /etc/shadow no podría (en teoría) obtener a partir de él las contraseñas. 

Pero el caso es que estas funciones, aunque unidireccionales, son deterministas: la misma entrada da siempre la misma salida; por lo que se podría hacer un ataque utilizando una lookup table: una tabla con hashes precalculados a partir de palabras de diccionario. El atacante que consiga acceso al shadow solo tendría que buscar en la lookup table a qué contraseña corresponde cada hash. La ventaja que tiene esta técnica es que las búsquedas son rápidas porque los cálculos ya están hechos. Pero la tabla ocupa mucho espacio en disco. 

Para solucionar los problemas de almacenamiento, se usan las rainbow tables. En ellas se guarda un conjunto reducido de palabras y, para cada una se calcula la palabra final que le corresponde, según el siguiente método:

Se calcula el hash de la palabra. Aplicando a dicho hash una función de reducción, se obtiene otra palabra distinta, de la que a su vez se calcula el hash. Y así hasta unas 40.000 veces, hasta que se obtine l'última palabra. El par primera palabra, última palabra, forma una fila de la tabla (los valores intermedios no se almacenan). Para cada una de las palabras escogidas, se hará lo mismo.

Ahora, una vez que se ha construido la tabla siguiendo el método anterior, podemos intentar calcular la contraseña correspondiente a un hash dado, de la siguiente manera:

Al hash se le aplica la función de reducción, si la palabra obtenida corresponde con alguno de los elementos finales de la tabla, ya hemos terminado. Si no, calcularemos el hash de dicha palabra, para aplicarle la función de reducción. El cálculo para cuando encontremos la palabra que coincida con el elemento final de alguna fila (no siempre se encuentra). En ese punto sabremos que, repidiendo el proceso tomando como partida la palabra incial de la final, obtendremos en algún momento nuestro hash. La palabra a partir de la la cual lo hayamos encontrado será la contraseña buscada.

Es importante recordar que la función de reducción NO es la inversa de la función hash (que ya decíamos que es unidireccional), pero una misma función de reducción, a partir del mismo hash, siempre produce la misma palabra. Para entenderlo mejor, podéis ver un ejemplo en la Wikipedia.

Fuente: Wikipedia


Como a cada contraseña le corresponde siempre el mismo hash, si dos usuarios tienen la misma contraseña tendrán también el mismo hash. Para complicar la cosa y hacer menos efectivas las tables, lo que se suele hacer es "saltear" las contraseñas: añadirles un salt aleatorio, distinto para cada una, antes de calcular el hash. Para que el método sea efectivo, hay que poner cuidado en no usar dos veces el mismo salt y que éstos sean lo suficientemente largos.

En resumen: las contraseñas no deben guardarse nunca en texto plano, sino "salteadas" y "hasheadas". La pregunta es si todos los sitios en los que nos registramos lo harán así.


09 marzo 2015

Mi experiencia en la #Rooted2015

HTTP 303 See other

Location: www.securitybydefault.com

Tranquilos, no le pasa nada al blog. Ese 303 lo he puesto yo para indicaros, de una manera original, que este año, la crónica podéis leerla en otro blog.

Los chicos de "Security by Default" me han pedido que escribiera en su blog la crónica de la Rooted2015. Así que, aunque podría repetirlo aquí (ellos solo quieren la primicia), mejor os redirijo a su blog para que lo leáis allí.

Espero que os guste. Y a SbD, reiterarles mi agradecimiento por darme la oportunidad de escribir en un blog tan prestigioso como el suyo y que llevo leyendo desde que me inicié en esto de la seguridad.

http://www.securitybydefault.com/2015/03/mi-experiencia-en-rootedcon-2015.html