Алгоритм аутентификации

[codex]

Алгоритм аутентификации

Алгоритм следующий.
Есть файл конфигурации *.php, в котором помимо прочего хранится логин и пароль, зашифрованные md5.
При логине, логин и пароль сверяются и бросается кука с зашифрованным паролем. Каждый раз, когда человек заходит в админ раздел - проверятся кука и пароль сверяется с тем, который в конфиге.

Теперь вопрос. Насколько надёжна данная система? Куку можно подделать в двух случаях (имхо) - имея доступ к компу админа и если заглянув в конф файл стырить зашифрованный пароль. Кстати, конф файл проверяет на наличие родного домена при запросе, на всякий случай.

Так вот, надёжен ли данный способ или же можно его как-то оптимизироваь?

Заранее благодарен.

 

[Дмитрий Попов]

codex
Мне вот непонятно:
Какой смысле шифровать пароль, если и там и там он хранится в md5()?

Я бы рекомендовал делать по другому:
Пароль хранится в md5, а кука ставится с оригинальным паролем:
Скрипт же, получая куку шифрует пароль в md5, и уже его сравнивает с хранимым значением.

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

 

[IntenT]

codex
Сессии для авторизации самое то.
И не надо велосипедов придумывать.

Даже поимев куку с ИД сессии многого не добьешься.
Ну а зная только хеш - можно попробовать его расшифровать. Если пароль взрослый- то надоест раньше, чем будет подобран

 

[codex]

IntenT
Факт. Но в данном случае нужно, что бы пользователь не вводил логин/пароль каждый раз при входе в систему.

Дмитрий Попов
Спасибо, я как раз и болтался между этими двумя решениями.

 

[camka]

Факт. Но в данном случае нужно, что бы пользователь не вводил логин/пароль каждый раз при входе в систему.

[m]session_set_cookie_params[/m]

 

[Дмитрий Попов]

camka
Вот не надо таких советов.

Сесси - один механизм, отвечающий за сессию работы с сайтом. Непонятно слово сессия - скажу "сеанс"

Помимо жизни куки есть еще, как минимум время жизни самой сессии.

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

 

[Olorin]

Дмитрий Попов
Ставить куку с оригинальным паролем -- вот это действительно извращение.

 

[camka]

Сесси - один механизм, отвечающий за сессию работы с сайтом. Непонятно слово сессия - скажу "сеанс"

Дорогой дмитрий. Уж ваш первый пост в этой тему дак точно является советом для супер секъюрного сайта.

Помимо жизни куки есть еще, как минимум время жизни самой сессии.

а кто мешает его изменть?

использовать сессию, для долговременного хранения данных - извращение.

Мне всегда казалось, что как раз это одно из основных примениний сессий. Не так?

И, кстати, не помогающее решить проблему, ибо украденный sessionid из куки в таком случае будет не лучше украденного пароля.

Дмитрий, вы - безнадежный параноик. Как по-вашему тогда работает технология сессий? Да, верно, чем длиннее время жизни куки, тем больше вероятность того, что можно подловить "живого" юзера и послать ту его куку, но при желании это можно сделать и для краткосрочной куки. Так что разници тут особой нету.

А ваш первый пост, как уже заметил г-н Olorin, - это идея фикс. Советую предложить эту идею Максиму Галкину, он с радостью включит ее в свою программу. Бегу переделывать весь свой код.

 

[Дмитрий Попов]

camka
[q]Мне всегда казалось, что как раз это одно из основных примениний сессий. Не так?[/q]
1) Не так. Основное применение сессии - передача данных между различными страницами (скриптами) сайта во время сеанса работы пользователя с сайтом (что такое сеанс - надо объяснять?).

[q]Ставить куку с оригинальным паролем -- вот это действительно извращение.[/q]
Вот тут как раз следует поговорить о паранойе.

Вы все мне написали много интересных вещей. Кроме одной:
Я еще раз спрашиваю:
Объясните мне, чем хранение оригинального пароля в куке, хуже чем хранение md5() строки?

Вы почему-то воспринимаете пароль как нечто "сверхопасное". Я же не вижу никакой разницы между паролем, или его md5 суммой, или случайно сгенерированным числом (чем, в какой то степени и является md5 сумма), если знание этого приводит к одному и тому же результату - подделыванию чужой куки. Все это - обычная строка.
Разница только в том, что храня на сервере md5 сумму, и её же посылая пользователю - Вы даете две лазейки для "воровства":
1) Воровство суммы со стороны сервера.
2) Воровство со стороны клиента.

