Перейти к содержанию

Использование слова в качестве соли

Описание

Иногда разработчики используют в качестве соли слово или фразу естественного языка. Это может быть набор байт, представляющий читаемое слово, например "password" или "saltValue". Такая практика представляет собой серьезную уязвимость, поскольку использование заранее известных слов делает соль предсказуемой, что значительно упрощает злоумышленникам возможность атаки на хешируемые данные.

Использование слов в качестве соли свидетельствует о том, что значение соли захардкожено в коде или ресурсах приложения и не вычисляется случайным образом. Это делает соль предсказуемой и дает возможность злоумышленникам использовать атаки с радужными таблицами и словарями, чтобы получить доступ к исходным данным.

Проблемы использования слов как соли

  1. Предсказуемость: Слова и фразы естественного языка легко поддаются угадыванию. Злоумышленник может легко предсказать или узнать используемую соль, если она не генерируется случайным образом, а представляет собой слово или фразу, что снижает уровень защиты.

  2. Повторение: Если разработчики используют одно и то же слово для соли в нескольких местах в приложении, это увеличивает риск, что одинаковые данные будут иметь одинаковый хеш, что значительно упрощает взлом.

  3. Низкая энтропия: Слова из естественного языка обладают низкой энтропией, что делает их менее устойчивыми к атакам по подбору и использованию радужных таблиц. Высокая энтропия, достигаемая за счет использования случайных и длинных значений, необходима для обеспечения безопасности хеширования.

Рекомендации

Чтобы избежать использования слов в качестве соли и обеспечить высокий уровень безопасности, следуйте следующим рекомендациям:

  1. Использование криптографически безопасных генераторов случайных чисел: Соль должна быть сгенерирована с использованием криптографически стойкого генератора случайных чисел, такого как SecureRandom. Это обеспечивает высокий уровень непредсказуемости и защищает от атак на основе радужных таблиц.

  2. Уникальность для каждого хеша: Каждое значение соли должно быть уникальным и генерироваться для каждого случая хеширования. Это предотвращает использование одного и того же значения для одинаковых данных, что делает систему более устойчивой к атакам.

  3. Длина соли: Рекомендуется использовать соль длиной не менее 16 байт. Это усложняет процесс подбора соли и делает использование радужных таблиц практически бесполезным.

Пример кода на Java для генерации безопасной соли

Ниже приведен пример, демонстрирующий правильное использование соли для хеширования:

import java.security.SecureRandom;

public class SecureSaltExample {
    public static byte[] generateSalt() {
        SecureRandom secureRandom = new SecureRandom();
        byte[] salt = new byte[16]; // Рекомендуемая длина соли - 16 байт или больше
        secureRandom.nextBytes(salt);
        return salt;
    }
}

В этом примере используется SecureRandom для генерации криптографически безопасной соли, которая является непредсказуемой и уникальной для каждой операции хеширования.

Ссылки

  1. https://www.baeldung.com/java-encryption-iv
  2. https://proandroiddev.com/secure-data-in-android-initialization-vector-6ca1c659762c
  3. https://medium.com/beautycoder/android-security-and-fingerprint-ef0f6f344888
  4. https://developer.android.com/training/articles/keystore
  5. https://medium.com/@josiassena/using-the-android-keystore-system-to-store-sensitive-information-3a56175a454b
  6. https://habr.com/ru/company/swordfish_security/blog/658433/
  7. https://habr.com/ru/company/swordfish_security/blog/664720/
  8. https://github.com/d0nutptr/Android-Security-Examples/blob/master/Cryptography/app/src/main/java/com/iismathwizard/cryptonote/Crypto.java
  9. https://github.com/flast101/padding-oracle-attack-explained/blob/master/oracle.py
  10. https://habr.com/ru/post/247527/?ysclid=l9wqtx7li4787340116
  11. https://en.wikipedia.org/wiki/Padding_oracle_attack
К началу