Хеширование и соление значений

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

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

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

:460526e74fd6a25b525e642db2f756a4:

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

:cdd5bc3f05f6a76f6c82af728b2c555c:346884e6e35be:

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

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

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

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

Использование SHA-256 или SHA-512 является нормальным и рекомендуется NIST

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

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

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

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

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

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

В 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)));
}

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