security - sigma - zte z835 precio

¿Cómo funciona el cifrado de contraseña de Maven 3?

Question

Estoy tratando de entender la función de encriptación de contraseñas de Maven 3. He encontrado que esta característica está mal documentada y confusa. Por ejemplo, la documentación de la característica y una publicación en el blog del autor de la característica se contradicen entre sí sobre varios puntos.

Esta pregunta es más amplia que ¿Cómo funciona maven --encrypt-master-password y no está cubierta por la buena práctica de Maven encrypt-master-password para elegir una contraseña ?

Específicamente, estoy tratando de responder las siguientes preguntas que no están cubiertas por la documentación. He puesto la información que he podido reunir hasta ahora debajo de cada pregunta en cursiva.

1. ¿La contraseña maestra cifrada proporciona seguridad simplemente al existir en settings-security.xml en una carpeta a la que solo puede acceder un usuario ( ~/.m2 )? Si es así, ¿por qué molestarse en cifrar una ''contraseña maestra'' (por qué no usar solo un valor aleatorio)? ¿No es la ''contraseña maestra'' realmente solo una entrada de entropía a la función criptográfica? Llamarlo con una contraseña es confuso: esperaba que Maven me pidiera esta contraseña antes de descifrar las contraseñas cifradas del servidor, pero no lo hizo.

Mi entendimiento es que sí, esto solo proporciona seguridad al existir en un archivo protegido del sistema operativo. Creo que Maven le permite cifrar una contraseña maestra para que, si pierde el archivo settings-security.xml , pueda volver a generarla. ¿Es esto correcto?

2. ¿La contraseña maestra y las contraseñas del servidor utilizan el mismo proceso de cifrado / cifrado? Las contraseñas del servidor se basan en la contraseña maestra, por lo que debe haber alguna diferencia en el algoritmo. ¿Dónde está ubicado el código fuente de esto?

La respuesta de Marcelo Morales sobre Cómo funciona maven --encrypt-master-password se vincula al proyecto plexus-cihper en GitHub . No está claro si es solo el cifrado, o el complemento Maven real que proporciona la funcionalidad de contraseña.

3. He observado que la misma contraseña maestra o contraseña del servidor cifrada varias veces genera hashes diferentes. De acuerdo con la respuesta de Marcelo Morales sobre ¿Cómo funciona maven --encrypt-master-password , esto se debe a que ''una sal aleatoria de 64 bits específica de JVM (generalmente SHA1PRNG)'' se agrega a la contraseña antes del cifrado. Maven descifra las contraseñas almacenadas cuando se usan en tiempo de compilación. ¿No significa esto que las sales tienen que ser almacenadas en algún lugar?

No tengo ni idea

4. También he observado que una contraseña normal cifrada utilizando una contraseña maestra cifrada funcionará si la contraseña maestra se vuelve a cifrar y se almacena en el archivo settings-security.xml , aunque el texto cifrado de la contraseña maestra cifrada ahora sea diferente . ¿Alguien puede explicar cómo funciona esto?

No tengo idea. Esto me parece que Maven está haciendo algo sospechoso o almacenando texto claro en algún lugar.

5. Según tengo entendido, las contraseñas cifradas solo se pueden usar con etiquetas <server /> en el archivo settings.xml . ¿Es esto cierto? ¿Dónde se pueden usar los servidores definidos en settings.xml ?

Tengo entendido que las definiciones de <server /> se pueden usar en <repositories /> y <distributionManagement /> , pero no en <scm /> . ¿Alguien puede verificar esto?

6. Para una característica tan crítica (construir seguridad del sistema) me parece que hay mucha confusión y poca documentación. ¿Alguien puede indicar cómo funciona la documentación en el sitio web de Maven 3? ¿Hay algún enlace wiki en algún lugar que me permita probar y mejorar la documentación?

no tengo idea

Lo siento por la pared de texto, y gracias por cualquier respuesta.

Answer 1

Aquí hay un código de ejemplo que muestra cómo descifrar la contraseña maestra de Maven de

~/.m2/security-settings.xml

y también las contraseñas del servidor de

~/.m2/settings.xml

Fuente de MavenPasswordDecryptor.java

import org.sonatype.plexus.components.cipher.DefaultPlexusCipher;
public class MavenPasswordDecryptor {
public static void main(String[] args) throws Exception {
if (args.length < 1 || args.length > 2 ) {
System.out.println("Usage: java -jar maven-password-decryptor.jar <encrypted-password>");
System.out.println("Usage: java -jar maven-password-decryptor.jar <encrypted-password> <master-password>");
return;
}
DefaultPlexusCipher cipher = new DefaultPlexusCipher();
String encryptedPassword = args[0];
String passPhrase = (args.length == 2 && args[1] != null && !args[1].isEmpty()) ? args[1] : "settings.security";
String result = cipher.decryptDecorated(encryptedPassword, passPhrase);
System.out.println(result);
}
}

También hay un proyecto de ejemplo en GitHub:

https://github.com/uweguenther/maven-password-decryptor

