2010-10-14 46 views
7

Necesito "proteger con contraseña" mi aplicación, pero necesito asesoramiento sobre dónde almacenar la contraseña de forma segura.Almacenar una contraseña de forma segura

¿Cómo voy a hacer esto:

La primera vez que se ejecuta el programa, se solicitará al usuario que cree una contraseña. La contraseña será salada y codificada en SHA-256 y luego guardada en el Registro o en un archivo.

El problema:

Si puedo almacenar la contraseña con algoritmo hash en el Registro o un archivo (o ambos), entonces sería demasiado fácil para alguien que acaba de eliminar la clave en el registro o el archivo y se le pedirá que crear una nueva contraseña ...

¿Cómo puedo guardar de forma segura la contraseña hash para que sea más difícil eliminarla?

He pensado en almacenarlo en el Registro y también crear un archivo con los Atributos ocultos y del sistema para leer en caso de que se elimine el archivo del Registro, pero parece una tontería ya que también podría eliminarse fácilmente.

// Espero haber publicado esta pregunta correctamente con las etiquetas correctas - Soy nuevo aquí, así que por favor vaya fácil. ;)

Todo lo mejor

Chris (Shamballa)

+0

¿De quién/contra qué te estás defendiendo? – SLaks

+0

¿Por qué debería su usuario ser capaz de dar una contraseña desde el principio y luego nunca más? – codymanix

+0

SLaks ... Necesito asegurarme de que nadie pueda acceder al programa, excepto la persona que creó la contraseña. – Shambhala

Respuesta

15

Esto es básicamente un problema de programación de Ética 101. Si está almacenando información en la computadora de otra persona, recuerde que la computadora es de su propiedad y tienen el derecho de eliminar o modificar cualquier archivo o clave de registro. Tratar de hacerlo para que no puedan es una muy mala idea.

Hay una buena razón por la que no puedes hacerlo. ¿Qué pasaría si alguien comenzara a poner archivos que no puede eliminar o modificar en su computadora? Extrapolate a la conclusión lógica: ¿Qué pasaría si un virus comenzara a poner archivos que no puedes eliminar o modificar en tu computadora, y lo hicieras en un ciclo infinito hasta que el disco duro estuviera lleno? Usted sabe si fuera posible, alguien lo intentaría.

Si desea un programa que almacene una contraseña en algún lugar donde el usuario no pueda modificarla, colóquela en su servidor y haga que su programa se contacte con ella a través de una conexión a Internet. (Que es una lata de gusanos completamente diferente, pero al menos no está tratando de hacer cosas imposibles o violar los derechos de propiedad básicos de sus usuarios).

+2

A través de Internet es una forma muy segura, pero luego tiene la molestia de asegurarse de que su servicio siempre esté listo para permitir su inicio de sesión, como algunos de los servicios de juegos que existen. Esto también le permitiría administrar su estructura de licencias (si tiene una) en su servidor, si el programa solo funciona cuando se puede conectar a su servicio. Esto tiene sus propios inconvenientes por no hacerlo. – jimplode

+0

Sí. Como dije, esto trae su propia lata de gusanos. Pero al menos es teóricamente posible. Lo que el OP quiere simplemente no es. –

+0

Creo que el problema ético es doble en ambos sentidos. Siempre que el usuario pueda cambiar o eliminar la contraseña, primero al proporcionar la contraseña existente, no creo que le quite ningún derecho. El problema es que el usuario que desea específicamente bloquear su aplicación una vez que se ha creado una contraseña, ¿cómo puede lograrse? –

3

La mejor solución sería confiar en una fuente externa que el el usuario NO puede controlar almacenar una parte de la contraseña. De lo contrario, no importa dónde lo ocultes, puede ser descubierto fácilmente por alguien con algunas herramientas gratuitas y un poco de tiempo.

Personalmente, he encontrado que el mejor lugar para almacenar dichos datos es a la vista, junto con otros datos a los que accede frecuentemente la aplicación. Tenga en cuenta que si el usuario tiene acceso para modificar los datos, está en riesgo.

Si desea bloquear su programa, exija que la clave ya exista antes de que se ejecute su programa. De esta forma, solo tendrá que preocuparse por cómo obtener la clave y, dado que está encriptada, le resultará más difícil crear una que funcione para su sistema.

