Recientemente tuve tiempo para pensar nuevamente en cómo debería funcionar una función de restablecimiento de contraseña segura, primero cuando estaba integrando esta funcionalidad en , y luego cuando ayudó a otra persona a hacer algo similar. En el segundo caso, quería darle un enlace a un recurso canónico con todos los detalles sobre cómo implementar de forma segura la función de reinicio. Sin embargo, el problema es que no existe tal recurso, al menos no uno que describa todo lo que me parece importante. Entonces decidí escribirlo yo mismo.
Verás, el mundo de las contraseñas olvidadas es bastante misterioso. Hay muchos puntos de vista diferentes, completamente aceptables y muchos bastante peligrosos. Es probable que se haya encontrado con cada uno de ellos muchas veces como usuario final; Así que intentaré usar estos ejemplos para mostrar quién lo está haciendo bien, quién no y en qué debes concentrarte para tener la función correcta en tu aplicación.
Almacenamiento de contraseñas: hash, cifrado y (¡jadea!) texto sin formato
No podemos discutir qué hacer con las contraseñas olvidadas antes de discutir cómo almacenarlas. Las contraseñas se almacenan en la base de datos en uno de tres tipos principales:
- Texto sencillo. Hay una columna de contraseña, que se almacena en formato de texto sin formato.
- Cifrado. Normalmente se utiliza cifrado simétrico (se utiliza una clave tanto para el cifrado como para el descifrado) y las contraseñas cifradas también se almacenan en la misma columna.
- Troceado. Proceso unidireccional (la contraseña se puede codificar, pero no se puede eliminar); contraseña, me gustaría tener esperanza, seguido de una sal, y cada uno está en su propia columna.
Vayamos directamente a la pregunta más simple: ¡Nunca almacene contraseñas en texto plano! Nunca. Una sola vulnerabilidad a , una copia de seguridad descuidada o uno de docenas de otros errores simples, y eso es todo, fin del juego, todas tus contraseñas, es decir, lo siento, contraseñas de todos tus clientes pasará a ser de dominio público. Por supuesto, esto significaría una gran probabilidad de que de todas sus cuentas en otros sistemas. Y será tu culpa.
El cifrado es mejor, pero tiene sus debilidades. El problema del cifrado es el descifrado; podemos tomar estos cifrados que parecen locos y convertirlos nuevamente a texto sin formato, y cuando eso sucede, volvemos a la situación de las contraseñas legibles por humanos. ¿Como sucedió esto? Hay un pequeño defecto en el código que descifra la contraseña y la hace pública; esta es una forma. Los piratas informáticos obtienen acceso a la máquina en la que se almacenan los datos cifrados; este es el segundo método. Otra forma, nuevamente, es robar la copia de seguridad de la base de datos y alguien también obtiene la clave de cifrado, que a menudo se almacena de manera muy insegura.
Y esto nos lleva al hash. La idea detrás del hash es que es unidireccional; La única forma de comparar la contraseña ingresada por el usuario con su versión hash es aplicar hash a la entrada y compararlas. Para evitar ataques de herramientas como las tablas arcoíris, salamos el proceso con aleatoriedad (lea mi sobre almacenamiento criptográfico). En última instancia, si se implementa correctamente, podemos estar seguros de que las contraseñas hash nunca volverán a ser texto sin formato (hablaré sobre los beneficios de los diferentes algoritmos hash en otra publicación).
Un argumento rápido sobre hash versus cifrado: la única razón por la que alguna vez necesitarías cifrar en lugar de hacer hash una contraseña es cuando necesitas ver la contraseña en texto sin formato, y nunca deberías querer esto, al menos en una situación de sitio web estándar. Si necesitas esto, ¡lo más probable es que estés haciendo algo mal!
¡Atención!
A continuación en el texto del post hay parte de una captura de pantalla del sitio web pornográfico AlotPorn. Está cuidadosamente recortado para que no haya nada que no puedas ver en la playa, pero si aún así es probable que cause algún problema, no te desplaces hacia abajo.
Restablece siempre tu contraseña nunca no le recuerdes
¿Alguna vez te han pedido que crees una función? recordatorios ¿contraseña? Da un paso atrás y piensa en esta petición al revés: ¿por qué es necesario este “recordatorio”? Porque el usuario olvidó la contraseña. ¿Qué queremos hacer realmente? Ayúdalo a iniciar sesión nuevamente.
Me doy cuenta de que la palabra "recordatorio" se usa (a menudo) en un sentido coloquial, pero lo que realmente estamos tratando de hacer es ayudar de forma segura al usuario a estar en línea nuevamente. Dado que necesitamos seguridad, hay dos razones por las que un recordatorio (es decir, enviar al usuario su contraseña) no es apropiado:
- El correo electrónico es un canal inseguro. Así como no enviaríamos nada confidencial por HTTP (usaríamos HTTPS), no deberíamos enviar nada confidencial por correo electrónico porque su capa de transporte es insegura. De hecho, esto es mucho peor que simplemente enviar información a través de un protocolo de transporte inseguro, porque el correo a menudo se almacena en un dispositivo de almacenamiento, accesible para los administradores del sistema, reenviado y distribuido, accesible al malware, etc. El correo electrónico no cifrado es un canal extremadamente inseguro.
- De todos modos, no deberías tener acceso a la contraseña. Vuelva a leer la sección anterior sobre almacenamiento: debe tener un hash de la contraseña (con una buena sal fuerte), lo que significa que no debería poder de ninguna manera extraer la contraseña y enviarla por correo.
Déjame demostrar el problema con un ejemplo. : Aquí hay una página de inicio de sesión típica:
Obviamente, el primer problema es que la página de inicio de sesión no se carga a través de HTTPS, pero el sitio también le solicita que envíe una contraseña (“Enviar contraseña”). Este puede ser un ejemplo del uso coloquial del término mencionado anteriormente, así que vayamos un paso más allá y veamos qué sucede:
Desafortunadamente, no se ve mucho mejor; y un correo electrónico confirma que hay un problema:
Esto nos dice dos aspectos importantes de usoutdoor.com:
- El sitio no codifica contraseñas. En el mejor de los casos, están cifrados, pero es probable que estén almacenados en texto plano; No vemos evidencia de lo contrario.
- El sitio envía una contraseña a largo plazo (podemos volver atrás y usarla una y otra vez) a través de un canal no seguro.
Una vez aclarado esto, debemos verificar si el proceso de reinicio se realiza de manera segura. El primer paso para hacer esto es asegurarse de que el solicitante tenga derecho a realizar el reinicio. En otras palabras, antes de esto necesitamos un control de identidad; Echemos un vistazo a lo que sucede cuando se verifica una identidad sin verificar primero que el solicitante sea realmente el propietario de la cuenta.
Listado de nombres de usuario y su impacto en el anonimato
Este problema se ilustra mejor visualmente. Problema:
¿Lo ves? Presta atención al mensaje “No hay ningún usuario registrado con esta dirección de correo electrónico”. El problema surge obviamente si un sitio así confirma presencia usuario registrado con dicha dirección de correo electrónico. Bingo: ¡acabas de descubrir el fetiche porno de tu marido/jefe/vecino!
Por supuesto, la pornografía es un ejemplo bastante icónico de la importancia de la privacidad, pero los peligros de asociar una identidad con un sitio web específico son mucho más amplios que la situación potencialmente incómoda descrita anteriormente. Un peligro es la ingeniería social; Si el atacante puede relacionar a una persona con el servicio, entonces tendrá información que podrá comenzar a utilizar. Por ejemplo, puede ponerse en contacto con una persona que se hace pasar por representante de un sitio web y solicitarle información adicional en un intento de cometer un delito. .
Estas prácticas también plantean el peligro de la “enumeración de nombres de usuario”, mediante la cual se puede verificar la existencia de una colección completa de nombres de usuario o direcciones de correo electrónico en un sitio web simplemente realizando consultas grupales y examinando las respuestas. ¿Tiene una lista de direcciones de correo electrónico de todos los empleados y unos minutos para escribir un guión? ¡Entonces ves cuál es el problema!
¿Cuál es la alternativa? De hecho, es bastante simple y está maravillosamente implementado en :
Aquí Entropay no revela absolutamente nada sobre la existencia de una dirección de correo electrónico en su sistema. a alguien que no posee esta dirección... Si usted propio esta dirección y no existe en el sistema, entonces recibirás un correo electrónico como este:
Por supuesto, puede haber situaciones aceptables en las que alguien piensaque te has registrado en el sitio web. pero este no es el caso, o lo hice desde otra dirección de correo electrónico. El ejemplo mostrado arriba maneja bien ambas situaciones. Evidentemente, si la dirección coincide, recibirás un correo electrónico que te facilitará el restablecimiento de tu contraseña.
La sutileza de la solución elegida por Entropay es que la verificación de la identificación se realiza de acuerdo con email antes de cualquier verificación en línea. Algunos sitios piden a los usuarios la respuesta a una pregunta de seguridad (más sobre esto a continuación) a cómo puede comenzar el reinicio; sin embargo, el problema con esto es que debes responder la pregunta proporcionando alguna forma de identificación (correo electrónico o nombre de usuario), lo que hace que sea casi imposible responder intuitivamente sin revelar la existencia de la cuenta del usuario anónimo.
Con este enfoque hay pequeña Disminución de la usabilidad porque si intenta restablecer una cuenta inexistente, no hay respuesta inmediata. Por supuesto, ese es el objetivo de enviar un correo electrónico, pero desde la perspectiva de un usuario final real, si ingresa la dirección incorrecta, solo lo sabrá por primera vez cuando reciba el correo electrónico. Esto puede causar cierta tensión por su parte, pero es un pequeño precio a pagar por un proceso tan poco común.
Otra nota, un poco fuera de tema: las funciones de asistencia al inicio de sesión que revelan si un nombre de usuario o dirección de correo electrónico es correcto tienen el mismo problema. Responda siempre al usuario con un mensaje "Su combinación de nombre de usuario y contraseña no es válida" en lugar de confirmar explícitamente la existencia de las credenciales (por ejemplo, "el nombre de usuario es correcto, pero la contraseña es incorrecta").
Enviar contraseña de restablecimiento versus enviar URL de restablecimiento
El siguiente concepto que debemos discutir es cómo restablecer su contraseña. Hay dos soluciones populares:
- Generar una nueva contraseña en el servidor y enviarla por correo electrónico
- Envíe un correo electrónico con una URL única para facilitar el proceso de reinicio
A pesar de , el primer punto nunca debe usarse. El problema con esto es que significa que hay contraseña almacenada, al que puedes regresar y utilizar nuevamente en cualquier momento; Se envió a través de un canal inseguro y permanece en tu bandeja de entrada. Lo más probable es que las bandejas de entrada estén sincronizadas entre los dispositivos móviles y el cliente de correo electrónico, además pueden almacenarse en línea en el servicio de correo electrónico web durante mucho tiempo. El caso es que un buzón no puede considerarse un medio fiable de almacenamiento a largo plazo.
Pero además de esto, el primer punto tiene otro problema grave: simplifica lo máximo posible bloquear una cuenta con intenciones maliciosas. Si conozco la dirección de correo electrónico de alguien que posee una cuenta en un sitio web, puedo bloquearlo en cualquier momento simplemente restableciendo su contraseña; ¡Este es un ataque de denegación de servicio servido en bandeja de plata! Es por eso que el reinicio solo debe realizarse después de una verificación exitosa de los derechos del solicitante.
Cuando hablamos de una URL de restablecimiento, nos referimos a la dirección de un sitio web que está exclusivo de este caso particular del proceso de reinicio. Por supuesto, debe ser aleatorio, no debe ser fácil de adivinar y no debe contener ningún enlace externo a la cuenta que facilite el restablecimiento. Por ejemplo, la URL de restablecimiento no debería ser simplemente una ruta como "Reset/?username=JohnSmith".
Queremos crear un token único que se pueda enviar por correo como una URL de restablecimiento y luego compararlo con el registro del servidor de la cuenta del usuario, confirmando así que el propietario de la cuenta es, de hecho, la misma persona que está intentando restablecer la contraseña. Por ejemplo, un token podría ser "3ce7854015cd38c862cb9e14a1ae552b" y almacenarse en una tabla junto con el ID del usuario que realiza el reinicio y la hora en que se generó el token (más sobre esto a continuación). Cuando se envía el correo electrónico, contiene una URL como “Reset/?id=3ce7854015cd38c862cb9e14a1ae552b”, y cuando el usuario lo descarga, la página solicita la existencia del token, luego de lo cual confirma la información del usuario y le permite cambiar el contraseña.
Por supuesto, dado que el proceso anterior (con suerte) permite al usuario crear una nueva contraseña, debemos asegurarnos de que la URL se cargue a través de HTTPS. No, , esta URL de token debe utilizar seguridad de capa de transporte para que el formulario de nueva contraseña no pueda ser atacado y la contraseña creada por el usuario se transmitió a través de una conexión segura.
Además, para la URL de restablecimiento, debe agregar un límite de tiempo simbólico para que el proceso de restablecimiento pueda completarse dentro de un intervalo determinado, digamos dentro de una hora. Esto garantiza que la ventana de tiempo de reinicio se mantenga al mínimo para que el destinatario de la URL de reinicio solo pueda actuar dentro de esa ventana muy pequeña. Por supuesto, el atacante puede iniciar el proceso de reinicio nuevamente, pero necesitará obtener otra URL de reinicio única.
Por último, debemos asegurarnos de que este proceso sea desechable. Una vez que se completa el proceso de restablecimiento, se debe eliminar el token para que la URL de restablecimiento ya no funcione. El punto anterior es necesario para garantizar que el atacante tenga una ventana muy pequeña durante la cual pueda manipular la URL de restablecimiento. Además, por supuesto, una vez que el reinicio se realiza correctamente, el token ya no es necesario.
Algunos de estos pasos pueden parecer demasiado redundantes, pero no interfieren con la usabilidad y de hecho mejorar la seguridad, aunque en situaciones que esperamos sean raras. En el 99% de los casos, el usuario habilitará el restablecimiento en un período de tiempo muy corto y no volverá a restablecer la contraseña en un futuro próximo.
Papel del CAPTCHA
¡Oh, CAPTCHA, la característica de seguridad que a todos nos encanta odiar! De hecho, CAPTCHA no es tanto una herramienta de protección sino una herramienta de identificación, ya sea usted una persona o un robot (o un script automatizado). Su objetivo es evitar el envío automático de formularios, lo que, por supuesto, lata ser utilizado como un intento de romper la seguridad. En el contexto del restablecimiento de contraseñas, CAPTCHA significa que la función de restablecimiento no puede ser forzada de forma bruta para enviar spam al usuario o intentar determinar la existencia de cuentas (lo cual, por supuesto, no será posible si siguió los consejos de la sección sobre verificar identidades).
Por supuesto, el CAPTCHA en sí no es perfecto; Hay muchos precedentes de su software "hackeado" y logrando suficientes tasas de éxito (60-70%). Además, hay una solución que se muestra en mi publicación sobre , donde puedes pagarle a las personas fracciones de centavo para resolver cada CAPTCHA y lograr una tasa de éxito del 94%. Es decir, es vulnerable, pero eleva (ligeramente) la barrera de entrada.
Echemos un vistazo al ejemplo de PayPal:
En este caso, el proceso de reinicio simplemente no puede comenzar hasta que se resuelva el CAPTCHA, por lo que teóricamente es imposible automatizar el proceso. En teoria.
Sin embargo, para la mayoría de las aplicaciones web esto será excesivo y exactamente representa una disminución en la usabilidad: ¡a la gente simplemente no le gusta CAPTCHA! Además, CAPTCHA es algo a lo que puedes volver fácilmente si es necesario. Si el servicio comienza a ser atacado (aquí es donde el registro resulta útil, pero hablaremos de eso más adelante), agregar un CAPTCHA no podría ser más fácil.
Preguntas y respuestas secretas.
Con todos los métodos que consideramos, pudimos restablecer la contraseña con solo tener acceso a la cuenta de correo electrónico. Digo "sólo", pero, por supuesto, es ilegal obtener acceso a la cuenta de correo electrónico de otra persona. necesario ser un proceso complejo. Sin embargo .
De hecho, el enlace de arriba sobre el hackeo del Yahoo! de Sarah Palin. tiene dos propósitos; En primer lugar, ilustra lo fácil que es hackear (algunas) cuentas de correo electrónico y, en segundo lugar, muestra cómo las malas preguntas de seguridad pueden usarse con intenciones maliciosas. Pero volveremos a esto más tarde.
El problema con el restablecimiento de contraseña XNUMX% basado en correo electrónico es que la integridad de la cuenta del sitio que está intentando restablecer depende XNUMX% de la integridad de la cuenta de correo electrónico. Cualquiera que tenga acceso a su correo electrónico tiene acceso a cualquier cuenta que se puede restablecer simplemente recibiendo un correo electrónico. Para este tipo de cuentas, el correo electrónico es la “llave de todas las puertas” de su vida en línea.
Una forma de reducir este riesgo es implementar un patrón de preguntas y respuestas de seguridad. Seguro que ya las has visto: elige una pregunta que sólo tú puedas responder tener conozca la respuesta y luego, cuando restablezca su contraseña, se la solicitará. Esto aumenta la confianza de que la persona que intenta restablecer es efectivamente el propietario de la cuenta.
Volviendo a Sarah Palin: el error fue que las respuestas a su pregunta o preguntas de seguridad se podían encontrar fácilmente. Especialmente cuando eres una figura pública tan importante, la información sobre el apellido de soltera de tu madre, tu historial educativo o dónde pudo haber vivido alguien en el pasado no es tan secreto. De hecho, casi cualquier persona puede encontrar la mayor parte. Esto es lo que le pasó a Sara:
El hacker David Kernell obtuvo acceso a la cuenta de Palin buscando detalles sobre sus antecedentes, como su universidad y fecha de nacimiento, y luego utilizando la función de recuperación de contraseña olvidada de Yahoo!.
Esto es principalmente un error de diseño en Yahoo! — al especificar preguntas tan simples, la empresa esencialmente saboteó el valor de la pregunta de seguridad y, por lo tanto, la protección de su sistema. Por supuesto, restablecer las contraseñas de una cuenta de correo electrónico siempre es más difícil ya que no se puede demostrar la propiedad enviando un correo electrónico al propietario (sin tener una segunda dirección), pero afortunadamente no hay muchos usos para crear un sistema de este tipo hoy en día.
Volvamos a las preguntas de seguridad: existe una opción que permite al usuario crear sus propias preguntas. El problema es que esto resultará en preguntas terriblemente obvias:
De que color es el cielo?
Preguntas que incomodan a las personas cuando se utiliza una pregunta de seguridad para identificar personas (por ejemplo, en un call center):
¿Con quién me acosté en Navidad?
O preguntas francamente estúpidas:
¿Cómo se escribe "contraseña"?
Cuando se trata de cuestiones de seguridad, ¡los usuarios deben salvarse de sí mismos! En otras palabras, la pregunta de seguridad debe ser determinada por el propio sitio, o mejor aún, formulada serie Preguntas de seguridad entre las que el usuario puede elegir. Y no es fácil elegir uno; Lo ideal es que el usuario seleccione dos o más preguntas de seguridad. en el momento del registro de la cuenta, que luego se utilizará como segundo canal de identificación. Tener varias preguntas aumenta la confianza en el proceso de verificación y también brinda la posibilidad de agregar aleatoriedad (no siempre mostrando la misma pregunta), además proporciona un poco de redundancia en caso de que el usuario real haya olvidado la contraseña.
¿Qué es una buena pregunta de seguridad? Esto está influenciado por varios factores:
- Él debe ser breve — la pregunta debe ser clara e inequívoca.
- La respuesta debe ser específico — no necesitamos una pregunta que una persona pueda responder de manera diferente
- Las posibles respuestas deben ser diverso - preguntarle a alguien cuál es su color favorito produce un subconjunto muy pequeño de posibles respuestas
- búsqueda la respuesta debe ser compleja, si la respuesta se puede encontrar fácilmente cualquier (recuerda a la gente en altos cargos), entonces es malo
- La respuesta debe ser permanente con el tiempo: si le preguntas cuál es la película favorita de alguien, un año después la respuesta puede ser diferente
Da la casualidad de que hay un sitio web dedicado a hacer buenas preguntas llamado . Algunas de las preguntas parecen bastante buenas, otras no pasan algunas de las pruebas descritas anteriormente, especialmente la prueba de “facilidad de búsqueda”.
Permítanme demostrarles cómo PayPal implementa las preguntas de seguridad y, en particular, el esfuerzo que pone el sitio en la autenticación. Arriba vimos la página para iniciar el proceso (con un CAPTCHA), y aquí mostraremos lo que sucede después de que ingresas tu dirección de correo electrónico y resuelves el CAPTCHA:
Como resultado, el usuario recibe la siguiente carta:
Hasta ahora todo es bastante normal, pero esto es lo que se esconde detrás de esta URL de reinicio:
Entonces, entran en juego las cuestiones de seguridad. De hecho, PayPal también le permite restablecer su contraseña verificando su número de tarjeta de crédito, por lo que existe un canal adicional al que muchos sitios no tienen acceso. Simplemente no puedo cambiar mi contraseña sin responder. оба pregunta de seguridad (o no saber el número de la tarjeta). Incluso si alguien secuestrara mi correo electrónico, no podría restablecer la contraseña de mi cuenta PayPal a menos que supiera un poco más de información personal sobre mí. ¿Que información? Estas son las opciones de preguntas de seguridad que ofrece PayPal:
La cuestión de la escuela y el hospital puede ser un poco dudosa en términos de facilidad de búsqueda, pero las demás no son tan malas. Sin embargo, para mejorar la seguridad, PayPal requiere una identificación adicional para cambios respuestas a preguntas de seguridad:
PayPal es un ejemplo bastante utópico de restablecimiento seguro de contraseñas: implementa un CAPTCHA para reducir el peligro de ataques de fuerza bruta, requiere dos preguntas de seguridad y luego requiere otro tipo de identificación completamente diferente solo para cambiar las respuestas, y esto después de que el usuario ya ha iniciado sesión. Por supuesto, esto es exactamente lo que esperado de PayPal; es una institución financiera que maneja grandes sumas de dinero. Esto no significa que cada restablecimiento de contraseña deba seguir estos pasos (la mayoría de las veces es excesivo), pero es un buen ejemplo para casos en los que la seguridad es un asunto serio.
La conveniencia del sistema de preguntas de seguridad es que si no lo ha implementado de inmediato, puede agregarlo más tarde si el nivel de protección de recursos lo requiere. Un buen ejemplo de esto es Apple, que recientemente implementó este mecanismo. [artículo escrito en 2012]. Una vez que comencé a actualizar la aplicación en mi iPad, vi la siguiente solicitud:
Luego vi una pantalla donde podía seleccionar varios pares de preguntas y respuestas de seguridad, así como una dirección de correo electrónico de rescate:
En cuanto a PayPal, las preguntas están preseleccionadas y algunas de ellas son bastante buenas:
Cada uno de los tres pares de preguntas/respuestas representa un conjunto diferente de preguntas posibles, por lo que hay muchas formas de configurar una cuenta.
Otro aspecto a considerar al responder su pregunta de seguridad es el almacenamiento. Tener una base de datos de texto sin formato en la base de datos plantea casi las mismas amenazas que una contraseña, es decir, que exponer la base de datos revela instantáneamente el valor y pone en riesgo no sólo la aplicación, sino también aplicaciones potencialmente completamente diferentes que utilizan las mismas preguntas de seguridad (nuevamente ). Una opción es el hash seguro (un algoritmo potente y una sal criptográficamente aleatoria), pero a diferencia de la mayoría de los casos de almacenamiento de contraseñas, puede haber una buena razón para que la respuesta sea visible como texto sin formato. Un escenario típico es la verificación de identidad por parte de un operador telefónico en vivo. Por supuesto, el hash también es aplicable en este caso (el operador puede simplemente ingresar la respuesta nombrada por el cliente), pero en el peor de los casos, la respuesta secreta debe ubicarse en algún nivel de almacenamiento criptográfico, incluso si es solo cifrado simétrico. . Resumir: ¡Trata los secretos como secretos!
Un último aspecto de las preguntas y respuestas de seguridad es que son más vulnerables a la ingeniería social. Intentar extraer directamente la contraseña de la cuenta de otra persona es una cosa, pero iniciar una conversación sobre su formación (una pregunta de seguridad popular) es completamente diferente. De hecho, es muy posible que puedas comunicarte con alguien sobre muchos aspectos de su vida que podrían plantear una pregunta secreta sin despertar sospechas. Por supuesto, el objetivo de una pregunta de seguridad es que se relaciona con la experiencia de vida de alguien, por lo que es memorable, y ahí es donde radica el problema. ¡A la gente le encanta hablar sobre sus experiencias de vida! Es poco lo que puede hacer al respecto, sólo si elige dichas opciones de preguntas de seguridad para que sean menor Probablemente podría eliminarse mediante ingeniería social.
[Continuará.]Sobre los derechos de publicidad
VDSina ofrece confiable , cada servidor está conectado a un canal de Internet de 500 Megabits y está protegido contra ataques DDoS de forma gratuita.
Fuente: habr.com