Answer 2

Mi respuesta se basa en leer el código fuente de Maven y hacer una pequeña investigación.

1. ¿La contraseña maestra cifrada proporciona seguridad simplemente al existir en settings-security.xml en una carpeta a la que solo puede acceder un usuario ( ~/.m2 )? Si es así, ¿por qué molestarse en cifrar una ''contraseña maestra'' (por qué no usar solo un valor aleatorio)? ¿No es la ''contraseña maestra'' realmente solo una entrada de entropía a la función criptográfica? Llamarlo con una contraseña es confuso: esperaba que Maven me pidiera esta contraseña antes de descifrar las contraseñas cifradas del servidor, pero no lo hizo.

La contraseña maestra es una entrada en la función criptográfica para cifrar / descifrar las contraseñas del servidor. Si alguien tiene sus contraseñas de servidor cifradas individuales, no podrán descifrarlas a menos que también tengan su contraseña maestra. Esto significa que puede compartir libremente su archivo maven settings.xml con otros, sin que ellos puedan descifrar las contraseñas de su servidor. Esta es también la razón por la cual la contraseña maestra se guarda en un archivo separado.

Este razonamiento se explica de alguna manera en la guía de encriptación.

2. ¿La contraseña maestra y las contraseñas del servidor utilizan el mismo proceso de cifrado / cifrado? Las contraseñas del servidor se basan en la contraseña maestra, por lo que debe haber alguna diferencia en el algoritmo. ¿Dónde está ubicado el código fuente de esto?

Por lo que puedo decir, la contraseña maestra se cifra con el mismo cifrado que las contraseñas del servidor. Al descifrar las contraseñas del servidor, la contraseña maestra (forma encriptada) es una entrada; al descifrar la contraseña maestra, la cadena mágica ''"settings.security"'' se usa como entrada adicional.

Puede ver el código fuente PBECipher y MavenCli.java .

3. He observado que la misma contraseña maestra o contraseña del servidor cifrada varias veces genera hashes diferentes. De acuerdo con la respuesta de Marcelo Morales sobre ¿Cómo funciona maven --encrypt-master-password , esto se debe a que ''una sal aleatoria de 64 bits específica de JVM (generalmente SHA1PRNG)'' se agrega a la contraseña antes del cifrado. Maven descifra las contraseñas almacenadas cuando se usan en tiempo de compilación. ¿No significa esto que las sales tienen que ser almacenadas en algún lugar?

Un enfoque tradicional para manejar las sales es que la sal aleatoria se almacena junto con el texto cifrado. Vea el artículo de Wikipedia .

Según el código fuente vinculado anteriormente, la sal parece estar almacenada como los primeros 8 bytes de los bytes descodificados de Base64, justo antes de la contraseña cifrada.

4. También he observado que una contraseña normal cifrada utilizando una contraseña maestra cifrada funcionará si la contraseña maestra se vuelve a cifrar y se almacena en el archivo settings-security.xml , aunque el texto cifrado de la contraseña maestra cifrada ahora sea diferente . ¿Alguien puede explicar cómo funciona esto?

Esto se debe a que se utiliza la forma descifrada de la contraseña maestra, no el "texto cifrado" cifrado. Por lo tanto, volver a cifrarlo no afecta al cifrado / descifrado de la contraseña del servidor.

No sé la respuesta a sus últimas dos (5 y 6) preguntas.

Answer 3

Necesito saber esto para bnd (herramientas) para poder compartir un análisis más profundo.

Las contraseñas ''encriptadas'' tienen una sintaxis de:

output ::= ''{'' base64(packet) ''}''
packet ::= salt[8] padlen[1] encrypted[?] padding[padlen]
salt ::= <random>
padlen ::= <length of padding >
padding ::= <random to make packet length a multiple of 16>

El cifrado utilizado es AES/CBC/PKCS5Padding . La clave secreta y el vector de inicialización se calculan de la siguiente manera:

sha = sha256( X + salt[8] )
key = sha[0..16]
iv = sha[16..32]

Para la contraseña maestra X es "security.settings". Dado que esta es una constante conocida, la contraseña maestra no está cifrada sino que solo está oculta. Para las contraseñas del servidor X es la contraseña maestra decodificada.

Por qué el paquete resultante se rellena parece un desperdicio de bytes, ya que el formato del paquete hace que sea fácil de eliminar y nunca forman parte del cifrado / descifrado. Simplemente agregan algunos caracteres aleatorios a la cadena base64.

La única forma en que esto es útil es usando la facilidad de reubicación. Por ejemplo, si monta el archivo settings-security.xml en un montaje privado en el servidor de compilación. Luego puede compartir libremente el archivo settings.xml en repositorios públicos. Sin embargo, esta también es una solución sucia, ya que necesita montarlo en el mismo punto de montaje para todos sus usuarios y servidores de compilación de CI.

Tenga en cuenta que cualquier complemento puede decodificar todas las contraseñas de su servidor, así que nunca use contraseñas reales para los servidores. Nexus puede crear contraseñas de proxy.