¿Usando AES CBC PKCS5PADDING para la API REST?

No está claro contra qué estás tratando de protegerte, pero en cualquier caso estás haciendo algo mal.

¿Está intentando evitar que un atacante MitM intercepte el tráfico de usuarios legítimos? Simplemente use TLS (HTTPS). En serio, es el respuesta correcta para este escenario. Siempre que utilices cifrados y bibliotecas modernas (en ambos extremos), estarás seguro contra casi cualquier atacante concebible (y mucho menos probable). Si desea ser extremadamente cuidadoso, fije la información del certificado o clave pública de su servidor (o su CA, en algún nivel de la cadena) para que incluso una CA comprometida o malintencionada no permita que alguien rompa el canal de comunicación. / p>

¿Está intentando usar esto como algún tipo de mecanismo de autenticación? El uso de crypto para establecer que ambos extremos de la comunicación conocen una clave compartida y, por lo tanto, establecer la identidad del cliente es viable idea para una API RESTful (AWS, por ejemplo, hace esto con su esquema SigV4 ). Sin embargo, para hacer eso, necesita usar una forma autenticada de criptografía. Cipher Block Chaining (CBC) no proporciona ninguna autenticación; un atacante que conoce parte del texto simple para un mensaje protegido solo por AES (o cualquier otro cifrado de bloque) en modo CBC puede manipular el texto cifrado para producir un cambio confiable en el texto simple, y ni la víctima ni El servidor lo sabrá. Puede observar que SigV4 no realiza ningún cifrado (solo HMACs, una forma de firma criptográfica de clave simétrica); no proporciona ninguna confidencialidad (HTTPS hace eso), solo autenticidad (asegurando que el mensaje provenga de la fuente real y que no haya sido manipulado) vuelo). Puede solucionar este problema utilizando un modo de operación de cifrado autenticado (como GCM), o utilizando firmas asimétricas (¡pero entonces también puede usar TLS mutuo!), O adoptar un esquema como SigV4 (o simplemente adoptarlo directamente). .), pero su esquema actual no funcionaría.

¿Estás tratando de evitar que las personas descubran cómo escribir clientes de terceros para tu API? No puedes evitar eso. No te molestes en intentarlo. Ya sea al analizar el tráfico de red, realizar ingeniería inversa de sus binarios o alguna otra vía, no puede evitar que las personas encuentren una clave que tenga para proporcionar a sus usuarios. Los mejores intentos (en términos de conocimientos técnicos y de ingeniería aplicados) son los sistemas DRM comerciales que "protegen" cosas como películas y software comercial, y aún están rotos (a veces con una facilidad hilarante). De hecho, es fundamentalmente imposible evitar que se rompan; lo mejor que puede esperar es ocultar la clave, y la oscuridad es no la seguridad.

Con respecto a la segunda pregunta: si el atacante conoce un par de texto plano + texto encriptado, puede hacer una fuerza bruta en la frase de contraseña si es fácil de adivinar. Se puede proporcionar cierto nivel de protección contra eso mediante el uso de una función de derivación de clave basada en contraseña ( PBKDF2 , Scrypt , etc.), que le permitirá usar una frase de contraseña de cualquier longitud y hacer que la fuerza bruta sea mucho más lenta.

Con respecto a la primera pregunta: no estoy seguro de que tal cifrado lo haga mucho más seguro que solo https. Al menos considere usar algún tipo de MAC / cifrado autenticado para proteger contra MITM, ya que CBC no protege contra la modificación de mensajes (es fácil para el atacante modificar (xor) el primer bloque de texto sin formato sin saber la clave, por ejemplo).