2-го пункта избежать нельзя по определению.

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

Если Вы хотите надежной защиты - то вообще забудьте про
1) Долговоременное хранение логина
2) В случае виртуального хостинга - Про использование "родных" сессий PHP (почему надо объяснять?)
3) От виртуального хотинга...

Вопрос:
Кто из нас параноик?
Второй вопрос:
Вы во "всем своем коде" сессии устанавливаете по времени жизни на 10 лет?

 

[SiMM]

Дмитрий Попов, а зачем посылать md5 пароля или пароль, когда можно посылать sessid, а в сессии, помимо прочего, хранить ip-машины, с которой приходят запросы. ip не сошёлся - куку удаляем напрочь. Это конечно не полное решение проблемы - но хоть какое то усложнение жизни тем, кто попытается "выкрасть" данные.

 

[Дмитрий Попов]

SiMM
Абсолютно не покатит.

Есть два варианта того, что нужно:
1 - то что, сокрее всего, хочет автор вопроса ) Обеспечить долгое сохранения "логина" пользователей в системе. Причем пользователей много. В такой ситуации Ваш вариант не катит - ибо подавляющее большинство пользователей не имеют выделенного IP. Соответсвенно для них схема не работает.
2 - то где может прокатить походий на Ваш вариант) Обеспечить долгое и безопасное сохранение логина, для определенной группы пользователей, зная, что в большинстве случаев у них выделенный IP.
Тогда можно, конечно хранить SID, но нет смысла извращать механизм работы сессий, увеличивая время их жизни. Достаточно просто хранить IPшники в базе и сверять по нему куку. Кстати, в куке можно хранить, в такой ситуации вообще не логин, а, допустим, какое-либо случайно сгенерированное число.

-~{}~ 02.03.04 13:47:

Поповоду 2-го. Я неправильно выразился - сверять IP-шник машины, с записью в базе. И, если все нормально, тогда уже можно и куку.
Но, опять же - а зачем тогда вообще кука? Сверяйте IP и все.

 

[StUV]

SiMM
Дмитрий Попов
http://detail.phpclub.net/article/sessions
наводит на размышления...

 

[camka]

Дмитрий, а может вам в Аншлаг податься?

Я еще раз спрашиваю:
Объясните мне, чем хранение оригинального пароля в куке, хуже чем хранение md5() строки?

Пример жизненный:
Скачал юный хакер Дмитрий сниффер. Запустил его и зырит как пакетики летают туда-сюда туда-сюда. Радуется Дмитрий, улыбается во все 32. Открывает один пакет за другим. И тут - вот счастье!!! - один пакет(а на самом деле все ХТТП пакеты, но этого Дмитрий не знал), исходящий как раз с компа коллеги Павлика, сидящего за соседним столом, имеет в заголовке кроме всего прочего текст Cookie: mysecretpassword=mydickislongest. Присмотрелся Дмитрий, взглянул на Павлика (где-то в район пояса), улыбнулся. Заглянул дмитрий в пакет еще раз, но уже гораздо внимательней. Смотрит - пакетик на порно.ком идет.
Не смотря на то што у Дмитрия был уже логин и пароль на этом сайте (хм...) , он все-таки решил проверить свои догадки. Полез на сайт, ввел пароль Павлика, да и логин он высмотрел уже у павлика давно. Нажал субмит.
Ого-гооооооо. Во пашка дает. Такое скрывал ...... Закручинился Дмитрий ....


Персонажи рассказа вымышлены и любое совпадение с реальными людьми является лишь совпадением и ничем иным.

 

[Дмитрий Попов]

Чего мне нравится, то что все обожают задавать вопросы, но терпеть не могут на них отвечать.

Я вопрос задал:
Чем отличается хранение логина, от хранения md5 строки?
Тем, что можно зайти через форму?

Этот сниффер легко перехватит тот же md5password = dsf32lkj32434klj324
И установит себе куку.


Если мы говорим про платный доступ к порно.ком, или про доступ администраторов сайта - то здесь категорически нельзя вообще давать возможность долгого доступа. Только сессионный. И ни в коем случае не родной "PHP-шный". А лучше вообще использовать безопасное соединение.

