Значения хеширования и соления

Question

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

Прости мое невежество, но что именно это значит?

Я пишу приложение на Java. Поэтому я планирую сделать хэширование userID, имени Person и некоторого значения Math.random () в качестве соли с Apache Commons Digest Utils SHA512 и передачу этой хэшированной строки вместе с userID и именем человека.

Это стандартная практика? Я должен передать третьей стороне соль, а также правильно?

Answer 1

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

hash(password + salt)

или даже

hash(hash(password) + salt)

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

Один из вариантов - сначала отправить идентификатор пользователя на веб-сайт, затем дать ему возможность ответить солью, а затем отправить hash(password+salt)) обратно на сайт.

Answer 2

В Java вы можете сделать что-то вроде:

import org.apache.commons.codec.digest.DigestUtils;
import org.apache.commons.lang.RandomStringUtils;

/**
 * SHA1-hash the password with the user's salt.
 *
 * @param password
 */
public void setPassword(String password)
{
    if (password.equals(this.password))
    {
        return;
    }

    if (passwordSalt == null || passwordSalt.equals(""))
    {
        passwordSalt = RandomStringUtils.randomAscii(20);
    }

    this.password = DigestUtils.shaHex(password + passwordSalt);
}

/**
 * Check if a given password is correct.
 *
 * @param givenPassword
 * @return True is correct, else false.
 */
public boolean checkPassword(String givenPassword)
{
    return (password.equals(DigestUtils.shaHex(givenPassword + passwordSalt)));
}

Тогда пароль не читается, даже если хакер украл вашу БД.

Answer 3

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

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

Answer 4

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

Вы аутентифицируете пользователя в своей программе (кажется, что несколько ответов касаются этой проблемы, и да, вы должны хранить пароли своих пользователей в виде соленых хэшей, но это целая «другая проблема»), а затем, после аутентификации, Передача некоторой информации в это стороннее приложение. Теперь это зависит от того, что именно это приложение должно делать / знать. Например, если ему нужно знать идентификатор пользователя, вы не можете хэшировать / засолять его перед отправкой, потому что приложение никогда не сможет вернуть исходный идентификатор пользователя. С другой стороны, если приложению просто необходим какой-то идентификатор для распознавания запросов, а хеширование userID + userName - это просто предложение , то это имеет смысл, вы в основном генерируете уникальный для пользователя, но не декодируемая строка для использования сторонним приложением, в основном в качестве ключа сеанса.

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

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

Answer 5

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

Это не звучит правильно. Хеши являются односторонними операциями. Вы не можете взять результат хеша и предугадать простой текст из него

Что я планирую делать - это хэширование идентификатор пользователя, имя человека и некоторые Значение Math.random () в качестве соли

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

Использование SHA-256 или SHA-512 хорошо и это то, что NIST рекомендует

Answer 6

Весь смысл соли в том, чтобы совершать атаки с использованием так называемых «радужных таблиц» неосуществимых (с вероятностной точки зрения: если вы берете достаточно большой хеш, то фактически невозможно предварительно вычислить радужные таблицы).

http://en.wikipedia.org/wiki/Rainbow_table

Вместо того, чтобы просто делать хеш ( a ) и хранить хеш:

:460526e74fd6a25b525e642db2f756a4:

вы делаете хеш (соль +) и сохраняете хэш и соль (соль может быть выбрана случайным образом):

:cdd5bc3f05f6a76f6c82af728b2c555c:346884e6e35be: