c# - rif - funcionario seniat gob ve iseniatlogin paginaprincipal do
¿Cómo debo obtener la clave y el vector de inicialización para mis entradas de base de datos cifradas AES? (1)
Creé un sistema CMS para permitir a los usuarios crear y administrar formularios en línea en la aplicación de intranet de mi cliente.
Por supuesto, algunos de los datos manejados por los formularios pueden necesitar ser encriptados, por ejemplo, si el sistema se usa para crear un formulario que maneje los detalles del salario o lo que sea. Así que estoy usando la clase AESManaged para encriptar simétricamente este tipo de datos antes de que AESManaged en nuestra aplicación db.
Todo está bien, pero ahora, antes del lanzamiento, podría hacerlo con un novato con respecto al shared secret y la salt .
Mi idea original era crear un shared secret (dinámico) al combinar el ID (basado en GUID) del Form contiene el campo cifrado con el id. (Nuevamente, basado en GUID) de la Question el campo es la respuesta a:
FormId:QuestionId
My Salt se genera actualmente de la misma manera, solo con el orden de Guids invertido, es decir.
QuestionID:FormID.
Soy nuevo en esto, ¿no estoy seguro si esta es una estrategia sensata o si debería hacerlo de otra manera?
La sal debe ser un valor generado aleatoriamente. Su propósito es hacer que los ataques de diccionario / fuerza bruta sean más difíciles de ejecutar. Wikipedia tiene un buen artículo sobre sales criptográficas: http://en.wikipedia.org/wiki/Salt_(cryptography )
Para el secreto compartido, idealmente, no sería un valor que se almacenó sin encriptar con los datos que estaba encriptando (como sus ID). En general, es una buena práctica que la clave sea elegida de alguna manera por el usuario final o el administrador para poder rotarla periódicamente o si se produce algún tipo de infracción de seguridad. Esta clave de contraseña podría ser propiedad de cada usuario del CMS o tal vez de una cuenta de administrador. Si tiene requisitos de seguridad muy serios, puede buscar un servidor de administración de claves de terceros.
Si el objetivo principal aquí es más de ofuscación y el CMS no estará sujeto a alguna forma de auditoría de seguridad, entonces algo similar a su idea inicial haría. Evitaría el acceso ocasional de los datos, pero probablemente no pasaría una auditoría en contra de los estándares formales que requerirían una sal aleatoria, una forma de rotar las claves, y una manera para que el "dueño" del sistema cambie la contraseña de tal manera que usted mismo no podría acceder a los datos.