Este es un problema difícil ya que tiene un enemigo potente: la naturaleza humana. Es natural confiar en nosotros y la experiencia cotidiana demuestra que la confianza funciona. Puedes visitar miles de sitios web sin ningún problema. Entonces, un día, los servidores de su consola de juegos favoritos son pirateados y su identidad digital está en peligro. Hay alrededor de mil millones de personas en línea, pero incluso un ataque como el de Sony solo consiguió 70 millones. Y los ataques a escala de Sony son raros.
A pesar de que la mayoría de las empresas no toman la seguridad realmente seria. Si analiza las brechas de seguridad en los últimos años, incluso las compañías especializadas en seguridad informática se vieron afectadas con el tiempo.
Aquí tenemos una gran brecha aquí: la seguridad debería ser importante, pero en realidad no es tan importante en la vida cotidiana. Puede tener un sitio web inseguro en línea durante años sin ser golpeado o puede hacer clic en un enlace e infectarse con un exploit de día cero que nadie podría haber evitado.
Así que creo que persuadir a la persona promedio sobre la seguridad es el enfoque equivocado. Al igual que en la vida real, la seguridad no debería ser un problema. Ninguna persona en su sano juicio se pone una chaqueta negra antes de salir de la casa en el hemisferio norte (bueno, ya me entiendes). La seguridad tiene que "simplemente funcionar" o no es seguridad.
No funciona porque las computadoras no son lo suficientemente inteligentes y potentes. Mi IDE es lo suficientemente poderoso como para generar 1.5 millones de líneas de código Java en menos de 4 segundos, pero es demasiado tonto para decirme que <input value="<%= dbField%>">
o "select * from table where name = '" + userInput + "'"
es peligroso.
Los lenguajes de programación de hoy ofrecen características sorprendentes como el estilo CSS de la interfaz de usuario, pero hasta el momento, nadie se preocupó por crear un marco que simplifique la escritura de código seguro en lugar de uno inseguro. Si empiezas a escribir aplicaciones RCP de Eclipse, se agregan aproximadamente 100 MB de código de byte Java a tu aplicación y nadie en el mundo puede decir cuántos agujeros de seguridad podría tener este código.
Si un cortafuegos recibe un paquete, la mayoría de las veces, no hay forma de saber de dónde proviene realmente y si contiene lo que debería. Es más importante enrutar un paquete alrededor del mundo en menos de 3 ns que asegurarse de que un correo electrónico proviene del remitente.
OMI, a menos que se aborden estos problemas, no tiene sentido educar a John Doe sobre la seguridad. Debemos empezar a educar a los especialistas, primero. Después de eso, John Doe ya no tendrá que preocuparse.
[EDITAR] Acabo de leer que algunas aplicaciones de Android transmiten el protocolo AuthToken para ClientLogin de Google sin encriptar . Eso significa que cualquiera puede acceder a todas las API de Google en las que tenga una cuenta: Gmail, Calendario, contactos, fotos privadas en Picasa, su blog en blogger.com.
Entonces, si Google no entiende algo tan básico, ¿para qué convencer a John Doe de que la seguridad es importante? :-(