Здравствуйте.

Возникла задача - изметить систему аутентификации на сайте. Раньше пароли в базе лежали в открытом виде, теперь будут в виде хешей с солью. Идея хорошая, но я вот задумался: а где соль то хранить? Просто в коде прописать? Это как то сомнительно звучит... Может кто нибудь посоветует хорошее решение? Надо принимать во внимание что физически работают 8 серверов под апачем + мод перл. Еще есть вебсервис и вебдав написанные на джаве - еще 2 машины. Очень хотелось бы нечто централизованное и безопасное. Подскажете?

храни рядом с хэшем в базе

Надеюсь это была шутка? 

вообще-то нет

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

Задача соли - затруднить перебор пароля по радужным таблицам. Если у вас что-то увели - считайте, что увели всё - и код, и базу. Так что это действительно не шутка.

Это сообщение отредактировал(а) DurRandir - 19.3.2013, 13:51

От чего же? База и код живут на разных машинах. Можно получить информацию из базы выполнив sql инъекцию (хоть вроде и нет такой возможности, но...). Код так просто не уведешь. Уведя базу, конкретно в моем случае, особого ущерба не будет. Самое главное в системе - это файлы. Они лежат на другой машине и доступны только с нескольких разрешенных айпи. Значит чтоб скачать чужой файл надо залогиниться этим пользователем и получить его через форму скачивания. Другого варианта нет. Допустим базу украли. Там хеши. Если совсем без соли то их считай что нет вовсе. Если они сделаны методом "md5hex($password.$salt)" то это немного надежнее но есть нюанс: теоретически можно подобрать строку совсем другую но дающую тот самый хеш. Таблицами или математически используя колизии. И с этой строкой логиниться. Тоже слабовато. Я собираюсь использовать вариант "md5hex(md5hex($password).$salt)". Тут уже без вариантов. Если и подобрать строку к украденному хешу то она бесполезна, ведь есть еще одно преобразование в цепочке.
Думаю теперь понятно почему соль в той самой базе - это плохо. У нас есть три секретных места:
1. База - там хеш
2. Код - там алгоритм формирования хеша
3. Некоторое третье место - там соль

Если же соль в базе то секретных мест становится 2 и надежность падает.

Можно по идее для хранения соли написать модуль на Си и подцепить его к перлу, саму соль хранить в этом модуле.

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


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


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

Проскакивала идея завести сервис генерации хеша во внутренней сети и через него логиниться. Отвергли как слишком сложное решение. Думаю для начала положу просто в конфиг. Если уж к нему получат доступ то и все прочее недалеко лежит. Но будем думать и над более интересными решениями.

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

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

наиболее важным мне видится
1. не использовать любимые пользователями простые и очевидные пароли 123, ДР и тп. предотвратить это трудно, но можно завуалировать манипуляциями с паролем/его хешем
2. не использовать очевидные (распространенные, опубликованные умельцами) способы соления
3. обеспечить защиту серверов, в т.ч. со стороны атак, использующих социальные аспекты


почему нет, чем это сложнее соединения к серверу бд?

Потому что для работы с базой уже все готово. А для этого сервиса придется запустить отдельную машину, на ней поднять веб сервер, написать сам сервис. Кроме того это будет самое одно узкое место всей системы. Если отвалится то все пропало - никто не залогиниться. Там сейчас даже sql серверов работает 2 штуки в кластере, для пущей надежности.

Может вам шелкод залили? Откуда вы знаете)


Это всё security through obscurity. Особенно со своим алгоритмом генерации, нагромождением md5 поверх md5 и прочее (особенно выбор md5+одна соль на все пароли, но зато спрятанная где-то далеко). 

Советую почитать http://stackoverflow.com/questions/401656/...r-php-passwords и далее по ссылкам: http://stackoverflow.com/questions/1581610...asswords-safely, http://www.codinghorror.com/blog/2007/09/y...ncorrectly.html. 

Знаю ) На сервере только один исполняемый файл: controller.pl . Никакой другой через апач не выполнишь.

А вам его через 0-day remote code execution в ядре залили. Или злой хакер стащил ключи с рабочего компа) Мало ли что - в теории защиты информации анализ исходит из того, что у злоумышленника есть вся информация о взламываемой системе, и надёжность защиты от этого страдать не должна.