Автор оригинала: Alexandre
Фанат, хоть и остр на язык, но он наводит на довольно умные рассуждения, которые надо уметь читать между строк, а не быть обиженной девочкой.
Гы, спасибо за поддержку, но я ни чуть не обиделась - привыкла к грубости отдельных мужчин
(ессно шутка... всё-таки тема "Юмор" н.з. - слегка можно и пошутить... я ваще-то парень... но иногда хочется быть и девчёнкой... хм-хм короче...)
Попробую растолковать его мысли:
Автор оригинала: Alexandre
если злоумышлонник сможет получить данные сессии, то он с такойже простотой сможет иметь доступ к источникам пхп (если они не будут закодированы), а отсюда - доступ ко всей информации, которая может быть доступна скрипту. А по сему, криптостойкость системы не выше надежности разрабатываемой системы и надежности хостера.
Да, разумеется, но если в ключ крипта включать ID сессии (который ессно регенерится при каждом запросе клиента), то криптостойкость повышается...
Автор оригинала: Alexandre
Для криптостойких систем используются именно удаленные сервера ключей, а не вычистяются ключи путем хеширования иди сессии.
В этом примере, для простоты использовался только ИД сессии, в конечном варианте, ессно удалённого сервера ключей не будет, но в криптуху кое-чего добавлю... ессно - не на столько секурней, но всё-таки, за те 5-10 минут, по истечении которых пользователь сделает новый запрос и ИД регенерится, будет реально мало для полного анализа...
Автор оригинала: Alexandre
ты их в сессию не записываешь, а хранишь в зашифрованном виде в поле BLOB.
я записываю в БД данные сессии, полученные в параметре ф-ции write (которую указали в session_set_save_handler( ))
вобщем, чтобы не "мусорить" сырцами, приведу часть:
//Здесь вызывается сама session_set_save_handler( )
PHP:
SessionPersistentManager::applyDecorator(new SessionEncrypt(new SessionDBPersistent(new SessionPersistent())));
//Это сам класс, который создаёт объект хендлинга
PHP:
class SessionPersistentManager {
private static $entry = null;
public static function open($save_path, $session_name) {
return self::$entry->open($save_path, $session_name);
}
public static function close() {
$ret = self::$entry->close();
self::$entry = null;
return $ret;
}
public static function read($id) {
return self::$entry->read($id);
}
public static function write($id, $session_data) {
return self::$entry->write($id, $session_data);
}
public static function destroy($id) {
return self::$entry->destroy(id);
}
public static function gc($life_time) {
return self::$entry->gc($life_time);
}
public static function applyDecorator($entry) {
ini_set("session.gc_probability", 100);
self::$entry = &$entry;
session_set_save_handler(
array('SessionPersistentManager','open'),
array('SessionPersistentManager','close'),
array('SessionPersistentManager','read'),
array('SessionPersistentManager','write'),
array('SessionPersistentManager','destroy'),
array('SessionPersistentManager','gc')
);
}
} //class SessionPersistentManager
т.е. цепочка Декораторов...
В данном случае, при инициализации поведения <read> вначеле читаем из бызы, потом передаём декорируемому объекту - Криптовальщику...
То, что данные читаются и пишутся в БД корректно - гарантирую.
Автор оригинала: Alexandre
я бы мог помочь советом, если бы понял ход работы программы(опиши по пунктам) , особенно тот кусок - где используется сессия и где происходит шифрование, куда потом идет эта информация, как потом она извлекается.
Угу, пасиб, если после этого поста ситуация не прояснится - "помусорю" исходником
-~{}~ 28.04.06 12:04:
Автор оригинала: Alexandre
Почему выбран именно RSA ?
...
Сам себя спрашиваю... знаете, скорее всего для понтов
или "на-вырост"... в реале, без сервера ключей по ssh использовать не собираюсь... (т.е. некоторое время...)
(Просто не сложно было)
Всё остальное - отверстие