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

Возникла задача - изметить систему аутентификации на сайте. Раньше пароли в базе лежали в открытом виде, теперь будут в виде хешей с солью. Идея хорошая, но я вот задумался: а где соль то хранить? Просто в коде прописать? Это как то сомнительно звучит... Может кто нибудь посоветует хорошее решение? Надо принимать во внимание что физически работают 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 в ядре залили. Или злой хакер стащил ключи с рабочего компа) Мало ли что - в теории защиты информации анализ исходит из того, что у злоумышленника есть вся информация о взламываемой системе, и надёжность защиты от этого страдать не должна.

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

Это сообщение отредактировал(а) baldina - 19.3.2013, 21:40

Неважный выбор. Сей алгоритм есть во многих программах-подборщиков. Лучше придумать что-то свое, нестандартное. Можно ориентироваться, например, на генератор хэшей на сайте insidepro.
В hashcat, например, есть (или была) опция подбора пароля к соленому хэшу по известному алгоритму, даже если нет самой соли. Если соль короткая, ее отсутствие в БД лишь отсрочит взлом.
PS. Юзайте нестандартные алгоритмы хэширования или криптования, какой-нить Blowfish или AES с достаточной длиной ключа.
PPS. Соль лучше всего хранить в солонке 

Это я уже понял. Теперь будет комбинация sha1+md5+еще кое что.



А перец? 

У меня в базе соль хранится рядом с самим хешем, генерация примерно такая  md5(md5(_filter($password)) . $salt);
По сути можно сделать примерно такую приблуду:

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

Двусоставная соль: "крупная" хранится в базе и "мелкая",- нигде не хранится. Её вводит пользователь каждый раз при авторизации. Протеряете и базу и код - без знания "мелкой" соли будут гораздо дольше подбирать. 

Мммм.... а 6 перл попробовать, скомпилить?