No, tranquilos, de momento no hemos comprado acciones para invertir en pornografía, ni hemos hecho ningún acuerdo para cambiar Security por Sex (by default). Aunque es posible que debiéramos plantearnos hacerlo, ya que la industria del porno ocupa una gran parte de Internet, y de esa tarta llamada dinero, se lleva un buen pedazo.
Y todo ese dinero hay que protegerlo, y a los clientes tenerlos contentos. Es por ello que curiosamente las páginas web de esta querida industria tienen medidas de seguridad bastante bien montadas.
A primera vista y generalizando podríamos diferenciar entre dos tipos de contenidos, los gratuitos y los de pago. Ya que estamos hablando de webs serias, los gratuitos serían el típico tour con trailers incluidos, y los de pago el contenido completo.
Evidentemente el objetivo es que, después de ser picado por el gusanillo del contenido gratuito, el usuario pase por caja para ver contenidos de verdad. ¿Y qué es lo que se quiere evitar? Que el usuario se salte el paso de pasar por caja para ver ese contenido.
Para evitar ésto, en la industria se ha extendido bastante el uso del producto Strongbox security system. Se trata de un software que protege y gestiona el login de acceso a miembros, además de añadir protección contra, por ejemplo, ataques de fuerza bruta, uso de la misma cuenta entre varios usuarios o descarga recursiva de la web.
Todo ésto con un completo sistema de reportes (screenshots incluidas) que almacena horas, IPs, países, usuarios, tiempos de actividad, logins, logins fallidos, ...
Además, para evitar ese gran enemigo de este tipo de sitios, que son los pares de usuario / contraseña comprometidos y publicados en foros, ofrecen un servicio de búsqueda automática y baneo de estas cuentas, por el módico precio de 5$ al mes.
Lo paradójico de todo esto, es que aún con tanta protección para el sitio web, el usuario inicia sesión y sus datos viajan en claro. Vale que puede no estar en manos de esta empresa implementar su sistema en el sitio con HTTPS, ¿pero ni siquiera hacer, por ejemplo, MD5 de la contraseña mediante Javascript? Pues no, ni siquiera eso.
La otra estrella del login en el área de miembros de la industria es la autenticación HTTP básica. Es increíble la cantidad de sitios que la implementan. ¿Será por la facilidad de gestión de .htaccess y .htpasswd? El hecho es que los credenciales del usuario vuelven a viajar en claro, al menos en aquellas que usen HTTP, que son la mayoría.
En cuanto a buscar en estas webs contenidos de pago a mano en el servidor mediante urls predecibles, listing de directorios o google hacking es complicado, ya que suelen tener la separación de privilegios bien montada. Tienen perfectamente definido lo que cada usuario puede y no puede ver.
La conclusión es que de forma general, las webs de esta industria suelen tener muy bien protegidos y controlados sus contenidos. No podemos decir que se aplique el mismo nivel de seguridad a los usuarios, que no sólo se les controla con tiempos de acceso, IPs, países y más datos personales de manera excesiva, sino que sus credenciales, que su dinero les han costado, viajan en claro.
Eso sí, siempre hay algún despistado que ni una cosa ni la otra. Hasta el día que a algún usuario con las manos ocupadas se le va el dedo a la tecla de la comilla y ...
Sitio web no apto para menores
... ups.
7 comments :
Una duda. Cifrar la contraseña en md5 utilitzando javascript que te aporta? Si te el pillan el md5 no saben que contraseña genera dicho hash md5, pero entiendo que en la parte del servidor sólo comparas els hash con lo cual te importa poco la contraseña que origina ese hash, no?
Saludos y gracias
Yo creo que se refiere a que por lo menos deberían de hacer esa minucia, así no viajaran en "tan" claro.
Si, pero eso realmente no aporta nada, al menos yo no lo veo.
Porque si tu envias el hash md5, este no lo puedes desencriptar en el servidor por medios razonables, lo normal, es que lo compares directamente con la base de datos. Entonces, si pillas el hash, tu envias el hash [igual que hace el formulario despues de hacer md5(password) ] junto con el usuario, y te podrías logar... no se si se me entiende.
Para un novato puede que el ver el md5 diga "oh! está encriptado, pierdo el tiempo, probemos otra web".
Es una buena pregunta. Imaginad el siguiente escenario:
Servidor envía en el formulario una salt. El cliente hace MD5 de su password + la salt, y se envía al servidor.
El servidor cifra la password que tiene almacenada de la cuenta (si, en texto claro) con la salt proporcionada, y si coincide accede a la cuenta.
En caso de que un atacante consiga sniffar la salt y el MD5 generado le da igual porque necesita la password para generar ese MD5 en el login que él realice.
Es una solución deficiente, porque entre otras cosas, en el servidor las passwords se guardan en texto claro, pero mejor éso a que directamente se envíen en texto claro. En entornos en los que no se puede montar SSL se pueden hacer apaños utilizando cosas así, que sigue siendo una pequeña capa de seguridad.
Pero cualquier cosa que envié el usuario sea salt+md5(pass) se enviara en texto claro al servidor ya que no tiene SSL , si alguien hace sniffing obtendrá el salt+md5(pass), por ende seria válido ya que el servidor puede hacer miles de operaciones pero tiene que hacerlas mediante los parámetros que el usuario le proporciono.
No se computa salt + md5(pass), se computa md5(pass + salt)
ahí es donde entra en juego la sal.
Saludos
Publicar un comentario