Украшение HashMap добавлением случайности для предотвращения (D)DoS

Если для любой строки crunch(s) возвращает воспроизводимую строку, которую злоумышленник не может угадать, DDoS-атака успешно предотвращена, верно?

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

Быстрая и грязная реализация может выглядеть примерно так:

public class SaltedHashMap<V> {
    private final Map<String, V> map = new HashMap<>();
    private final String salt;
    public SaltedHashMap(String salt) {
        this.salt = salt;
    }
    public V get(String key){
        return map.get(key + salt);
    }
    public void put(String key, V value) {
        map.put(key + salt, value);
    }
}

Используя веб-сервер в качестве примера, мы могли бы использовать SecureRandom для рандомизации новой соли для каждого входящего запроса, а это означает, что даже если вам удалось вычислить ввод, генерирующий коллизии, для одного запроса, крайне маловероятно, что он сработает для другого. Запросы.

Альтернативная хэш-функция String, добавленная в 7u6, была удалена из JDK 8 вместе с системным свойством jdk.map.althashing.threshold. Вместо этого хеш-бины, содержащие большое количество конфликтующих ключей, повышают производительность, сохраняя их записи в сбалансированном дереве, а не в связанном списке. Это изменение JDK 8 применяется только к HashMap, LinkedHashMap и ConcurrentHashMap.

См.: https://docs.oracle.com/javase/8/docs/technotes/guides/collections/changes8.html

Я думаю, что к тому времени, когда он доберется до вашего кода (где вы могли бы внести вышеуказанные изменения), хеширование уже было выполнено базовыми библиотеками, обрабатывающими запрос POST. Так что нет, я не думаю, что это сработает.

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

// from java.lang.String
public int hashCode() {
    int h = hash;
    if (h == 0 && count > 0) {
        h = MY_STARTING_VALUE;
        int off = offset;
        char val[] = value;
        int len = count;

        for (int i = 0; i < len; i++) {
            h = MY_PRIME*h + val[off++];
        }
        hash = h;
    }
    return h;
}

Проблема в том, что некоторые библиотеки полагаются на конкретную реализацию hashCode. Если вы не используете такую ​​библиотеку, это гарантирует, что каждый фрагмент кода, использующий Strings, будет исправлен.

Проблема с использованием «crush» или seed заключается в том, что вам нужно знать его значение, чтобы выполнить поиск в первую очередь. Если вы используете случайное значение, вам нужно опросить все возможные ключи, чтобы получить значение, которое звучит не очень эффективно.

Если вы беспокоитесь о производительности в худшем случае, вы можете использовать TreeMap. Типичная и наихудшая производительность - O (log n) для выполнения вставки/поиска.

Если вы действительно беспокоитесь об этом, вы можете использовать класс String со своим собственным hashCode() или переопределить встроенный hashCode для String или значение, используемое HashMap.