¡Caminando hacia el éxito!

Aprende en Comunidad

Avalados por :

Otimização de armazenamento de senha secundária no IDM para conformidade e segurança

  • Creado 01/03/2024
  • Modificado 01/03/2024
  • 7 Vistas
0
Cargando...

Na nossa implementação de IDM, precisamos armazenar uma senha secundária que estamos usando em um processo de autenticação de dois fatores. Recriar o armazenamento desta senha no IDM é fácil, mas por razões de conformidade, precisamos garantir que a senha secundária não coincida com a senha regular existente no IDM.

Estou usando o framework de extensão para adicionar lógica Java inline no portal; se uma senha não atender às nossas regras de complexidade ou coincidir com a MX_ENCRYPTED_PASSWORD existente, o usuário receberá uma mensagem ao tentar salvar. No entanto, estou enfrentando um problema: as funções de criptografia Java comuns que criam criptografia 3Des estão retornando uma senha diferente da função uDesEncrypt dentro do IDM quando uma chave idêntica é usada.

Alguém já experimentou isso antes? Alguém sabe a maneira correta de chamar o objeto de criptografia Java para obter um resultado idêntico à função uDesEncrypt?

Obrigado,

Pete.

Pedro Pascal
Se unió el 07/03/2018
Pinterest
Telegram
Linkedin
Whatsapp

4 Respuestas

0
Cargando...

Bem, é impreciso - é apenas codificado em hexadecimal. A parte relevante codificada em hexadecimal é F700AD168253BC248497969EDB988620 - o 1: significa que foi criptografado pela KEY001 em keys.ini. Posso gerar a mesma sequência criptografada usando tanto uDESEncrypt quanto as classes javax.crypto, com algoritmo = "DESede", transformação = "DESede/CBC/PKCD5Padding". Recebo o resultado " 1:0653565108cc220e" de uDESEncrypt e "0653565108CC220E" do java.

Minha sugestão seria que você alterasse a KEY00x em keys.ini que acredita estar sendo usada, verifique se o DES3 gerado dentro do IDM muda, então use essa chave em hexadecimal com uma função rápida usando javax.crypto para garantir que esteja usando o mesmo método de geração e chaves. Um código java de exemplo que deve produzir os mesmos resultados que uDESEncrypt (sem a parte " 1:") é o seguinte.

String PLAIN_TEXT = "SEU TEXTO AQUI";

String SHARED_KEY = "SUA CHAVE AQUI"; // apenas os 48 caracteres hexadecimais

String algoritmo = "DESede";

String transformação = "DESede/CBC/PKCS5Padding";

byte[] keyValue = Hex.decodeHex(SHARED_KEY.toCharArray());

DESedeKeySpec keySpec = new DESedeKeySpec(keyValue);

IvParameterSpec iv = new IvParameterSpec(new byte[8]);

SecretKey key = SecretKeyFactory.getInstance(algoritmo).generateSecret(keySpec);

Cipher encrypter = Cipher.getInstance(transformação);

encrypter.init(Cipher.ENCRYPT_MODE, key, iv);

byte[] input = PLAIN_TEXT.getBytes("UTF-8");

byte[] encrypted = encrypter.doFinal(input);

System.out.println(new String(Hex.encodeHex(encrypted)).toUpperCase());

Editado por: Chris Foley em 1 de março de 2012 às 2:01 AM

Respondido el 15/04/2024
LUCIANO RIOJA GHIOTTO
Se unió el 13/07/2019
0
Cargando...

Algo que he notado y que puede suscitar alguna reflexión... la documentación de SAP menciona

el resultado está precedido por seguido por el número de clave utilizado en la encriptación. Luego los datos encriptados se almacenan como base64 . Sin embargo, al observar los datos, no parecen ser base64, ¿no terminan con un = por ejemplo? Aquí tienes un ejemplo de los datos que veo en IDM 1:F700AD168253BC248497969EDB988620

¿Alguien sabe si esa afirmación del documento es precisa?

Editado por: Pete Simms el 29 de febrero de 2012 a las 10:47 PM

Respondido el 15/04/2024
LUCIANO RIOJA GHIOTTO
Se unió el 13/07/2019
0
Cargando...

SIM, com certeza é a chave que o IDM está utilizando. Eu tentei várias opções ao passá-la para o objeto Java, como enviá-la como está, reduzir seu comprimento para corresponder à documentação do uDesEncrypt, também tentei convertê-la de uma cadeia hexadecimal para decimal e adicionar um prefixo com . Eu ficaria feliz se alguém pudesse me dizer como formatar a chave para obter o resultado correto, mas até agora todas as variações que tentei falharam.

Respondido el 15/04/2024
LUCIANO RIOJA GHIOTTO
Se unió el 13/07/2019
0
Cargando...

¿Estás seguro de que estás utilizando la misma clave exacta para la encriptación?

La clave debería estar en el archivo <directorio de instalación>\key\keys.ini

Pero otra cosa a tener en cuenta es que la clave en keys.ini es más larga de 24 caracteres (al menos en mi caso), lo cual debe ser (en el caso de Java) según la documentación de uDesEncrypt, por lo que esto podría causar problemas.

Respondido el 15/04/2024
LUCIANO RIOJA GHIOTTO
Se unió el 13/07/2019

contacto@primeinstitute.com

(+51) 1641 9379
(+57) 1489 6964

© 2024 Copyright. Todos los derechos reservados.

Desarrollado por Prime Institute

¡Hola! Soy Diana, asesora académica de Prime Institute, indícame en que curso estas interesado, saludos!
Hola ¿Puedo ayudarte?