Para su proceso de autenticación inicial, puede colocar una parte de la clave en su servidor web, dar al usuario una clave de acceso necesaria para crear el archivo cifrado.El uso de la clave de acceso los conduciría a la clave de su servidor y, si es válida, les permitirá guardar el archivo cifrado. Si le preocupa la reactivación, una vez activada, puede eliminar el archivo en su servidor web.

Otra opción sería usar algo como OnGuard (latest versions) para codificar una clave de tiempo limitado que le proporcione al usuario. Luego, cuando se ejecuta la activación, verifique que la llave que suministró haya expirado o no y, de ser así, no permita la activación. De esta forma, su clave de activación solo corre riesgo durante un tiempo limitado.

No gaste demasiado tiempo en esto. Incluso el mejor algoritmo se puede remendar con unas pocas instrucciones NOP después de desplegar la aplicación.

+1

Esta es una buena opción, libera el programa con algún tipo de bloqueo de teclas. de modo que una clave de serie generada desbloqueará el programa y permitirá que se use y se ejecute, luego permitirá que los usuarios proporcionen su propia contraseña. Este es un modelo mucho más limpio que tratar de insistir en que utilicen la conexión a Internet para verificar las licencias. Aquí hay un enlace a un kit de inicio de shareware, podría darle algunas ideas. http://blogs.msdn.com/b/danielfe/archive/2005/07/10/437293.aspx – jimplode

+0

@jimplode - sí, eso también funciona, pero no limita el uso de la clave a menos que haya algo externo para trabajar En contra. – skamradt

+0

yup ... ¡las licencias y la protección en serie son un asunto tan complicado! Si fuera yo, no me molestaría y apuntaré al mercado profesional que pagaría por usarlo y no abusarlo. Especialmente ya que todos están sujetos a auditorías que realmente no pueden hacer trampa. El sector privado ... buena suerte, si está en manos del público en general, se resquebrajará sin importar lo que haga. – jimplode

4

Puede almacenar de forma segura una contraseña para una aplicación usando el Windows crypto API. Hay un ejemplo de su uso en CodeGuru, pero está escrito en C++, no en Delphi. El código no es demasiado desafiante, por lo que debe convertirse con relativa facilidad a Delphi.

Una solución más avanzada sería pedirle al usuario la contraseña antes de descargar la aplicación, e insertar la parte del código binario de la contraseña hash; por supuesto, si obtuvo varias copias de la aplicación podría determinar fácilmente la ubicación del valor cifrado y el código que lo controla para eliminarlo.

El problema es que no ha creado ningún valor por el uso de la contraseña, es decir, parece ser solo una contraseña. Debe usar la contraseña como una semilla para encriptar los datos de la aplicación y vincular la contraseña a los datos. Pierde la contraseña y solo pierde los datos.

1

Hay al menos 2 formas en que puedo interpretar su pregunta.

(1) Desea almacenar contraseñas para que puedan usarse posteriormente para iniciar sesión en una base de datos remota.

This answer en Password encryption in Delphi explica la parte de encriptación.

De esta forma puede almacenar una contraseña para que luego pueda usarse para autenticar al usuario cuando inicia sesión usando su aplicación en un servidor de base de datos o algo así.

La parte "no eliminar" es realmente delicada para los usuarios; Yo no haría eso.

(2) Desea almacenar una contraseña, por lo que se puede utilizar para validar a un usuario para acceder localmente a su aplicación.

Esto es más difícil, ya que básicamente no se puede.

La manera más cercana es mantener un proceso en segundo plano en ejecución que mantiene un bloqueo en el archivo.
Usted se comunica con ese proceso para desbloquear el archivo para que pueda verificar la contraseña.

--jeroen

+0

Disculpe, así que arruina la numeración; Hice tipo 1. y 2. –

+0

... hasta que el usuario utiliza el Administrador de procesos para detectar quién tiene el bloqueo, cancela el proceso y elimina el archivo. ;) –

+1

Es por eso que los escritores de virus y troyanos ponen tanto esfuerzo en ocultar sus cosas. Y no pueden. A menos que instalen un kit raíz como lo hizo Sony para la protección contra copia: http://en.wikipedia.org/wiki/Sony_BMG_CD_copy_protection_scandal –

0

Si sólo necesita una contraseña, encriptar y clavarlo en el extremo del .exe. He hecho esto exitosamente muchas veces.

+0

Si el usuario no es un administrador o no ejecuta el exe elevado, puede que no haya permisos de escritura. – Remko

