Es bastante común últimamente recibir noticias de que algún sitio de gran popularidad ha sido hackeado (O, como suele comunicarse, «su seguridad se ha visto comprometida»).
Dependiendo del tipo de sitio del que se trate el problema puede preocuparnos más o menos.
Claro que eso es cuando somos meramente usuarios del sitio… ¿qué pasa cuándo se trata de un sitio que está bajo nuestra responsabilidad?
Aclaremos algo antes de seguir: es imposible hacer un sitio 100% libre de vulnerabilidades.
Si hay gente decidida a romper nuestra seguridad lo van a lograr (Si tienen la capacidad técnica y/o el teléfono de alguien que la tenga).
Es por eso que es muy importante, no sólo poner trabas a los atacantes si no también dejar un botín poco atractivo para el caso de que lo consigan.
Algo bastante común es que la gente reutilice sus contraseñas en diferentes sitios, con lo cual, el acceso a las contraseñas de un sitio puede permitir a los atacantes hacerse «gratuitamente» con el acceso a otros…
Nuevamente, no vamos a poder evitar que se ponga en juego la integridad de los datos que nuestros usuarios dejan en otros sitios, pero al menos podremos decir que no lo han logrado por nuestra bajada de guardia.
Cómo proteger la información sensible
La única medida real con la que contamos hoy en día es la encripción de los datos sensibles (Como ser las contraseñas).
Hasta hace un tiempo se utilizaba mucho la función MD5 para transformar una clave legible humanamente en un texto indescifrable. Por ejemplo el MD5 de ‘Hola mundo!’ es ‘d501194c987486789bb01b50dc1a0adb’.
Lo que se hacía entonces era calcular el md5 del texto ingresado como contraseña y eso era lo que se almacenaba en la base de datos (y cuando se intentaba un login se volvía a calcular el md5 con lo que se tenía guardado, de modo que la verdadera contraseña no estaba en la base).
Desafortunadamente, todo avanza rápido en la informática y estas funciones (md5 y sha1) ya no son suficientemente seguras (Las computadoras de hoy son tan rápidas que se ha vuelto un problema menor romper este tipo de encripción).
¡Pero no todo está perdido! 🙂
Más allá de md5 y sha1
Desde la versión 5.5 de PHP nos encontramos con buenas librerías de criptografía internas. Dos funciones interesantes son password_hash y password_verify.
Con la primera se obtiene un hash a partir de un texto plano (lo ingresado por el usuario).
Con la segunda se verifica que un texto plano corresponda con un hash.
A muy alto nivel lo que logra es lo mismo que antes, sólo que mucho más seguro (Los algoritmos usados por password_hash son más fuertes).
Pero en realidad es bastante más lo que se logra… Al levantar el nivel de abstracción (usamos una función de hashing que internamente puede usar diversas estrategias para lograr su objetivo) logramos también independizarnos de la implementación particular.
¿Qué significa esto? Simplemente que si en un futuro el algoritmo de encripción usado cambia (Por ejemplo porque se encuentra uno mejor), nuestro código no se verá afectado.
Y ahora, ¿qué pensás hacer con las passwords de tus sitios?
- Cómo agregar una página de error 500 en un proyecto PHP - 31/10/2024
- ¿Cuántos contenedoresnecesita tu php? - 28/10/2024
- Cuál es el mejor framework PHP para hacer APIs REST - 25/10/2024
Muy Buen articulo. bien explicado.
Gracias Luis!
¡Buen artículo!
Siempre he dicho que utilizar md5, sha1, base64 y demás sistemas de cifrado que son fácilmente reversibles en su algoritmo, no sirven para nada. password_hash es lo que he utilizado en todos mis proyectos, me ha funcionado y nunca me ha dado un problema de seguridad con respecto a él. Claramente, pueden existir ataques por diccionario o fuerza bruta, pero eso ya tiene que ver con otro tema de seguridad, sin embargo, con este hash, los hackers tienen más complicado acceder al sistema aún teniendo el hash en mano.
Gracias, Mauro ¡Saludos!
Gracias Jerson! Sólo un comentario: md5 y sha1 son funciones de encripción (es decir, no son reversibles), base64 es un simple encoding (sí es reversible).
El problema de usar directamente esas funciones es que se pierde abstracción. Más vale dejar que sea el intérprete quien elija el algoritmo específico… de esa forma el código es adaptable a nuevas versiones sin problemas.
Saludos!