Как работает шифрование паролей Maven 3?

Ответ 1

Мой ответ основан на чтении исходного кода Maven и небольшом исследовании.

• Предоставляет ли зашифрованный главный пароль безопасность только существующим в settings-security.xml в папке, доступ к которой может получить только один пользователь (~/.m2)? Если да, зачем беспокоиться об шифровании "главного пароля" (почему бы просто не использовать какое-то случайное значение)? Разве это не "главный пароль", а просто энтропийный ввод криптографической функции? Вызов пароля - запутанный - я ожидал, что Maven предложит мне этот пароль перед дешифрованием любых зашифрованных паролей сервера, но это не так.

Главный пароль - это вход в криптографическую функцию для шифрования/дешифрования паролей сервера. Если у кого-то есть ваши индивидуальные зашифрованные пароли сервера, они не смогут расшифровать их, если у них также нет вашего основного пароля. Это означает, что вы можете свободно делиться своим файлом maven settings.xml с другими, не имея возможности расшифровывать свои пароли сервера. Именно поэтому главный пароль хранится в отдельном файле.

Это объяснение несколько объяснено в руководстве по шифрованию

2. Используют ли пароль главного и пароли сервера один и тот же процесс шифрования/шифрования? Пароли сервера основаны на главном пароле, поэтому в алгоритме должна быть какая-то разница. Где находится исходный код для этого?

Из того, что я могу сказать, главный пароль зашифрован с использованием того же шифрования, что и пароли сервера. При расшифровке паролей сервера главный пароль (зашифрованная форма) является входом; при расшифровке главного пароля в качестве дополнительного ввода используется магическая строка "settings.security".

Вы можете увидеть исходный код PBECipher и MavenCli.java.

3. Я заметил, что один и тот же пароль главного сервера или сервера, зашифрованный несколько раз, дает разные хэши. В соответствии с ответом Марсело Моралес о том, как работает maven -encrypt-master-password, это связано с тем, что 64-разрядная конфигурация, специфичная для JVM-конфигурации (обычно SHA1PRNG) случайная соль "добавляется к паролю до шифрования. Maven расшифровывает сохраненные пароли, когда они используются во время компиляции. Разве это не означает, что соли нужно где-то хранить?

Традиционный подход к обработке солей заключается в том, что случайная соль хранится вместе с зашифрованным текстом. См. Статья в Википедии.

На основе исходного кода, связанного выше, соль, по-видимому, хранится в виде первых 8 байтов декодированных байтов Base64, прямо перед зашифрованным паролем.

4. Я также заметил, что обычный пароль, зашифрованный с использованием одного зашифрованного главного пароля, по-прежнему будет работать, если главный пароль будет заново зашифрован и сохранен в файле settings-security.xml, , даже если зашифрованный главный зашифрованный пароль пароля теперь отличается. Может кто-нибудь объяснить, как это работает?

Это связано с тем, что используется расшифрованная форма главного пароля, а не зашифрованный "зашифрованный текст". Таким образом, повторное шифрование не влияет на шифрование/дешифрование пароля сервера.

Я не знаю ответа на ваши последние два (5 и 6) вопросов.

Ответ 2

Мне нужно знать это для bnd (tools), чтобы я мог поделиться более глубоким анализом.

"Зашифрованные" пароли имеют синтаксис:

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>

Используемый шифр AES/CBC/PKCS5Padding. Секретный ключ и вектор инициализации вычисляются следующим образом:

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

Для главного пароля X "security.settings". Поскольку это хорошо известная константа, главный пароль не зашифрован, а только затенен. Для серверных паролей X является расшифрованным основным паролем.

Почему результирующий пакет заполняется, кажется пустой тратой байтов, так как формат пакета делает его тривиальным для полосы, и они никогда не являются частью шифрования/дешифрования. Они просто добавляют несколько случайных символов в строку base64.

Единственный способ, которым это полезно, - использовать средство перемещения. Например, если вы установили параметры-security.xml на частном монтировании на сервере сборки. Затем вы можете свободно делиться файлом settings.xml в публичных репозиториях. Тем не менее, это также очень привлекательное решение, так как вам нужно смонтировать его для одной и той же точки монтирования для всех ваших пользователей и серверов сборки CI.

Помните, что любой плагин может декодировать все ваши пароли сервера, поэтому никогда не используйте настоящие пароли для серверов. Nexus может создавать прокси-пароли.

Ответ 3

Вот пример кода, который показывает, как расшифровать главный пароль maven из

~/.m2/security-settings.xml

а также пароли сервера из

~/.m2/settings.xml

Источник 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);
    }
}

В GitHub также есть пример проекта:

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