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

Mishin Oleg

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

Предлагаю обсудить теорию создания таких систем. Плюсы/минусы, варианты решения проблемы.

В частности, на одном из моих сайтов из-за отсусттвия какой-либо DB использую хранение всей инфы в файлах (здесь без мата - сам умный). Проблемы с файлами хоть и возникали, но все были довольно просто решены.

Осталась следующая проблема: идентификацию сделал следующим образом: получаю от пользователя при регистрации пару логин/пароль, делаю из нее

$ID=crypt($login/$password);

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

$record_in_file=crypt($ID,$ID);

Это позволяет проверять наличие пользователя по его кукизу, и в то же время не держать паролей на сайте в сколько-нибудь открытом виде.

Возникает проблема: пользователь хочет сменить пароль: я не могу получить его старый пароль/логин из этой записи (вполне логично: одностороннее шифрование).

Соответственно не могу предложить ему хотябы Логин в поле форму. А хранить Логин - значит хранить часть секретной пары в открытом виде.

Вопрос: безопасно ли хранить Логин рядом с $ID, и не повлияет ли это на уровень безопасности сайта?
 

rotoZOOM

ACM maniac
Логин хранить надо!
Хотя бы для того, чтобы потом помочь юзеру восстановить/поменять пароль.
 

Mishin Oleg

Новичок
Уверен, что это не влияет на декриптинг? Ладно.

А система восстановления реализована через e-mail, так что здесь проблем нет.

Занешь еще какие-нибудь более удачные системы хранения паролей без баз данных?
 

Popoff

popoff.donetsk.ua
А хранить Логин - значит хранить часть секретной пары в открытом виде.
Логин не является секретным. Если логин - это секретная информация, то вводить его нужно в поле типа password, что бы никто не мог подсмотреть во время ввода.
 

rotoZOOM

ACM maniac
в качестве секретной пары можно хранить сочетание id пользователя + его пароль (шифрованные)
 

Mishin Oleg

Новичок
Idap - база данных, на том хостинге же нет ничего кроме PHP, да и вопрос скорее теоретического плана, нежели сложности в реализации.

То есть хранить

ID
Crypt(password,???)

Тогда не решена проблема, тогда уж легче действительно хранить

Login
$ID=Crypt($Login,$Password)

так хоть можно восстановить явный Login.

Повторюсь, я не могу хранить открытый $ID, так как он есть в кукизах и в адресе, и спереть его - проще простого. Необходимо зранить что-то, что бы однозначно соответствовало идентификатору, получалось из пары логин/пароль, и не обладало обратным триптированием.

-~{}~ 31.01.05 15:27:

Согласен, что безопасно, было просто интересно, может есть какие другие алгоритмы, так как этот я ни у кого не брал, он мне просто в голову стукнул как более-менее оптимальный и универсальный.
 

rotoZOOM

ACM maniac
А почему бы не хранить:
Login
$ID=Crypt($ID,$Password)
Тогда ты хранишь ID и Пароль в зашифрованном виде.
И ID юзер добыть не сможет никак.
И вообще 100% ой защиты нет, так что чем больше ты наворотишь в плане защиты, тем сложнее тебе будет работать с данными потом. Например базу восстанавливать понадобится.
 

Mishin Oleg

Новичок
да, сложности тут ни к чему.

rotoZOOM

Твоя система мне не подходит, хоть она и удобна. Вот почему: я доблеж передавать ID параллельно в cookies и в адресной строке, и вот смотри:

Получает скрипт ID пользователя, а ему понадобилось сделать запись в логе, или найти пользователя из списка, тогда ему необходим еще и пароль (для создания ID в виде записи в файле), ведь открытый ID не должен быть равен хранимому ID, и получается, что я не могу его получить.
 

dimas

Новичок
Логин не надо шифровать в базе, это маразм.
Пароль шифровать объязательно и не высылать его, а высылать ссылку, по которой можно перейти для его изменения.
Хранить данные в файлах это не плохо, это очень хорошо, только писать такой код запаришься. Например на google так и сделано.
 

rotoZOOM

ACM maniac
Получает скрипт ID пользователя, а ему понадобилось сделать запись в логе, или найти пользователя из списка, тогда ему необходим еще и пароль (для создания ID в виде записи в файле), ведь открытый ID не должен быть равен хранимому ID, и получается, что я не могу его получить.
От кого скрипт получает ID пользователя ?
Если скрипт его получил, он сможет без труда достать всю информацию о пользователе. Иначе зачем вообще идентификатор нужен.
Я имел ввиду хранить вместо пароля Crypt ($ID,$PlainPassword);
 

Mishin Oleg

Новичок
Автор оригинала: dimas
Логин не надо шифровать в базе, это маразм.
Пароль шифровать объязательно и не высылать его, а высылать ссылку, по которой можно перейти для его изменения.
Хранить данные в файлах это не плохо, это очень хорошо, только писать такой код запаришься. Например на google так и сделано.
Для шибко умных прозьба переситать ветку, особенно первое сообщение, где в вопросе использования файлов посталвлена точка.

Откуда ты взял, что Логин кто-то собирается шифромать, или ты сам предлагаешь это сделать?

-~{}~ 31.01.05 15:47:

2 rotoZOOM
А тогда как скрипт получает Password? скрипт уже по ходу работы сессии, когда пользователь зашел и залогинился по кукизу, а не вводил пароль?

Я хочу сработать по принципе зашел->создал ID->забыл пароль. Чтобы нигде его не хранить и не передавать.
 

rotoZOOM

ACM maniac
Я так понял, что пользователь зашел. Зарегистриовался, зашел на страничку Login (поставил галочку автологина), ввел свои Login и пароль, и забыл про них ? Так ?
А ты в кукисах хочешь записать такую информацию, чтобы при автологине ты смог уникально идентифицировать этого пользователя.
Если это так, то в кукисах храни шифрованную пару (id,password) - это и будет уникальным ключем для каждого пользователя.
 

Astral Man

We Will Rock You
Логин в открытом виде, пароль в MD5, а $ID == Session id
и не изобретать велосипед.
 

Mishin Oleg

Новичок
2 rotoZOOM
Да, совершенно верно, так я и делаю. Только что за id? откуда ты предлагаешь его получать?

2 Astral Man
$SID - это то же самое, дак к чему велосипед?

-~{}~ 31.01.05 16:57:

2 rotoZOOM
Если ты имеешь в виду $SID, то при отключенных cookies он теряется, поэтому я от него отказался.
 

rotoZOOM

ACM maniac
id - уникальный идентификатор пользователя. (точнее записи о пользователе)
 

Orlis

Guest
session_id гораздо более безопасная для пользователя вещь, ибо имеет четко ограниченное время жизни

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

Mishin Oleg

Новичок
но пароль ломануть сложно - он закриптован

-~{}~ 31.01.05 17:13:

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

-~{}~ 31.01.05 17:16:

Хотя, это только теория, так как если запорачиваться SSL, то уже пора бы переползать на MySQL ;-)
 
Сверху