Относительно движка сайта

Разные браузеры бывают. Но как это может влиять, так и не понял. IP постоянный.
И кто же это мне может в куку изменение внести?

Цитипую отсюда:

spinore:
Да, и по поводу разных браузеров: почему меня
выкидывает из предыдущего браузера когда я авторизовываюсь в новом браузере?

SATtva:
Потому что определённая сеансовая информация сохраняется в куке, и если система при переподключении пользователи этой информации найти в переданном куке не может (или эта информация не соответствует тому, что ожидала система), происходит сброс. У Вас же в разных браузерах разные куки сохраняются. Оттого так и происходит.

spinore:
Да, но это неудобно – ограничивать пользователей по числу сессий, особенно с учётом
того что подобного артефакта на сайтах в интернете обычно нет

SATtva:
Зато есть уязвимость к атакам с повторной передачей: скопируйте куку пользователя (например, если он авторизовался с работы или инет-кафе), а потом гоняйте её, чтобы в любой момент заходить от его имени на сайт. Здесь если человек разлогинился, любые копии куков становятся бесполезны.

На самом деле SATtva внятно не отаргументировал каким образом кто может спирать куки и почему надо запрещать работать в 2-х браузерах. Мне просто лень спорить было и я замолчал. Аргумент что кто-то забудет разовтаризоваться в кафе и тем самым даст возможность злоупотребить своими куками не уместен: с таким же успехом можно вообще зарубить парольную аутентификацию так как она не спасёт против кейлоггеров установленных в кафе и т.п. Не говоря уже о том, что в пользу редкой тупой единицы которая ходит на сайт с кафе создаются неудобства для 99% пользователей сайта ходящих сюда со своих домашних или рабочих компьютеров, а не говоря уже о том, что для особо одарённых прикручивается подпись комментариев, и уже прикручена смена пароля по ключу – это для тех кто действительно пекётся о безопасности своего аккаунта. Кто же не пекётся о безопасности – он может свой пароль на этот сайт хоть на заборе написать чтоб все видели – идеология с куками от этого не спасёт. Правильная стратегия – защищать тех, кто сами прикладывают усилия к этому, то есть на защите от дурака далеко не уехать – дурак окажется смышлённее чтоб обойти защиту от него рано или поздно.

против кейлоггеров установленных в кафе

Можно было бы дать возможност желающим сделать некоторые (и даже все) символы пароля зависимыми от того, что они видят на экране. Ну типа вторая буква в третьем слове. А задавать пароль можно будет выражениями типа "Fh(3,2) gk(5,1) fcv" (или вобще регулярными выражениями :)

регулярными выражениями

То же что и выше будет выглядеть примерно так:

s/([A-я]*[^A-я]*){2}.(.)([A-я]*[^A-я]*){2}(.)/Fh$2gk$4fcv/

Зато SATtvа не надо будет писать свой парсер!
Просто производим замену и результат сравниваем с вводом ползователя.

Ну и самый радикальный вариант когда пользовытель задаёт пароль фрагментом кода (на PHP). При этом он сможет на своей стороне написать аналогичный скрипт (на JavaScript) для автоматизации входа (из дома). Это будет давать защиту от кейлоггеров общего назначения. А если кто опасается специально написанных кейлоггеров или связываются с чужого компьютера, могут использовать Java-апплет на сотовом телефоне.

Ладно, spinore, будем считать, что Вы меня переубедили. Изначально, если помните, защита куков делалась ещё до установки SSL — в качестве одной из первых мер для укрепления сессий (после памятного первого случая получения Вами моего имени на сайте). Сейчас, когда есть SSL и когда в истинных причинах того инцидента разобрались, во всех этих сложностях действительно нет большого смысла.

Cпасибо, SATtva :-)

spinore, Kent и все остальные,
Я отключил аутентификацию куков (сделал её опциональной на уровне глобальных настроек безопасности движка), так что теперь можете работать из нескольких браузеров одновременно.

0чень х0р0ш0, приятная н0в0сть.

ещё вот что хотел спросить:
Был-жил гость, и публиковался он на pgpru.com с подписями.
А пототм взял да зарегался.
Сайт прожуёт тот факт, что "неопределённые ЭЦП" стали "определёнными"?
Или форум не имеет обратной силы? Как это сделано?
(в смысле реализовано алгоритмически на данный момент)

Всё просто. Проверка подписей и вывод индикатора с конкретной диагностикой производится при каждой отрисовке страницы. Соответственно, если вчера ключ автора отсутствовал на сайте и выводилась "неопределённая ЭЦП", а сегодня он зарегистрировался и загрузил ключ в профиль, старые сообщения от гостя получать "верную ЭЦП", но с уточнением, что "ключ принадлежит пользователю Икс".

Грамотно кстати реализовали. Но всё равно подозрения гложат что что-то может быть не так. А если пользователь загрузит ключ, где дата создания из будущего? Или отозванный ключ? Ну там много вариантов есть, все не перебрать в двух словах...

Если один ключ принадлежит двум пользователям сразу: A и B.
Если A подпишет им своё сообщение после авторизации на сайте будет зелёный траст или жёлтая ругань на то что ключ принадлежит пользователю B?

А если пользователь загрузит ключ, где дата создания из будущего?

В OpenPGP, в отличие от X.509, это не имеет практического значения. Можно, конечно, проверять дату специально, но я в этом смысла не вижу. Может у пользователя часы не правильно установлены? Вы же сами идею с лагом забраковали — это из той же оперы.

Или отозванный ключ?

А вот это интересней (как и просроченный ключ, кстати). Данный функционал пока не реализован, но стоит в ближайших планах.

Если один ключ принадлежит двум пользователям сразу: A и B.
Если A подпишет им своё сообщение после авторизации на сайте будет зелёный траст или жёлтая ругань на то что ключ принадлежит пользователю B?

Ситуация нетипичная, и результат зависит от того, чей никнэйм окажется выше в записях БД. Поскольку А выше, то ругани не будет. А вот если тем же ключом подпишет В, то будет предупреждение, что ключ принадлежит А (просто при проверке принадлежности ключа возвращается только первое соответствие; вообще сценарий интересный, и его тоже следует добавить в проверку).