¿Hay alguna razón para usar un valor cifrado para la clave de firma de texto simple?

-1

Estoy creando una API y estoy pensando en usar un valor cifrado de alguna contraseña aleatoria como el valor que se almacena para la representación de texto sin formato de mi clave de firma. ¿Es esto un intento vano de hacer que las cosas se vean seguras o hay algún beneficio para esto?

editar
 Es una clave de firma privada para un JWT. Algo que estaría almacenando en un archivo de propiedades o en otro lugar. La API proporciona funcionalidad para publicar datos en el servidor. Estoy preguntando específicamente si el uso de un hash bcrypt generado arbitrariamente proporciona algún beneficio para usar como valor de texto sin formato de mi clave de firma.

    
pregunta zero01alpha 05.02.2018 - 19:35
fuente

1 respuesta

1

Teniendo en cuenta sus respuestas a los comentarios, intentaré proporcionar una respuesta aquí.

Para su aclaración, OP tiene un servicio web que entrega los tokens web JSON firmados y está preocupado por la seguridad de su clave privada en el servidor. Preguntó OP, si la codificación es buena, la respuesta es no . Las codificaciones no proporcionan seguridad, ya que son reversibles sin una clave. Si un atacante obtiene acceso a su clave privada codificada, no hay nada que le impida decodificarla.

Además, OP preguntó si bcrypt es una forma segura de almacenar la clave privada. La respuesta también es no . bcrypt no es una función de codificación o encriptación, sino una función de hash criptográfica . Toma una entrada y genera un hash criptográfico salado seguro, que permite al servidor compararla con otras entradas y decidir si ambas son las mismas (es decir, que coinciden con la contraseña de un usuario al iniciar sesión, sin tener que almacenar la contraseña en texto sin formato ).

El hash de tu clave privada la deja inutilizable, ya que no se puede recuperar y el hash no se puede usar para firmar o descifrar ningún mensaje.

Tal vez pueda almacenar su clave privada en un archivo, solo legible por el usuario del servidor web (es decir, www-data, cuando use apache) o use otro. Sin embargo, si ni siquiera puede confiar en su propio servidor en esta extensión, tal vez ese sea el punto para comenzar a considerar más medidas de seguridad. Finalmente, debes confiar en algo .

Editar: el OP indica que solo el servidor está interesado en el propio JWT, lo que hace que la verificación de la firma por parte del usuario sea obsoleta. En este caso, el servidor puede generar un par de llaves solo para sí mismo, lo que parece una exageración, si el servidor de firma y verificación es siempre la misma máquina.

Teniendo en cuenta que tener un secreto es suficiente para OP, HMAC o una función hash basada en clave similar podría ser una mejor opción aquí. El servidor tiene una clave secreta, que se utiliza para crear un hash de JWT y verificarlo al recibir el token de un usuario. La manipulación es prevenida por esta técnica.

Un enfoque asimétrico podría ser mejor, si hay un solo servidor / (micro) servicio que cree esos tokens y otros puntos finales requieren que se verifiquen las firmas JWT. Una ventaja es que la "Fábrica de Token" puede ser una máquina / servicio aún mejor protegida, mientras que los puntos finales regulares solo necesitan la clave pública correspondiente, por lo que no se corta el par de llaves si se piratea.

    
respondido por el GxTruth 06.02.2018 - 14:53
fuente

Lea otras preguntas en las etiquetas