Еще парочка вопросов к умным людям

Вопрос номер раз. Собственно, задача вот какая... Необходимо хранить пароль в базе в виде, удовлетворяющем следующим условиям:
1) Иметь как можно большую взломоустойчивость в случае, если злоумышленник каким-то способом получил доступ к базе данных.
2) Не давать принципиально возможность сменить пароль через SQL запросы (считаем что доступ к базе данных у злоумышленника есть).
3) Все вышеперечисленное - при том, что исходный код CMS в общем то опубликован в сети, и злоумышленник, считаем, знает все алгоритмы шифрования, применяемые в системе.
Сразу навскидку приходит в голову идея хранить внешний ключ в отдельном файле, например воспользоваться классическим RSA ключом, который генерить при "инсталляции" системы.
Какие есть еще предложения, идеи, соображения?
Вопрос номер два. Хранение сессий - в базе данных или в файлах. Какие + и - каждого из способов?(Язык программирования D, скорость чтения и записи в файл, а так же общения с СУБД будем считать равна C++).

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

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

С базой - надо таскать базу. В общем случае база работает медленнее файла и жрет больше ресурсов. Хотя кода на пару экранов меньше.

Хых, использовать пароли мускула - это весело) Правда в "коробочную" версию такой метод класть нехорошо, на многих хостингах люди ограничены в создании пользователей...
Цитата ("akkort"):

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

С базой - надо таскать базу. В общем случае база работает медленнее файла и жрет больше ресурсов. Хотя кода на пару экранов меньше.

В целом ясно... Вообще говоря, одновременное использование несколькими процессами одного и того же файла - ситуация скорее исключительная, чем штатная, но очередь всеравно придется реализовывать...
Ситуация в общем вот какая. Время генерации стандартной странички у нас составляет порядка 50 мс у нас на сильно урезанной в ресурсах VDS... И из них бОльшую часть времени - от 30 до 40 занимает запрос на апдейт сессии, даже если препарированный...
К слову, селекты на его фоне вообще летают, даже достаточно большого обьема данных. Оно и понятно, найти, изменить, переиндексировать... БД - PostgreSQL.
Вот и хотелось бы максимально это время сократить.

Цитата ("dervinar"):

..1) Иметь как можно большую взломоустойчивость в случае, если злоумышленник каким-то способом получил доступ к базе данных.

Перед записью пароля в БД, пароль шифруется любым алгоритмом "одностороннего" шифрования (т.е. шифрования не допускающего расшифровки, например md5hash). Для проверки пароля, проверяемый пароль шифруется тем же алгоритмом и сравнивается с шифрованным паролем из БД, таки образом, в БД хранятся только зашифрованные пароли, которые невозможно раскодировать. Эта схема хранения паролей используется в системах Unix и в MySQL.

Цитата ("dervinar"):

2) Не давать принципиально возможность сменить пароль через SQL запросы (считаем что доступ к базе данных у злоумышленника есть).

А) Не хранить пароли в БД SQL, хранить, например, в текстовом файле, для доступа к этому файлу запросы SQL не использовать.

Б) Если хранить пароли в БД SQL, то установить соответствующие права доступа на таблицу с паролями (например, для прикладных программ доступ "только чтение".

Цитата ("dervinar"):

3) Все вышеперечисленное - при том, что исходный код CMS в общем то опубликован в сети, и злоумышленник, считаем, знает все алгоритмы шифрования, применяемые в системе.

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

Цитата ("dervinar"):

Вопрос номер два. Хранение сессий - в базе данных или в файлах. Какие + и - каждого из способов?...

Если Ваше приложение использует БД - храните в БД, если не использует - храните в файлах. Третий вариант - не хранить сессию на сервере, а хранить данные сессии в кукишах на браузере пользователя.

Цитата ("Illarion_SA"):

Перед записью пароля в БД, пароль шифруется любым алгоритмом "одностороннего" шифрования (т.е. шифрования не допускающего расшифровки, например md5hash). Для проверки пароля, проверяемый пароль шифруется тем же алгоритмом и сравнивается с шифрованным паролем из БД, таки образом, в БД хранятся только зашифрованные пароли, которые невозможно раскодировать. Эта схема хранения паролей используется в системах Unix и в MySQL.

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

