¿Cómo se puede asegurar una contraseña / clave en el código fuente [duplicado]?

Respuesta corta: no puedes .

Nunca puedes proteger una contraseña que estás distribuyendo. Puede ocultarlo entre algunas cadenas y usar otras operaciones para "cubrir" la contraseña, pero al final tendrá que ponerlo todo junto para que su función funcione. Y aquí es donde la galleta la va a llevar.

No hay una manera fácil de resolver este problema y, por lo general, significa que no ha elegido el mejor esquema de seguridad o, si cree que es suficiente, tal vez significa que simplemente no necesita este tipo de seguridad.

Y si realmente, realmente, realmente tienes que hacerlo de esa manera, tendrás que ir con "seguridad por oscuridad", después de todo, cuanto más se demore en ser resquebrajado, mejor. Será mejor que tengas algún sistema de detección para cuando esto suceda.

Como ejemplo, considere la industria del juego todos estos años con sus protecciones de copia, etc., si hubiera habido una manera de lograr la seguridad dentro del código en sí mismo que significaría el fin de la "piratería".

Si bien la respuesta de @kiBytes es correcta desde un punto de vista práctico, me gustaría agregar para agregar que un artículo reciente por Amit Sahai sugiere una forma (teórica) de construir un ofuscador de caja negra criptográficamente "duro" retroceder. (Consulte aquí para obtener un artículo alámbrico al respecto).

No es, sin embargo, como si pudieras o incluso deberías implementarlo: hasta ahora, es completamente impráctico de usar en software real y aún no se ha examinado adecuadamente. No obstante, es interesante.

Como dice @kiBytes, simplemente no puede asegurar una contraseña o clave dentro del código fuente. Agregaría (en caso de que la gente llegue a esta pregunta tratando de resolver una inquietud general) que en el ejemplo que da (una aplicación que usa una API), no es necesario que la clave de la API se almacene en el código fuente de la aplicación.

Normalmente, la clave API se almacena en un servidor que usted controla. Para acceder a la API, su aplicación realiza una solicitud al servidor, que a su vez hace una solicitud a la API, y luego responde a su aplicación con la información que recupera de la API.

Aparte de eso, lo ideal sería que la clave de la API tampoco esté almacenada en el código fuente del servidor, ya que eso presumiblemente está incluido en el control de versiones y, por lo tanto, es potencialmente inseguro.

Algo que hice hace 20 años fue dividir la clave en sus caracteres individuales y luego construir una colección de objetos que devolviera explícitamente esos caracteres en la secuencia correcta una vez que los objetos se ordenaron en función de otro atributo de las clases. Con la ofuscación, esto es bastante difícil de descifrar, especialmente si el orden correcto de los objetos es difícil de determinar (p. Ej., Cambia según el entorno de la aplicación).

Tenga en cuenta que la práctica estándar para almacenar contraseñas EN CUALQUIER LUGAR es nunca almacenar la propia contraseña. En su lugar, almacene el resultado de un hash criptográfico (una "puerta trampa", o unidireccional, cifrado) de la contraseña. Cuando el usuario ingrese una contraseña, táchela de la misma manera y compare las versiones encriptadas.

En este caso, como señala Brendan, la cuestión es la autenticación del cliente en lugar del servidor. Esto es más difícil ya que el código del cliente teóricamente puede ser de ingeniería inversa. La mejor sugerencia que puedo ofrecer es hacer que el propio cliente actúe como la contraseña en un sistema de respuesta-desafío: solicite al host que envíe una solicitud para que se calcule una suma de comprobación criptográfica de un (parcialmente) subconjunto del programa seleccionado al azar, que el host verificará un resultado precomputado con la misma versión del código del cliente.

Esto no protege contra la piratería, per se. Protege contra el acceso de clientes que no sean los aprobados. No sé si eso responde a sus necesidades o no.