Соленые пароли

-1

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

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

Идея, которая у меня есть, что я хотел бы запускать люди, - использовать «счастливое число» для создания соли из части хеша пароля. В принципе, наряду с выбором пароля пользователь выбирает «счастливое число». Затем это число будет использоваться в качестве начального индекса для извлечения соли из хеширования.

Таким образом, очень простой пример был бы таким.

Pass = "Password" 
Lucky Number = "4" 
Pass Hash = "00003gebdksjh2h4" 
Salt Length = "5" 
Resulting Salt = "3gebd"

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

источник

2015-02-09 sidjames

Это не добавило бы большей безопасности - самый подавляющий расчет на самом деле находит строковое сопоставление хэша. Ваши вычисления постоянны, что ничто по сравнению с этим. Достаточно иметь четкую (или практически отличную), но не тривиально простую («1», «2», ... и т. Д.) Соль для каждого хеша, который вы вычисляете. – lared

Спасибо за ответ. Это то, что я пытаюсь на самом деле опустить. Я думаю, если соль имеет фиксированную длину, то это всего лишь случай перехода через хэш, пока не найдете соль. Но что, если длина соли была переменной, основанной на «счастливом числе»? Будет ли это еще расчет по постоянному времени? – sidjames

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

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

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

источник

2015-02-09 22:31:27 lared

Соленые пароли

ответ

Смежные вопросы