Автообновление CMS

У Бирмана встретил на сайте его движка блогов «e2»:

Рекламируют автообновление:

Если смотреть на систему непредвзято — она действительно хороша. Первое, чем она вас встретит — это автоматические обновления: пожалуй, уникальное свойство в мире CMS. Она сама скачивает с сайта разработчика заплатки и новые функции и сама же на себя их устанавливает.

Я действительно гений. После того, как я это сделал в 2004 году, это стало появляться и в других веб-приложениях.


TimeLabs CMS (23.89КиБ)

в 2003-м появилась TimeLabs CMS, хорошая система для тех лет, с контекстным меню, автообновлением, модулем, позволяющим создавать произвольные типы данных (причём более гибко, чем в «Битриксе» даже сейчас), безопасным логином (через JavaScript SHA1), гибкой системой прав, системой контекстной помощи, PHP cron, AJAX-модулем общения админов (админка была расчитана на IE) и так далее — интересных особенностей там была куча.

Система прав, локализатор и модуль файла конфигурации сейчас используется в Lixil CMS, а миниязык блокировки по IP — в проекте KVNru.ru. Так что часть системы жива и сейчас, не говоря уже о том, что до сих пор существуют сайты на этой CMS (скриншот взят с одного из таких сайтов).
13 апреля 2008 16:09

tserbis (BresSergey.com)
13 апреля 2008, 16:49

> безопасным логином (через JavaScript SHA1)
Это об отсылке по HTTP при авторизации не пароля as is, а его hash'а, если включён JavaScript?

bolk (bolknote.ru)
13 апреля 2008, 16:54, ответ предназначен bressergey.com:

Отсылается пара sha1(pass + salt) и ID salt в базе. Включен ли JS меня не волновало — он должен быть включен, иначе с админкой работать просто не получится.

tserbis (BresSergey.com)
13 апреля 2008, 17:29, ответ предназначен bolk (bolknote.ru):

А, ну это о том, о чём я подумал.
Спасибо (думал что-то упустил).

parpalak (written.ru)
13 апреля 2008, 17:37, ответ предназначен bolk (bolknote.ru):

А salt генерится каждый раз при загрузке формы с логином и паролем?

Насколько хорош (или плох) вариант, когда отсылается пара md5(md5(pass) + salt) и salt, причем salt действителен в течение N часов, а в таблице хранятся md5(pass)?

bolk (bolknote.ru)
13 апреля 2008, 18:02, ответ предназначен parpalak (written.ru):

salt генерится каждый раз, а назад (в данных формы) приходи не salt, а идентификатор salt в базе (или salt кладётся в сессию). В любом случае, salt нигде не передаётся в открытом виде.

Salt в окрытом виде чуть более секурно, чем plain password, причём величина этого «чуть» зависит от популярности проекта.

parpalak (written.ru)
13 апреля 2008, 18:23, ответ предназначен bolk (bolknote.ru):

В любом случае, salt нигде не передаётся в открытом виде.
А как тогда javascript сгенерит sha1(pass + salt)?

И еще, после того, как пользователь залогинился, в запросах (или через cookies) нужно что-либо передавать (salt или его ID)? Или проверять ip, с которого идут запросы?

bolk (bolknote.ru)
13 апреля 2008, 18:28, ответ предназначен parpalak (written.ru):

Salt содержится в данных от сервера.

bolk (bolknote.ru)
13 апреля 2008, 18:34, ответ предназначен parpalak (written.ru):

В запросах передаётся идентификатор сессии, больше ничего. Если вы расчитываете, что закрытой части будут обращаться пользователи с dialup, то IP лучше не контролировать, я использую данные браузера (user-agent, te и так далее).

Я тут обнаружил, что ответил не на тот вопрос, который вы задали, а на то, что было у меня в голове. Salt надо удалять из базы сразу, как только был произведён login или по timeout. Причём важно, чтобы система проверяла — есть ли salt на момент логина в базе.

Сам salt передаётся с сервера, обратно я возвращаю только ID salt в базе и sha1(pass + salt). Это усложняет атаку, так как нужно сопоставлять пришедший с сервера salt и его ID в данных от клиента и слушать трафик в обе стороны.

parpalak (written.ru)
13 апреля 2008, 19:14, ответ предназначен bolk (bolknote.ru):

Теперь понятно. Я примерно так и делал. За исключением одной детали - у меня salt совпадает с идентификатором сессии. В общем, подумаю на досуге, что там можно переделать.

bolk (bolknote.ru)
13 апреля 2008, 19:18, ответ предназначен parpalak (written.ru):

Переделывать особо нечего — можно поместить salt в сессию, делов-то.

parpalak (written.ru)
13 апреля 2008, 20:35, ответ предназначен bolk (bolknote.ru):

Мне сначала надо понять смысл этих изменений, что я и постараюсь сделать на досуге :)

Пока мне непонятно вот что.

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

2) Если будут перехвачены данные, отправленные из формы, когда я залогинился, из них всё равно пароль (или его хеш для используемого мной md5(md5(pass) + salt) и salt) достать не удастся.

Учитывая эти два факта, зачем нужно обеспечивать защиту salt'а и не передавать его назад на сервер в открытом виде?

bolk (bolknote.ru)
13 апреля 2008, 21:15, ответ предназначен parpalak (written.ru):

1) защита от задачи зависит. вариантов несколько: например, можно смотреть не работают ли одновременно два IP с одного логина (у меня так и было), если да — оба отрубаются. если не расчитывать на dialup, можно контролировать IP. Ну и конроль характеристик браузера немаловажен.

2) чем сложнее, тем лучше. выше вероятность, что возиться не будут, это я знаю по себе.

Кстати, что я вспомнил. У меня salt ещё и к IP привязывалась.

saetov.com (saetov.com)
16 апреля 2008, 19:55

оо, старые знакомые)) как люди, так и сиэмэс

bolk (bolknote.ru)
17 апреля 2008, 10:35, ответ предназначен saetov.com:

Всех знаешь? :)

Ваше имя или адрес блога (можно OpenID):

Текст вашего комментария, не HTML:

Кому бы вы хотели ответить (или кликните на его аватару)