Шифрование SHA — действительно ли нужны соли?

Я использую Jquery SHA512.js для отправки шифрования и отправки имени пользователя и пароля на сервер. На сервере я делаю следующее, чтобы создать ХЭШ, хранящийся в БД:

$dbhash = = хеш('sha256',(хеш('sha512',$user). хэш('sha256',$extremesalt)));

Это все работает нормально.

Мой вопрос: какое значение имеет соль? В тот момент, когда соль применяется к паролю, пароль уже находится на сервере и не передается через Интернет. Также соль хранится рядом с хешем пароля.

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

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

Еще один вопрос - можно ли применить соль из браузера на сервер. Я предполагаю, что нет, или, по крайней мере, если бы вы это сделали, это было бы видно, если бы кто-то проверил источник (например: по моей причине, видимой в jquery). Таким образом, никакой реальной ценности.

спасибо


php jquery sha256
person Adam    schedule 09.08.2011    source источник

Ответы (4)


arrow_upward
4
arrow_downward

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

При втором взгляде я вижу, что вы используете 2 хэша один за другим 256, а затем 512. Это плохая идея, используйте один и придерживайтесь его. Вы тратите время на вычисление нескольких хэшей.

person Jesus Ramos    schedule 09.08.2011
comment
Я +1 ваш ответ за первый абзац. 2-й абзац может быть неправильным в будущем. См. мой комментарий к Марку Б. - person Heath Hunnicutt; 10.08.2011
comment
@Марк, да, я действительно читал эту газету пару недель назад, это довольно интересно. Хотя существуют методы хеширования хэша, которые, хотя и имеют такой эффект, упрощают фактический поиск исходной строки. У меня где-то была другая статья, в которой это показывалось, но сейчас я не могу ее найти. - person Jesus Ramos; 10.08.2011

arrow_upward
2
arrow_downward

Смешивать такие хэши довольно бессмысленно. Взяв хэш sha512 и пропустив его через sha256, вы обязательно сократите пространство ключей вдвое, так что все, что вы сделали, это потратили процессорное время и удвоили вероятность столкновения. Шансы по-прежнему будут исчезающе малы/микроскопичны, но это все же следует учитывать.

Соль здесь как механизм, прикрывающий задницу. Если по какой-то причине ваша база данных будет просачиваться (например, файл дампа «потерян»), было бы тривиально создать радужную таблицу общих паролей sha256/512 и посмотреть, есть ли совпадения в вашей таблице. Хэш нужен для того, чтобы значительно удорожить создание радужной таблицы. например «пароль» легко вычислить и проверить. «пароль#^$@#%#^Y#@#$@#^%$^Y%%$» гораздо менее вероятно будет радужным.

person Marc B    schedule 09.08.2011
comment
Использование соли также защищает вас от восстановления общих паролей из хэшей... возьмем, например, поищите в Google хэш md5 приветствия - person Chris Farmiloe; 10.08.2011
comment
@Chris: это из-за радужного стола. Сам md5 не нарушен тем, что вы можете получить исходную строку из хэша, но теперь довольно просто вычислить/организовать коллизии, чтобы найти строку, которая ДЕЙСТВИТЕЛЬНО хэширует до того же значения. Соль не защищает от столкновений, особенно организованных. - person Marc B; 10.08.2011
comment
@MarcB - из-за функций расширения сообщений SHA-2 запуск вывода SHA-2 (512) через SHA-2 (256) может повысить устойчивость к вычислению коллизий с помощью линейных приближений - см. Sanadhya и Sarkar для ссылок и информации. Сложность с точки зрения выполняемых операций SHA-256 аналогична SHA-512 — например, функция малой сигмы-1 имеет 3 поворота и сдвиг XORd вместе. SHA-512 не имеет, например, 6 вращений и 2 сдвига, он просто имеет вращение, которое больше, потому что регистры SHA-512 больше. - person Heath Hunnicutt; 10.08.2011

arrow_upward
0
arrow_downward

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

person jfriend00    schedule 09.08.2011

arrow_upward
0
arrow_downward 

$dbhash = = hash('sha256',(hash('sha512',$user) . hash('sha256',$extremesalt)));

Должно быть (нет необходимости в двойном хешировании)

$dbhash = = hash('sha512',$pass + $salt);

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

person Yavor Shahpasov    schedule 09.08.2011