+0

Esto suena interesante, para almacenar la contraseña dentro del programa? ¿Esto no sería señalado por los programas antivirus como malo? – Shambhala

+0

¡Vaya! ¡Presionó y se envió antes de que terminara de escribir! Iba a agregar >> ¿Cómo hiciste esto? Esto debería agregarse durante el tiempo de ejecución. – Shambhala

0

Sugeriría usar las funciones de autenticación en Windows, específicamente CredWrite y CredRead.También sería posible utilizar las ventanas de cifrado proporciona (CryptProtectData/CryptProtectMemory) y luego guardar las credenciales

EDITAR: Si necesita las cabeceras de Delphi, que están disponibles en el Jedi Windows Api Library.

5

Realmente no especificó qué protege esta contraseña. Asumiré que se usa para proteger los datos creados por su programa.

No soy un experto en seguridad o criptógrafo, pero si los datos se almacenan localmente la solución es simple. Almacene la contraseña (o más probablemente un hash de la contraseña) y los datos en el mismo lugar (archivo, base de datos, etc.) cifrados con claves separadas.

Esto evita la elusión por eliminación de archivos. Eliminarían todos los datos también. Esto frustrará a todos menos al usuario final más determinado.

+0

Iba a mencionar esto también. Use la contraseña como clave de cifrado. De esta forma, sus datos están realmente seguros y no tiene sentido borrar la contraseña. El único problema, sin embargo, es que mucha gente no quiere encriptar sus datos. Quieren poder recuperar sus datos en caso de que olviden su contraseña, pero no quieren que sus datos sean fácilmente accesibles con solo abrir un programa. Sé que no puedes tener tu pastel y comértelo también, pero eso es lo que quieren muchos usuarios. – Kibbee

+0

La contraseña es para proteger el acceso al programa real. es decir. poder acceder realmente al programa una vez instalado. El programa que estoy desarrollando es un programa de encriptación de correo electrónico. Utiliza AES Rijndael en modo CBS de 256 bits, por lo que esta contraseña se elige justo antes del momento de encriptación, pero nunca se almacena. Inicializo la "clave" que usan con SHA-256, que se convierte en la clave real. Nunca se almacena. De lo contrario, el problema sería que alguien pudiera descifrar los datos usando una sola clave predeterminada ... – Shambhala

+0

Quise decir el modo CBC ... – Shambhala

1

A juzgar por su descripción, usted no entiende que si toda la seguridad que se tiene es

if not SameString(Hash(UserPassword), StoredPassword) then exit; 

Entonces usted tiene ninguna seguridad en absoluto, y no es una cuestión de usuario borrar su archivo de contraseñas. El usuario tan sólo puede abrir su archivo ejecutable en cualquier editor binario y NOP a cabo la parte que realiza la verificación:

//if not SameString(Hash(UserPassword), StoredPassword) then exit; 
//Check commented out ---malicious user 

Hay que darse cuenta de que a pesar de que compila su aplicación, todavía contiene todo el código fuente, por si ensamblador. Todavía puede editar la fuente, es un poco más difícil porque ahora está en un idioma diferente.

Por lo tanto, si desea evitar que el usuario haga algo en su aplicación, sólo hay dos maneras:

  1. de protección contra escritura de su aplicación y es archivos. O guárdelos en un servidor separado, si no tiene el control de este. O simplemente hazles un servicio que acepte solo un conjunto fijo de comandos.

  2. Haga que la aplicación no lo verifique, pero encripta algo crítico con contraseña. Claro, el usuario malintencionado puede restablecer la contraseña o incluso eliminar la rutina de descifrado por completo, pero aún tendrá que descifrar los datos.

Se pueden eludir cualquier otra solución, todo lo que difiere es el tiempo y las habilidades que se necesitarán sortear. Por ejemplo, puede cifrar una parte crítica del código de la aplicación y descifrarlo sobre la marcha (lo hizo una vez). Luego ejecuta y encripta de nuevo. Sin la contraseña correcta, su aplicación nunca se ejecutará.

Pero un usuario malintencionado puede instalar una copia separada de la aplicación con contraseña conocida, examinar partes del programa cuando se descifran y ensamblarlas en el origen no encriptado. Claro, eso es mucho trabajo. Pero se puede hacer en un tiempo finito.

Cuestiones relacionadas