Если мы говорим про обычных пользователей, то лучше у меня у одного обычного пользователя утащат пароль и похулиганят - я его прикрою, нежели кто-то более умный заберет у меня всю базу с паролями (или их суммами), и начнет хулиганить от имени всех пользователей. И, соответстеено отловить его можно будет, толкьо сбросив пароли всем пользователям.

Расставляйте приоритеты.

P.S. Я тоже пару лет назад пароль отдавал в виде md5. Пока на одном проекте, как раз не произошла та самая ситуация, когда кто-то получил пароли всех пользователей (хостер-то виртуальный), и стал, автоматом подделывая куки флеймить в OnLine поддержке.

 

[camka]

P.S. Я тоже пару лет назад пароль отдавал в виде md5. Пока на одном проекте, как раз не произошла та самая ситуация, когда кто-то получил пароли всех пользователей (хостер-то виртуальный), и стал, автоматом подделывая куки флеймить в OnLine поддержке.

И с тех пор ты передаешь пароль в открытую, дабы перестраховаться

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

Что это за понятие новое "долгий доступ", и в чем его отличие от сессионного?
Чем тебе не подходит сессионный доступ посредством session_set_cookie_params?

Чем отличается хранение логина, от хранения md5 строки?

тебе специально StUV ссылочку дал.

 

[Дмитрий Попов]

camka

И с тех пор ты передаешь пароль в открытую, дабы перестраховаться

Нет. С тех пор я вообще не храню паролей в первозданном виде. Нигде. А пользователю генерирую псевдослучайное число, md5-сумму которого я храню в базе. Что является по своей сути аналогом пароля. Только пользователь о нем ничего не знает.

Что это за понятие новое "долгий доступ", и в чем его отличие от сессионного

Это я обозначил "Память о том, что пользователь вошел в систему в течении неограниченного периода". Не хочется все время писать такую длиную память.
А сессии, еще раз повторюсь - механизм, созданный для работы во время сеанса доступа к сайту.

тебе специально StUV ссылочку дал.

Почитал. Привязываться к броузеру - это не менее глупо чем привязываться к IP. У меня, например, как минимум 2 броузера (дома и на работе). Да еще я имею свойство его обновлять. И перенастраивать. Просто ради инетереса. И уж тем более я не буду заниматься генерацией тонны "мусора" для того что бы запутать хакера Васю. Мое время стоит дороже работы с безопасными идиотами. А уж про передачу чего-то в GET я вообще молчу.
Тем более - что там нигде не говорится, что надо хранить в сессии "долгие" данные. Там идет речь про ограничение внутри одной сессии. И это - правильно (но не до такой же паранойи).

 

[SiMM]

Дмитрий Попов, удаление сессии, если ip не сошёлся, всего лишь повлечёт необходимость перезалогиниться пользователю. Думаю, делать это один раз за сеанс - не так утомительно для диалапщика, если уж его заботит безопасность. Конечно это не панацея (на одном ip может сидеть масса пользователей).

 

[camka]

Автор оригинала: Дмитрий Попов

Нет. С тех пор я вообще не храню паролей в первозданном виде. Нигде. А пользователю генерирую псевдослучайное число, md5-сумму которого я храню в базе. Что является по своей сути аналогом пароля. Только пользователь о нем ничего не знает.

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

В каждом своем последующем посте вы противоречите своим утверждениям в предыдущем.

Эта беседа уже удручает, посему предлагаю успокоиться. Торжественно клянусь не постить больше в этот топик.

 

[Дмитрий Попов]

camka

В каждом своем последующем посте вы противоречите своим утверждениям в предыдущем.

Пример?

И зачем тогда, спрашивается, бедняге codex'у советовать такие глупости, как в первом вашем посте

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

P.S. Первое противоречие: Единственное, каюсь, что в свете своей привычки, я отвлекся от понятия пароля, как от метода первичной авторизации. Забыл - ибо авторизацию с нуля не делал очень давно...

 

[ecto]

от снифера спасет только защищенное соединение - например ssl.

хранить пароль и пользователя в сессии глупо
аутентификация - и последующяа авторизация на каждой странице???
логично в сесси хранить уровень доступа (например).
После авторизации он изменятся.

хранить куку с номером сессии нужно до закрытия окна
(собственно по умолчанию она так и хранится)

на сервере пароль хранится в зашифрованном виде -
это риторический вопрос - смысл его - хозяин сервера не знает пароли пользователей.