Seguridad: ¿Cómo almacenar Llave de encriptación localmente?

04/01/2007 - 19:05 por Néstor Sánchez A. | Informe spam
Hola,
tengo la siguiente duda respecto a seguridad y quisiera saber cuál es la
mejor práctica.
Para una aplicación WinForms C/S se requiere almacenar la Llave de
encriptación localmente.
¿cómo se podría almacenar la llave para que fuera accedida sólo por la
aplicación WinForms y no un usuario malicioso?
Alternativas:
- Un archivo: La clave tendría que a su vez estar encriptada para que no
fuera visible a simple vista.
- En duro en la aplicación: El problema es que el programa se puede
decompilar (incluso si está ofuscado).
- ¿Depender de un servicio del Sistema Operativo u otro ente externo?
Gracias de antemano,

Néstor.

Preguntas similare

Leer las respuestas

#6 Néstor Sánchez A.
05/01/2007 - 23:24 | Informe spam
Finalmente llegamos al hackeo... y veo que con la decompilación,
al hacer la réplica, podría capturar cualquier password que un usuario
pudiera ingresar.
Creo que esta problemática da para que teorizemos harto.

"Alberto Poblacion"
escribió en el mensaje news:
"Néstor Sánchez A." wrote in message
news:
Pero si el programa es decompilado entonces se puede crear una réplica
impostora y acceder al server.
Según veo no hay solución.



Estamos mezclando dos cosas: autenticación y cifrado. La pregunta
original sólo se refería al cifrado, y con este sistema se resuelve: Una
vez establecida la comunicación no es posible interceptarla escuchando en
la linea, por lo que si el usuario teclea algo y se lo manda al servidor,
nadie puede "espiar" y saber qué es lo que el usuario ha preguntado o qué
es lo que el servidor ha contestado.

Otra cosa distinta es la autenticación, es decir, saber QUIEN es el que
está haciendo esas preguntas al servidor, cosa que efectivamente no se
resuelve con el mecanismo anterior. Una forma de resolverlo es tecleando
una password y enviándola al servidor para que éste la compruebe. Dicha
password obviamente debe transmitirse a través de la conexión cifrada para
que nadie pueda "capturarla". En consecuencia, es útil y tiene sentido
establecer dicha comunicación cifrada (con el mecanismo que hemos
descrito) ANTES de haber autenticado al usuario, ya que dicha
autenticación se realiza a través de la conexión cifrada. Aunque alguien
cree una réplica impostora y por tanto pueda abrir un canal encriptado al
servidor, si no sabe la password que tiene que teclear para transmitir por
el canal encriptado, el servidor no le hace caso.

Por cierto, básicamente este mecanismo es el mismo que usa el navegador
de internet cuando te conectas a un servidor con https:. El https lo único
que hace es establecer el canal cifrado para que no se pueda espiar la
linea, pero eso no quita que luego, si el servidor lo necesita, tengas que
autenticarte, por ejemplo, accediendo a un formulario de login. La
conexión encriptada impide que alguien pinchando la linea sepa qué es lo
que estás tecleando en el formulario de login.




Respuesta Responder a este mensaje
#7 Alberto Poblacion
06/01/2007 - 08:41 | Informe spam
"Néstor Sánchez A." wrote in message
news:
Finalmente llegamos al hackeo... y veo que con la decompilación,
al hacer la réplica, podría capturar cualquier password que un usuario
pudiera ingresar.



Solo si modifican el programa y sustituyen al anterior. Cosa que se
puede impedir firmando el ejecutable con un certificado y configurando la
política de seguridad de .Net para que no dé permisos de ejecución a los
ejecutables no firmados con ese certificado.
Para eso hay que asumir que el Sistema es seguro. Si el hacker se
"cuela" en el sistema y adquiere permisos administrativos, entonces sí que
estamos perdidos.
email Siga el debate Respuesta Responder a este mensaje
Ads by Google
Help Hacer una pregunta AnteriorRespuesta Tengo una respuesta
Search Busqueda sugerida