Где вы храните свои солевые струны?

Ответ 1

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

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

Ответ 2

Я представлю немного другое дело.

Я всегда храню соль, смешанную с хешем соленого пароля.

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

Мое обоснование для этого подхода:

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

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

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

Заключение к этому.

1) Никогда не храните данные, которые использует ваше приложение для проверки подлинности в его точной форме.

2) Если возможно, сохраните секретную логику аутентификации для дополнительной безопасности.

Перейти на один шаг дальше.

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

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

Например, вы генерируете случайную соль размером 512 байт. Вы добавляете соль к своему паролю и получаете хэш SHA-512 вашего соленого пароля. Вы также генерируете случайное целое число 200. Затем вы сохраняете первые 200 байт соли, за которым следует хэш-код соленой пароли, за которым следует остальная часть соли.

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

Преимущества такого подхода:

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

Недостатки этого подхода:

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

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

Этот подход может быть реализован различными способами и может быть еще более безопасным с использованием солей переменной ширины и/или соленых паролей.

Ответ 3

Часто они добавляются в хэш и сохраняются в одном поле.

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

Если у вас было более безопасное место хранения, было бы целесообразно просто хранить хеши.

Ответ 4

Основываясь на разработке веб-приложений ASP.NET MVC 4 от William Penberthy:

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