|
| |
|
|
| |
для: Trianon
(02.12.2007 в 00:34)
| | | Ужо разобрался, но на самом деле в этой статье множество ошибок, до которых пришлось мне, как нубу, догадываться долго и нудно =( | |
| |
|
|
| |
|
|
| |
для: DiMoN_TD
(02.12.2007 в 00:03)
| | | В условиях стоят знаки неравенства. | |
| |
|
|
| |
|
|
| |
для: JIEXA
(31.08.2007 в 18:09)
| | | ну так что, никто не может мне помочь? | |
| |
|
|
| |
|
|
| |
для: JIEXA
(31.08.2007 в 18:09)
| | | Вы мне можете объяснить сл. строки в коде check.php:
if(($userdata['user_hash'] !== $_COOKIE['hash']) or ($userdata['user_id'] !== $_COOKIE['id']) and (($data['user_ip'] == $_SERVER['REMOTE_ADDR']) or ($data['user_ip'] == "0")))
{
setcookie("id", "", time() - 3600*24*30*12, "/");
setcookie("hash", "", time() - 3600*24*30*12, "/");
print "Хм, что-то не получилось";
}
else
{
print "Привет, ".$userdata['user_login'].". Всё работает!";
}
|
До меня что-то не доходит, почему, если все эти условия выполняются, то у нас что-то не получилось... может наоборот, у нас всё прекрасно, всё совпало и можно идти дальше??
А то я в этих кукисам дуб дубом =( | |
| |
|
|
| |
|
|
| |
для: bronenos
(31.08.2007 в 20:13)
| | | > на С++
на чём? | |
| |
|
|
| |
|
|
| |
для: Trianon
(04.09.2007 в 01:28)
| | | Собирусь как-нить, напишу немного в другом виде. Есть пара идей | |
| |
|
|
| |
|
|
| |
для: JIEXA
(31.08.2007 в 18:09)
| | | три существенных замечания.
1. magic quotes следует отключить, либо нейтрализовать.
Иначе может случиться неприятность при переносе базы пользователей с одного хостинг на другой, например.
2. Момент генерации случайного ключа лучше бы выразить более четко.
На самом деле вся случайность вызова mt_rand в его неявном обращении к mt_srand - а того, соответственно, к таймеру машины. Все остальное - деетрмированные вычисления.
Лучше прямо взять результат вызова microtime (до определенного знака, считая от младших).
3. Двойной хеш, конечно, лучше одинарного, но не на порядок.
Лучше генерировать Init Vector для каждого эккаунта (тот же случайный ключ), сохранять его в таблице, и хешировать пароль с его учетом и с учетом логина. Тогда атака построением таблиц хешей явно загнется, останутся лишь брут форс и словарь.
Еще лучше, конечно, аутентифицироваться по challenge-response методике, но для этого потребуется считать хеш на клиенте... В принципе, если клиент поддерживает хотя бы JS - это реально, хотя и крайне муторно. Тут и до https недалеко, тем более, что для обеспечения хотя бы коммерческого уровня секьюрности он всё равно потребуется.
PS. А умалчиваемое значение полю user_hash всё же стоит задать. Версия MySQL тут не при чем. Если у поля стоит NOT NULL и не стоит DEFAULT - оператор INSERT должен задавать значение такого поля явно. | |
| |
|
|
| |
|
|
| |
для: victoor
(03.09.2007 в 18:59)
| | | Я вообще-то это написал тем, кто боится, что пользователь оставит ссылку где-то, в которой будет фигуриорвать его сессия.
А скрывать сессию от самого пользователя, который ей пользуется мне ещё не приходило в голову: зачем? чтобы он сам себя не хакнул? =))
Кстати говоря, в скрытом поле он ничего не увидит, равно как и саму форму, потому что она формируется с использованием метода appendChild DOM2 | |
| |
|
|
| |
|
|
| |
для: Futurer
(03.09.2007 в 18:54)
| | | а что мешает пользователю посмотреть ключ сессии в скрытом поле? делается простым просмотром html-кода... | |
| |
|
|
| |
|
|
| |
для: Unkind
(02.09.2007 в 23:29)
| | | А я как-то написал скрипт, который обрабатывает все ссылки и формы и добавляет к ним значение ключа. А потом эти ссылки делятся на 2 части:
Формируется форма и общая часть ссылки(без ключа сессии) отсылается в поле action формы, а само значение ключа сессии в скрытом поле методом post в этой же форме. При нажатии на ссылку форма сабмитуется и всё выглядит как клик по ссылке, только ключ не присутствует в строке запроса. Вот вам как вариант. | |
| |
|
|
|
