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

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

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

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

Есть ли рекомендуемые решения для этого?

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

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

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

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

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

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

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

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

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

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

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.

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