Цитата(baldina @ 19.3.2013, 12:07  ) |
| храни рядом с хэшем в базе |
Надеюсь это была шутка?
| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > Perl: разработка для Web > Где хранить соль? |
| Автор: infarch 19.3.2013, 10:56 |
| Здравствуйте. Возникла задача - изметить систему аутентификации на сайте. Раньше пароли в базе лежали в открытом виде, теперь будут в виде хешей с солью. Идея хорошая, но я вот задумался: а где соль то хранить? Просто в коде прописать? Это как то сомнительно звучит... Может кто нибудь посоветует хорошее решение? Надо принимать во внимание что физически работают 8 серверов под апачем + мод перл. Еще есть вебсервис и вебдав написанные на джаве - еще 2 машины. Очень хотелось бы нечто централизованное и безопасное. Подскажете? |
| Автор: baldina 19.3.2013, 12:07 |
| храни рядом с хэшем в базе |
| Автор: infarch 19.3.2013, 12:24 | ||
Надеюсь это была шутка? |
| Автор: baldina 19.3.2013, 13:31 |
| вообще-то нет |
| Автор: infarch 19.3.2013, 13:39 |
| Соль добавляет защиту хешей, в случае если базу данных увели. А вы предлагаете ее в ту самую базу положить. Это только облегчит жизнь злоумышленику. |
| Автор: DurRandir 19.3.2013, 13:50 |
| Задача соли - затруднить перебор пароля по радужным таблицам. Если у вас что-то увели - считайте, что увели всё - и код, и базу. Так что это действительно не шутка. |
| Автор: infarch 19.3.2013, 14:12 | ||
От чего же? База и код живут на разных машинах. Можно получить информацию из базы выполнив sql инъекцию (хоть вроде и нет такой возможности, но...). Код так просто не уведешь. Уведя базу, конкретно в моем случае, особого ущерба не будет. Самое главное в системе - это файлы. Они лежат на другой машине и доступны только с нескольких разрешенных айпи. Значит чтоб скачать чужой файл надо залогиниться этим пользователем и получить его через форму скачивания. Другого варианта нет. Допустим базу украли. Там хеши. Если совсем без соли то их считай что нет вовсе. Если они сделаны методом "md5hex($password.$salt)" то это немного надежнее но есть нюанс: теоретически можно подобрать строку совсем другую но дающую тот самый хеш. Таблицами или математически используя колизии. И с этой строкой логиниться. Тоже слабовато. Я собираюсь использовать вариант "md5hex(md5hex($password).$salt)". Тут уже без вариантов. Если и подобрать строку к украденному хешу то она бесполезна, ведь есть еще одно преобразование в цепочке. Думаю теперь понятно почему соль в той самой базе - это плохо. У нас есть три секретных места: 1. База - там хеш 2. Код - там алгоритм формирования хеша 3. Некоторое третье место - там соль Если же соль в базе то секретных мест становится 2 и надежность падает. |
| Автор: noize 19.3.2013, 14:35 |
| Можно по идее для хранения соли написать модуль на Си и подцепить его к перлу, саму соль хранить в этом модуле. |
| Автор: baldina 19.3.2013, 14:38 | ||||||
ну не настолько. пытаться подобрать пароли по одним хешам - малоприятное занятие, требующее генерации таблиц: это долго и места много занимает. ваша соль добавляет изрядную длину к паролю, что требует гораздо бОльших таблиц. факт наличия соли тут играет не такую значительную роль: сокращает время подбора, если точно знать, как применяется соль, но не кардинально. таблицы все-равно придется генерить.
это относится к любому хешированию, что бы вы там ни накручивали. собственно, подобрав пароль, никогда не знаешь точно - он или нет 
хороший способ  аргументы по хранению соли рядом те же: знание соли тут мало что даёт впрочем, подходя параноидально, можно хранить и отдельно: другая база например. имхо усложнение того не стоит, но ради спокойствия на что только не пойдешь... |
| Автор: infarch 19.3.2013, 14:50 |
| Проскакивала идея завести сервис генерации хеша во внутренней сети и через него логиниться. Отвергли как слишком сложное решение. Думаю для начала положу просто в конфиг. Если уж к нему получат доступ то и все прочее недалеко лежит. Но будем думать и над более интересными решениями. |
| Автор: baldina 19.3.2013, 15:53 | ||
| стойкость метода основана на длине шифруемого ключа (для коротких паролей можно взять готовые таблицы, несколько терабайт всего)), а так же неизвестности самого метода: злоумышленник не знает, что именно делается с паролем и солью. т.е. нестандартный подход повышает надежность. естественно, в предположении, что злоумышленник не получит одновременно вашу базу и алгоритм. в принципе соль можно вообще не хранить, а вычислять для каждого пароля - расширять пароль до определенной длины, используя символы пароля. это способ только для https: вы же не передаете пароль по сети открытым. - вычислять соль по символам первоначального хеша - вычислять соль, применяя альтернативный алгоритм хеширования (напр sha) можно использовать комбинацию явно хранимой соли и вычисления соли дополнительной. наиболее важным мне видится 1. не использовать любимые пользователями простые и очевидные пароли 123, ДР и тп. предотвратить это трудно, но можно завуалировать манипуляциями с паролем/его хешем 2. не использовать очевидные (распространенные, опубликованные умельцами) способы соления 3. обеспечить защиту серверов, в т.ч. со стороны атак, использующих социальные аспекты
почему нет, чем это сложнее соединения к серверу бд? |
| Автор: infarch 19.3.2013, 16:12 | ||
Потому что для работы с базой уже все готово. А для этого сервиса придется запустить отдельную машину, на ней поднять веб сервер, написать сам сервис. Кроме того это будет самое одно узкое место всей системы. Если отвалится то все пропало - никто не залогиниться. Там сейчас даже sql серверов работает 2 штуки в кластере, для пущей надежности. |
| Автор: DurRandir 19.3.2013, 16:42 | ||||
Может вам шелкод залили? Откуда вы знаете)
Это всё security through obscurity. Особенно со своим алгоритмом генерации, нагромождением md5 поверх md5 и прочее (особенно выбор md5+одна соль на все пароли, но зато спрятанная где-то далеко). Советую почитать http://stackoverflow.com/questions/401656/secure-hash-and-salt-for-php-passwords и далее по ссылкам: http://stackoverflow.com/questions/1581610/how-can-i-store-my-users-passwords-safely, http://www.codinghorror.com/blog/2007/09/youre-probably-storing-passwords-incorrectly.html. |
| Автор: infarch 19.3.2013, 17:18 | ||
Знаю ) На сервере только один исполняемый файл: controller.pl . Никакой другой через апач не выполнишь. |
| Автор: DurRandir 19.3.2013, 21:30 |
| А вам его через 0-day remote code execution в ядре залили. Или злой хакер стащил ключи с рабочего компа) Мало ли что - в теории защиты информации анализ исходит из того, что у злоумышленника есть вся информация о взламываемой системе, и надёжность защиты от этого страдать не должна. |
| Автор: baldina 19.3.2013, 21:39 | ||
это худший вариант для пессиместической оценки. злоумышленник может знать пароль от сейфа и иметь к нему физический доступ. какие способы защиты? правильно, ничего не хранить в сейфе. но тогда и сейф не нужен... часто так и происходит: проще и дешевле подкупить персонал непробиваемых защит не бывает. всегда речь идет о балансе стоимости информации, средств защиты и стоимости взлома |
| Автор: krypt3r 20.3.2013, 07:30 | ||
Неважный выбор. Сей алгоритм есть во многих программах-подборщиков. Лучше придумать что-то свое, нестандартное. Можно ориентироваться, например, на генератор хэшей на сайте insidepro. В hashcat, например, есть (или была) опция подбора пароля к соленому хэшу по известному алгоритму, даже если нет самой соли. Если соль короткая, ее отсутствие в БД лишь отсрочит взлом. PS. Юзайте нестандартные алгоритмы хэширования или криптования, какой-нить Blowfish или AES с достаточной длиной ключа. PPS. Соль лучше всего хранить в солонке  |
| Автор: infarch 20.3.2013, 10:44 | ||||
Это я уже понял. Теперь будет комбинация sha1+md5+еще кое что.
А перец? |
| Автор: warlock000 22.3.2013, 19:57 |
| У меня в базе соль хранится рядом с самим хешем, генерация примерно такая md5(md5(_filter($password)) . $salt); По сути можно сделать примерно такую приблуду: Привязку к айпи адресу и(или) подсети, для добавления доверенных айпи использовать СМС, ввёл код с СМСки добавил подсеть. Можно извратиться ещё больше, убрать или почти убрать авторизацию (есть пару нюансов) сделал проверку на айпишник если он доверенный то впускать в систему (буду проблемы с динамическими айпи, но можно сделать данное условие только для статики). Ну и уж если совсем защитится сделать токены или карты переменых кодов, аналогично как в банках и что хочет сделать гугл Что то я замечтался... |
| Автор: Сумасшедший 22.3.2013, 21:29 |
| Двусоставная соль: "крупная" хранится в базе и "мелкая",- нигде не хранится. Её вводит пользователь каждый раз при авторизации. Протеряете и базу и код - без знания "мелкой" соли будут гораздо дольше подбирать. |
| Автор: Marlik 1.5.2013, 11:43 |
| Мммм.... а 6 перл попробовать, скомпилить? |