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

Question

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

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

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

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

Answer 1

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

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

Answer 2

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Answer 3

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

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

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

Answer 4

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

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

Answer 5

Смысл в том, чтобы сделать все радужные столы бесполезными и потребовать, чтобы их сделал новый набор. Чтобы угадать строку нужно столько же времени, сколько и для создания радуги. Например, хэш 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.

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