Система идентификации пользователей

Orlis

Guest
Пойми же ты! SID это временный пропуск на вход, подбирать его или стаскивать смысла немного.

А хакнутый логин/пароль имеет ценность в отрыве от твоего сайта, так как многие пользователи используют одну пару на всех сайтах интернета, именно так добывают 6-значные аськи и красивые почтовые ящики...

SSL тут ни к селу, ни к городу. Ломать будут не провайдеров по маршруту между юзером и хостером, а либо машину пользователя, либо хостера, либо твой сайт конкретно.
 

Astral Man

We Will Rock You
Автор оригинала: Mishin Oleg
А вот SID можно стащить при передаче данных...

А других способов взлома я не вижу, только опять перехватить данные регистрации, но тогда нужно длеать регистрацию через SSL, а все остальное через этот ID.
Скажи мне пожалуйста чем отличается твой ID от SID? все можно стащить при передачи данных.

А если вдруг куки у пользователя выключены, можно добавлять SID к url.
Или проверять на факт включения кук, если они не включены не пускать на страницу вообще.
 

Orlis

Guest
тем что SID генерируется случайно, а не на основе секретных данных пользователя
 

Astral Man

We Will Rock You
Orlis
Всмысле перехвата...
Какая разница на основе "секретных" данных или просто случайно сгенерит его система?
 

Mishin Oleg

Новичок
2 Orlis
я с тобой абсолютно согласен, с челью исключить эту вохможность я и избавляюсь от пароля, сгенерировав $ID.

2 Astral Man
читай внимательно ветку!!!
SID - Session IDentificator
ID=crypt($login,$password);
>> А если вдруг куки у пользователя выключены, можно добавлять SID к url.
так и сделано - читай ветку внимательно.
>>Или проверять на факт включения кук, если они не включены не пускать на страницу вообще.
Это е подходит по понятным причинам.

2 Astral ManВсе дело в том, что мне надо с чем-то его сопоставлять, а если запоминать сам SID, то дабы сделать возможным "вспоминеание" пользователя... впринципе - логичный вариант. Пожалуй я с тобой соглашусь, что такая система немного стройнее и красивее. пожалуй стоит попробовать заморочиться.

Сказать по правде, сначала все было сделано именно на сессиях, но когда пошли пользователи с отключенными кукизами, начальством была дана команда решить проблему. Так что в результате пришлось изварачиваться. Где наша не пропадала?

Тогда вопрос: пользователь вводит логин/пароль, что я должен запоминать, пароль запоминать нельзя (см. выше), Запоминать SID нет смысла, так как когда он устареет, как я вспомню пользователя? Значит нужен все равно запомнить логин и $ID=crypt($login,$password), а уже рядом запминать $SID, дабы вспомнить пользователя, пока у него есть живой кукиз,

я правильно тебя понял?

-~{}~ 01.02.05 09:48:

Но, тогда к чему все эти пляски? тогда по логике ID ~ SID, разница лишь в том, что SID генерится автоматически (хотя я и могу его насильно устанавливать), а ID я генерю сам.
 

rotoZOOM

ACM maniac
Зачем запоминать $SID вообще ?
Пусть его помнит PHP и сам передает в URL'е или в Кукисах браузеру. Не надо с этим заморачиваться.
Запоминай в сессионных переменных все что хочешь, для определения юзера эти данные все равно не будут доступны юзеру, так как они хранятся на сервере. И никто левый, кроме твоего PHP кода не сможет с ними работать.
 

Mishin Oleg

Новичок
Правильно бы было.

Но когда как я буду ассоциировать переданный номер SID с определенной учетной записью (login) ?

-~{}~ 01.02.05 10:32:

Запомнить в сессии логин? Ты уветен, что это безопасно? Но тогда что хранить в кукизах?

SID и логин - тоже не получается

только SID, но тогда для "вспоминания" необходимо время жизни сессии устанавливать долгим...
 

rotoZOOM

ACM maniac
Хранить SID в кукисах это что то из области фантастики, так как SID и так хранится в кукисах САМ (если в опциях не отключено специально).
Для автологина в кукисах достаточно хранить хэш(уникального ключа юзера, включающий пароль, например пароль+ID юзера, или пароль + логин, неважно)
Главное, чтобы ты по этому хэшу потом смог бы однозначно идентифицировать пользователя.
Все. Больше ничего не надо.
 

Mishin Oleg

Новичок
описка, сори

я имел в виду не хранить, а просто иметь номер сессии...

Ну да, тогда мы опять выходим на хранение ID, только теперь уже в сессии, и потом распознавание этого login+ID = авторизация.

Спасибо, сам немного разобрался с темой.

То есть, подытожим:

В сессии храню ID и логин, по которым могу однозначно идентифициовать пользователя,

В дазе пользователей храню логин и ID, но уже в зашифрованом виде. Одностороннее шифрование ID, логин в открытом виде, дабы дать пользователю возможность менять логин/пароль.

Все верно?

Тогда, стоит ли делать процесс регистрации через SSL? Явно надежнее, дабы не подарить пароль налево. А без пароля не получить ни ID, ни SID.
 

rotoZOOM

ACM maniac
Если у тебя логин уникален (что должно быть), то хранить нужно только его (или только ID пользователя). По любому из этих полей, ты сможешь (должен смочь) уникальным образом идентифицировать юзера.
Это что хранить в сессии.
А вот в кукисах храни ЧТО_НИБУДЬ в зашифрованном виде, что тоже уникальным образом идентифицирует пользователя и это ЧТО_НИБУДЬ должно включать в себя пароль.
Базу пользователей строй таким образом, чтобы тебе было удобно с ней работать, не надо там немыслимых и никому не нужных шифрований логина, id и т.д.
Пусть там хранится ID, Login, и ЧТО_НИБУДЬ в зашифрованном виде. Все равно это все хранится на сервере и к юзеру не попадет.
Зато теперь любое это поле является уникальным ключом.
И искать в базе можно по любому из этих полей.
SSL авторизация необходима, чтобы не перехватили пароль "по дороге", во время регистрации юзера.
 

Mishin Oleg

Новичок
2 Astral Man

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

Еще раз повторюсь, вопрос скорее философский, к тому же, он уже закрыт, и писать в конце ветки ссылки на то, что участники уже знали до начала ветки, по меньшей мере глупо.

Извини, если обидел, но ты даже не понял сути происходящего.
 

Astral Man

We Will Rock You
Mishin Oleg
Да всё я понял, вот ты понять не хочешь и упираешься в свою систему которая работает стабильно...
Тебе предлогают варианты, как правильно сделать, а ты на своем...
Думай сам - изобретатель велосипедов :)
 

Mishin Oleg

Новичок
2 Astral Man
Ты даешь ссылку на систему на основе DB, ты в курсе? Или ты мне хотел показать, как строятся систему на основе сессий? Спасибо!

Я специально перечитал эту статью сейчас, дабы исключить непонимание, система неплоха, довольно универсальна, Но это то же самое, что написано здесь, что нового ты сказал? Только то, что на DB это решается проще? Ёжику понятно, но уж таковы особенности нашей работы, что приходится изварачиваться.

Я понял все плюсы системы на SID, тем более, что изначально моя система была именно на сессиях. Теперь буду бумать дальше, может и перевуде движок на сессии, тем более, что это не трудоемко.

В любом случае, спасибо всем, в том числе и Astral Man, я ведь статью прочитал ;=)
 

Astral Man

We Will Rock You
Mishin Oleg
Да не за что, главное что бы все работало ;)
А где хранить данные в БД или на файлах суть не меняет.

Удачи!
 
Сверху