Где хранить соль?

 
0
 
Perl
ava
infarch | 19.03.2013, 11:56
Здравствуйте.

Возникла задача - изметить систему аутентификации на сайте. Раньше пароли в базе лежали в открытом виде, теперь будут в виде хешей с солью. Идея хорошая, но я вот задумался: а где соль то хранить? Просто в коде прописать? Это как то сомнительно звучит... Может кто нибудь посоветует хорошее решение? Надо принимать во внимание что физически работают 8 серверов под апачем + мод перл. Еще есть вебсервис и вебдав написанные на джаве - еще 2 машины. Очень хотелось бы нечто централизованное и безопасное. Подскажете?
Comments (20)
ava
baldina | 19.03.2013, 12:07 #
храни рядом с хэшем в базе
ava
infarch | 19.03.2013, 12:24 #
Цитата (baldina @  19.3.2013,  12:07 findReferencedText)
храни рядом с хэшем в базе


Надеюсь это была шутка? smile
ava
baldina | 19.03.2013, 13:31 #
вообще-то нет
ava
infarch | 19.03.2013, 13:39 #
Соль добавляет защиту хешей, в случае если базу данных увели. А вы предлагаете ее в ту самую базу положить. Это только облегчит жизнь злоумышленику.
ava
DurRandir | 19.03.2013, 13:50 #
Задача соли - затруднить перебор пароля по радужным таблицам. Если у вас что-то увели - считайте, что увели всё - и код, и базу.
ava
infarch | 19.03.2013, 14:12 #
Цитата (DurRandir @  19.3.2013,  13:50 findReferencedText)
Если у вас что-то увели - считайте, что увели всё - и код, и базу


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

Если же соль в базе то секретных мест становится 2 и надежность падает.
ava
noize | 19.03.2013, 14:35 #
Можно по идее для хранения соли написать модуль на Си и подцепить его к перлу, саму соль хранить в этом модуле.
ava
baldina | 19.03.2013, 14:38 #
Цитата (infarch @  19.3.2013,  14:12 findReferencedText)
 Допустим базу украли. Там хеши. Если совсем без соли то их считай что нет вовсе.

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

Цитата (infarch @  19.3.2013,  14:12 findReferencedText)
теоретически можно подобрать строку совсем другую но дающую тот самый хеш

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

Цитата (infarch @  19.3.2013,  14:12 findReferencedText)
md5hex(md5hex($password).$salt)

хороший способ smile
аргументы по хранению соли рядом те же: знание соли тут мало что даёт
впрочем, подходя параноидально, можно хранить и отдельно: другая база например. имхо усложнение того не стоит, но ради спокойствия на что только не пойдешь...
ava
infarch | 19.03.2013, 14:50 #
Проскакивала идея завести сервис генерации хеша во внутренней сети и через него логиниться. Отвергли как слишком сложное решение. Думаю для начала положу просто в конфиг. Если уж к нему получат доступ то и все прочее недалеко лежит. Но будем думать и над более интересными решениями.
ava
baldina | 19.03.2013, 15:53 #
стойкость метода основана на длине шифруемого ключа (для коротких паролей можно взять готовые таблицы, несколько терабайт всего)),
а так же неизвестности самого метода: злоумышленник не знает, что именно делается с паролем и солью.
т.е. нестандартный подход повышает надежность. естественно, в предположении, что злоумышленник не получит одновременно вашу базу и алгоритм.
в принципе соль можно вообще не хранить, а вычислять для каждого пароля
- расширять пароль до определенной длины, используя символы пароля. это способ только для https: вы же не передаете пароль по сети открытым.
- вычислять соль по символам первоначального хеша
- вычислять соль, применяя альтернативный алгоритм хеширования (напр sha)

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

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

Цитата (infarch @  19.3.2013,  14:50 findReferencedText)
Проскакивала идея завести сервис генерации хеша во внутренней сети и через него логиниться. Отвергли как слишком сложное решение.

