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

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

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

Я поделюсь с вами несколько иначе.

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

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

Мое обоснование такого подхода:

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

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

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

Вывод к этому ..

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

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

Сделайте еще один шаг…

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

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

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

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

Плюсы этого подхода:

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

Минусы этого подхода:

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

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

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

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

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

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

На основе книги Уильяма Пенберти «Разработка веб-приложений ASP.NET MVC 4»:

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

Суть проблемы в том, чтобы сделать все радужные таблицы бесполезными и потребовать создания нового набора из них. Чтобы угадать строку, нужно столько же времени, сколько и составить радужную таблицу. Например, хэш SHA-256 для «пароля» равен 5e88 4898 da28 0471 51d0 e56f 8dc6 2927 7360 3d0d 6aab bdd6 2a11 ef72 1d15 42d8. После добавления соли, такой как «badpassword», новая строка для хеширования будет «passwordbadpassword», которая из-за эффекта лавины резко изменит вывод на 457b f8b5 37f1 802e f9c8 2e46 b8d3 f8b5 721b 7cbb d485 f0bb e523 bfbe 73e6 58d6.

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

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

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

 userPassword + salt

и мы передаем это нашему алгоритму хеширования.

 hash(userPassword+salt)

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

Теперь значение соли добавляется к значению хеширования, потому что оно снова используется при входе пользователя в систему для сравнения переданных учетных данных с сохраненными учетными данными.

 hash(userPassword+salt)=ashdjdaskhfjdkhfjdashadslkhfdsdh

вот как этот пароль хранится в db: ashdjdaskhfjdkhfjdashadslkhfdsdh.salt

Теперь, если злонамеренный пользователь увидит это, он сможет вычислить пароль, но это займет уйму времени. Потому что у каждого пароля будет своя соль. У Let's malware есть таблица из 5000 распространенных паролей и их хеш.

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

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

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

С солью из 10 символов и фиксированным размером хэша в 40 символов это будет выглядеть так:

salt = "california"
passwd = "wp8tJ4Pr"

stored_passwd = salt + hash(passwd + salt)

salt = substr(stored_passwd, 0, 10)
hashed_passwd = substr(stored_passwd, 10, 40)

if hash(user_input + salt) == hashed_passwd:
    print "password is verified"

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