Цитата ("Illarion_SA"):

Б) Если хранить пароли в БД SQL, то установить соответствующие права доступа на таблицу с паролями (например, для прикладных программ доступ "только чтение".

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

Цитата ("Illarion_SA"):

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

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

Цитата ("Illarion_SA"):

Если Ваше приложение использует БД - храните в БД, если не использует - храните в файлах. Третий вариант - не хранить сессию на сервере, а хранить данные сессии в кукишах на браузере пользователя.

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

Приложение использует БД, как я уже написал выше - PostgreSQL. Время которое тратится на один запрос - апдейт сессий, там положить то надо всего ничего - абсолютно неприличное.

Ясно, спасибо за ответы, будем пробовать реализовать мутекс... Надеемся, получится принципиально быстрее, чем в базе.

Боитесь за md5 - пользуйте sha2 . Или более сумашедший вариант sha2(md5(pwd))

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

Цитата ("vovan_f"):

Боитесь за md5 - пользуйте sha2 . Или более сумашедший вариант sha2(md5(pwd))

Смешно. Вы еще предложите делать sha2(md5(crc32(pwd)))

dervinar, А донгл использовать не катит? В него можно легко зашить любой алгоритм шифрования, плюс защита серверного ПО от копирования.

Хорошо что смешно....
Значит шутка удалась..
Суть то вообще в том что пароль для входа .этой "системы широкого использования" (а я так понял речь о ней идет, а не о каком то супер секюрном продукте), скорее всего будет скомпрометирован сотней других способов чем получен перебором md5

Донгл - это в смысле который в USB втыкается? Нет, не катит, это будет фреймворк для создания сайтов, он должен становиться на любой хостинг...
Хотя вообще штуковина классная.. Помню аналогичные были для LPT портов, я еще мелкий был - игрался скручивал их 1 к 1..=)

Цитата ("vovan_f"):

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

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

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

Цитата ("dervinar"):

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

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

Цитата ("Nitrogeniy"):

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

Любой метод сокрытия информации должен строиться так, чтобы знание метода не облегчало раскрытие скрытой информации. Например, анализ исходного текста программы PGP никак не поможет в расшифровке кодированных сообщений, исходный текст пакета openSSL не поможет расшифровать трафик https. С другой стороны, пароли можно зашифровать любым, сколь угодно сложным, алгоритмом, но если ключ к шифру хранится где-то на том же сервере где лежат пароли, то криптостойкость этого метода будет определяться именно тем, сколько времени понадобится взломщику на то, чтобы найти спрятанный ключ.

Цитата ("dervinar"):

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

а еще если не сложно ввести определения "пароли нормальной длины" и "приемлемое время". А то вроде и по теме сказали, а смысла как-то не ощущается.

ПыСы.
Ничего личного

Я тут вдогонку полез гуглить.

вот такой прикидыватель по времениншел:

ссылка

при 12 символах Цитата:

При производительности в 3800000 паролей в секунду это займет: 280552 веков 91 лет 314 дней 8 часов 56 минут 51 секунд

и таблица снизу. В общем более 7 символов пароля сильно усложняют метод перебора.

Ypeskov, если верить тому же прикидывателю - на 1 компьютере P-IV 2.4Ghz PC533 (Northwood) - в настоящий момент уже далеко не топовый - пароль из 6 знаков, к слову, это именно знаки, а не символы (имеем в виду что пароль полностью бессмысленный) - 4 часа. Если перебирать по словарю, может оказаться меньше. Пароль из 7 знаков будет вскрываться 10 дней. Пароли более 8 знаков(и при этом бессмысленные) уже достаточно редкое явление - не всякий хороший сисадмин такие пароли имеет. Ну лично у меня от хостинга пароль 8 знаков... Бессмысленный. Потенциальный администратор сайта поставит пароль, который с высокой степенью вероятности будет найдет в одном из соответствующих интернет-сервисов.

Цитата ("Nitrogeniy"):

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

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

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