Son OAuth2 y SSL suficientes para asegurar una API

Question

Estoy tratando de encontrar la mejor manera de asegurar una API. Solo permito SSL y estoy usando OAuth2 para la autenticación, pero eso no parece suficiente.

La principal preocupación que tengo es que cualquier persona podría inspeccionar las solicitudes realizadas por un cliente legítimo a la API y robar el OAuth client_id. En ese punto, podrán construir cualquier solicitud que deseen para suplantar al cliente legítimo.

¿Hay alguna forma de evitar esto? He visto personas usar un hash HMAC de los parámetros usando una clave secreta conocida solo por el cliente y el servidor, pero veo 2 problemas con eso.

1. Es muy difícil (¿imposible?) Evitar que un usuario malintencionado decompile a su cliente y descubra la clave secreta.
2. Algunos parámetros parecen extraños para hacer un hash HMAC de. Por ejemplo, si un parámetro era bytes de un archivo, ¿incluye todo en su hash HMAC?

Answer 1

Puede implementar SSL mutuamente autenticado entre sus clientes legítimos y su API. Genere un certificado de cliente SSL autofirmado y almacénelo dentro de su cliente. Configure su servidor para que requiera autenticación del lado del cliente y solo acepte los certificados que ha implementado para sus clientes. Si alguien/algo que intenta conectarse no tiene ese certificado de cliente, no podrá establecer una sesión SSL y la conexión no se realizará. Suponiendo que controle los clientes legítimos y los servidores, no necesita un certificado emitido por CA aquí; solo use certificados autofirmados ya que controla tanto la confianza del certificado del lado del cliente como la del lado del servidor.

Ahora, usted dice que es realmente difícil evitar que alguien realice ingeniería inversa en su cliente y recupere su credencial (la clave privada que pertenece al certificado del cliente, en este caso). Y tienes razón Normalmente almacenará esa clave (y el certificado) en un almacén de claves de algún tipo (un KeyStore si está usando Android) y ese almacén de claves se cifrará. Esa encriptación se basa en una contraseña, por lo que deberá (1) almacenar esa contraseña en su cliente en alguna parte, o (2) pedirle al usuario la contraseña cuando inicie su aplicación cliente. Lo que debe hacer depende de su uso. Si (2) es aceptable, entonces ha protegido su credencial contra la ingeniería inversa, ya que será encriptada y la contraseña no se almacenará en ningún lugar (pero el usuario deberá ingresarla cada vez). Si lo hace (1), alguien podrá realizar una ingeniería inversa de su cliente, obtener la contraseña, obtener el almacén de claves, descifrar la clave privada y el certificado, y crear otro cliente que pueda conectarse al servidor.

No hay nada que pueda hacer para evitar esto; puede hacer que la ingeniería inversa sea más difícil para su código (por ofuscación, etc.) pero no puede hacerlo imposible.Debe determinar cuál es el riesgo que está tratando de mitigar con estos enfoques y cuánto trabajo vale la pena para mitigarlo.

Answer 2

¿Está ejecutando el paso de autenticación OAuth sobre SSL? Eso evita todo tipo de fisgoneo, aunque significa que tendrá que tener cuidado de mantener actualizado el certificado de su servidor OAuth. (Tenga en cuenta, el servidor de OAuth puede tener una identidad SSL pública; aún así es imposible de falsificar con cantidades incluso vagamente razonable de esfuerzo Es sólo la clave privada que tiene que ser secreto guardado..)

Dicho esto, Debes ser más cuidadoso con lo que estás protegiendo. ¿Por qué la gente tiene que usar su código de cliente? ¿Por qué tiene que ser "secreto"? Es más fácil dar eso y poner la inteligencia (incluida la verificación de la identidad de inicio de sesión) en su servidor. Si alguien quiere escribir su propio cliente, déjalos. Si alguien quiere agitar su cuenta en público de una manera estúpida, cámbieles los costos que incurren por su insensatez ...