почему нет, чем это сложнее соединения к серверу бд?
ava
infarch | 19.03.2013, 16:12 #
Цитата (baldina @  19.3.2013,  15:53 findReferencedText)
почему нет, чем это сложнее соединения к серверу бд? 


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


От чего же? База и код живут на разных машинах. Можно получить информацию из базы выполнив sql инъекцию (хоть вроде и нет такой возможности, но...). Код так просто не уведешь.


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

Цитата
У нас есть три секретных места

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

Советую почитать http://stackoverflow.com/questions/401656/...r-php-passwords и далее по ссылкам: http://stackoverflow.com/questions/1581610...asswords-safelyhttp://www.codinghorror.com/blog/2007/09/y...ncorrectly.html
ava
infarch | 19.03.2013, 17:18 #
Цитата (DurRandir @  19.3.2013,  16:42 findReferencedText)
Может вам шелкод залили? Откуда вы знаете)


Знаю ) На сервере только один исполняемый файл: controller.pl . Никакой другой через апач не выполнишь.
ava
DurRandir | 19.03.2013, 21:30 #
А вам его через 0-day remote code execution в ядре залили. Или злой хакер стащил ключи с рабочего компа) Мало ли что - в теории защиты информации анализ исходит из того, что у злоумышленника есть вся информация о взламываемой системе, и надёжность защиты от этого страдать не должна.
ava
baldina | 19.03.2013, 21:39 #
Цитата (DurRandir @  19.3.2013,  21:30 findReferencedText)
у злоумышленника есть вся информация о взламываемой системе

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

часто так и происходит: проще и дешевле подкупить персонал

непробиваемых защит не бывает. всегда речь идет о балансе стоимости информации, средств защиты и стоимости взлома
ava
krypt3r | 20.03.2013, 07:30 #
Цитата
md5hex(md5hex($password).$salt)

Неважный выбор. Сей алгоритм есть во многих программах-подборщиков. Лучше придумать что-то свое, нестандартное. Можно ориентироваться, например, на генератор хэшей на сайте insidepro.
В hashcat, например, есть (или была) опция подбора пароля к соленому хэшу по известному алгоритму, даже если нет самой соли. Если соль короткая, ее отсутствие в БД лишь отсрочит взлом.
PS. Юзайте нестандартные алгоритмы хэширования или криптования, какой-нить Blowfish или AES с достаточной длиной ключа.
PPS. Соль лучше всего хранить в солонке smile
ava
infarch | 20.03.2013, 10:44 #
Цитата (krypt3r @  20.3.2013,  07:30 findReferencedText)
Неважный выбор. Сей алгоритм есть во многих программах-подборщиков.

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


Цитата (krypt3r @  20.3.2013,  07:30 findReferencedText)
Соль лучше всего хранить в солонке

А перец? smile
ava
warlock000 | 22.03.2013, 19:57 #
У меня в базе соль хранится рядом с самим хешем, генерация примерно такая  md5(md5(_filter($password)) . $salt);
По сути можно сделать примерно такую приблуду:

Привязку к айпи адресу и(или) подсети, для добавления доверенных айпи использовать СМС, ввёл код с СМСки добавил подсеть. Можно извратиться ещё больше, убрать или почти убрать авторизацию (есть пару нюансов) сделал проверку на айпишник если он доверенный то впускать в систему (буду проблемы с динамическими айпи, но можно сделать данное условие только для статики). Ну и уж если совсем защитится сделать токены или карты переменых кодов, аналогично как в банках и что хочет сделать гугл smile Что то я замечтался...
ava
Сумасшедший | 22.03.2013, 21:29 #
Двусоставная соль: "крупная" хранится в базе и "мелкая",- нигде не хранится. Её вводит пользователь каждый раз при авторизации. Протеряете и базу и код - без знания "мелкой" соли будут гораздо дольше подбирать. 
ava
Marlik | 01.05.2013, 11:43 #
Мммм.... а 6 перл попробовать, скомпилить?
Please register or login to write.
Firm of day
Вы также можете добавить свою фирму в каталог IT-фирм, и публиковать статьи, новости, вакансии и другую информацию от имени фирмы.
Подробнее
advanced
Submit