ios - descargar - swift for mac download

En iOS, ¿cómo puedo almacenar una "clave" secreta que me permita comunicarme con mi servidor?

Question

Quiero almacenar una clave secreta ("abc123") que usaré en el encabezado de mis solicitudes de API REST. Mi servidor verificará esta clave secreta. Si coincide con "abc123", permita que se realice la solicitud.

Estoy pensando en una solución simple como:

let secret = "abc123" 

¿Pero habrá alguna desventaja en esto?

Answer 1

Al codificar la cadena en su aplicación, es posible que los atacantes descifren su binario (a través de herramientas como dumpdecrypt ) y obtengan su cadena sin muchos problemas (un simple hexdump incluiría cualquier cadena en su aplicación).

Hay algunas soluciones para esto. Podría implementar un punto final en su API REST que devuelva sus credenciales, que luego podría llamar al inicio. Por supuesto, esto tiene sus propios problemas de seguridad no triviales y requiere una llamada HTTP adicional. Por lo general , no lo haría de esta manera.

Otra opción es ofuscar la clave secreta de alguna manera. Al hacer eso, los atacantes no podrán reconocer instantáneamente su clave después del descifrado. cocoapods-keys es una opción que utiliza este método.

Aquí no hay una solución perfecta: lo mejor que puede hacer es hacer que sea lo más difícil posible para un atacante obtener sus llaves.

(Además, asegúrese de usar HTTPS al enviar solicitudes, de lo contrario, esa es otra buena manera de comprometer sus claves).

Answer 2

Aunque suene loco, esta es probablemente la mejor solución. Todo lo demás es más complicado, pero no mucho más seguro. Cualquier técnica sofisticada de ofuscación que use solo se realizará en ingeniería inversa casi tan rápido como encontrarán esta clave. Pero esta solución de clave estática, aunque es extremadamente insegura, es casi tan segura como las otras soluciones y casi no impone complejidad adicional. Me encanta.

Se romperá casi de inmediato, pero también lo harán todas las demás soluciones. Así que mantenlo simple.

Lo único que realmente desea hacer aquí es usar HTTPS y anclar sus certificados . Y elegiría una clave larga y aleatoria que no sea una palabra. Idealmente, debería ser una cadena de bytes completamente aleatoria, almacenada como valores sin formato (no caracteres) para que no se destaque tan obviamente en su binario. Si quiere volverse loco, aplique un SHA256 antes de enviarlo (para que la clave real nunca aparezca en su binario). Nuevamente, esto es trivial de romper, pero es fácil y no perderá mucho tiempo desarrollando.

Es poco probable que un esfuerzo superior a una hora valga la pena para implementar esta función. Si desea mucho más sobre el tema, consulte Cifrado seguro https para la aplicación de iPhone en la página web y sus enlaces.

Answer 3

He usado el objeto PFConfig (un diccionario) que le permite recuperar en su aplicación valores de variables almacenadas como parámetros de entorno del Servidor.
Similar a las variables de entorno que se pueden recuperar usando ENV en la programación del lado del servidor de sitios web como Ruby o PHP. En mi opinión, esto es casi tan seguro como usar variables de entorno en Ruby o similar.

PFConfig.getConfigInBackgroundWithBlock{
      (config: PFConfig?, error: NSError?) -> Void in
      if error == nil {
        if let mySecret = config["mySecret"] as? String {
          // myFunction(mySecret)
        }

    }

Answer 4

Parece que estás usando tokens de acceso. Usaría Keychain para los tokens de acceso. Para las ID de clientes, las mantendría como variables porque los identificadores de clientes no cambian mientras que los tokens de acceso cambian por usuario, o incluso por token de actualización y el llavero es un lugar seguro para almacenar credenciales de usuario.

Answer 5

Si bien los tokens dentro de banda se usan comúnmente para algunos esquemas, es probable que eventualmente implementes TLS para proteger el tráfico de red y los tokens. Esto, como menciona Rob Napier en otra respuesta .

El uso de su propia cadena de certificados aquí permite el uso de los mecanismos de seguridad y autenticación TLS existentes y el llavero iOS, y también le da la opción de revocar las credenciales TLS si es necesario (¿cuándo?) Y también permite al cliente fijar sus conexiones a sus servidores y detectar la suplantación de servidores si es necesario.

Su propia autoridad de certificación y su propia cadena de certificados son gratuitas, y sus propios certificados son, una vez que carga el certificado raíz en el cliente, son tan seguros como los certificados adquiridos comercialmente.

En resumen, este enfoque basado en certificados combina cifrado y autenticación, utilizando los mecanismos TLS existentes.

Answer 6

Si lo almacena así y si alguien se enfurece con su aplicación, él / ella puede obtener acceso a su clave secreta. Te recomendaría que comiences a almacenar tu secreto como #define o por defecto de usuario por ahora (para que puedas construir tu aplicación primero), y una vez que estés cerca del envío de la aplicación, usa keychain. Aquí hay una respuesta de ejemplo.