нужно ли хранить пароль в сессии

[craz]

блин храните в куке пожалуйста только auth = true, а? Я вам реально говорю с таким подходом скоро будет страшно из дома в интернет выходить! У меня не мильон паролей.

 

[Духовность™]

Духовность™.... без id.

как это, без ID? А как же вы тогда ищите пользователя?

А зачем там секретное слово?

на всякий случай. Если я знаю, что вы используете часто связку логина и пароля 555:555, то что бы получить доступ к вашему аккаунту мне достаточно будет послать md5('555' . md5('555')) и ID вашего аккаунта, который виден в 99% приложений. С секретным словом - никогда.

 

[Духовность™]

а дальше только md5 (разве его нельзя точно так же расшифровать, если поймать снифером?

md5 нельзя расшифровать, его можно подобрать перебором с заранее приготовленным словарем из популярных слов (паролей). Я не думаю, что кто-то когда-то сможет подобрать строку вида "555555dcdc35687989sdcsd", не говоря уже о более сложных комбинациях логина и пароля, нежели 555.

 

[inkz]

Духовность™

как это, без ID? А как же вы тогда ищите пользователя?

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

Вроде бы видел разные сервисы онлайн-расшифровки md5, сейчас проверил - более менее сложные комбинации и правда им не по зубам.

 

[Духовность™]

Опять таки не знаю насколько это рационально, но получается, что в куках хранится только это хэшированное поле.

Не рационально. Это бессмысленно - хранить избыточные данные - хэш от того, что можно сгенерировать в программе. Плюс выборка по первичному ключу - не нужно на дополнительное поле ставить индекс.

 

[Alien85]

Вы сами себе усложняете жизнь, используйте сессии! В куке будет храниться только SID.

Для автовхода используйте такой вариант: id пользователя + md5( mt_rand() . session_id() )
например: 52_fahjawtewryte5y5y45sdgs
эту строчку зашифровываем функцией

функция шифрования:

function encryptCookie($value){
	if(!$value){return false;}
	$key = 'тут секретное слово';
	$text = $value;
	$iv_size = mcrypt_get_iv_size(MCRYPT_RIJNDAEL_256, MCRYPT_MODE_ECB);
	$iv = mcrypt_create_iv($iv_size, MCRYPT_RAND);
	$crypttext = mcrypt_encrypt(MCRYPT_RIJNDAEL_256, $key, $text, MCRYPT_MODE_ECB, $iv);
	return trim(base64_encode($crypttext)); //encode for cookie
}

функция расшифровки:

function decryptCookie($value){
	if(!$value){return false;}
	$key = 'тут секретное слово';
	$crypttext = base64_decode($value); //decode cookie
	$iv_size = mcrypt_get_iv_size(MCRYPT_RIJNDAEL_256, MCRYPT_MODE_ECB);
	$iv = mcrypt_create_iv($iv_size, MCRYPT_RAND);
	$decrypttext = mcrypt_decrypt(MCRYPT_RIJNDAEL_256, $key, $crypttext, MCRYPT_MODE_ECB, $iv);
	return trim($decrypttext);
}

зашифрованную строчку пихаем в куку. Потом, когда пользователь приходит и сессии для него нет, а кука с автовходом есть - расшифровываем куку и пробуем поделить строчку: explode('_', $cookie); - если поделилось нормально (массив из 2-х строк) - получим ID и случайный хеш пользователя, по этим данным проверяем, существует такой или нет.

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

 

[MiksIr]

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

 

[Alien85]

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

каков ваш вариант авторизации и автовхода?
и никто не предлагал хранить хеш от пароля в печеньях... так же как никто не говорил, что автовход - это легко.

 

[MiksIr]

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

ЗЫ: хеш от пароля = хеш от набора данных, в который входит и хеш от пароля хранимый в базе

 

[Духовность™]

Вы сами себе усложняете жизнь

$crypttext = base64_decode($value); //decode cookie
$iv_size = mcrypt_get_iv_size(MCRYPT_RIJNDAEL_256, MCRYPT_MODE_ECB);
$iv = mcrypt_create_iv($iv_size, MCRYPT_RAND);
$decrypttext = mcrypt_decrypt(MCRYPT_RIJNDAEL_256, $key, $crypttext, MCRYPT_MODE_ECB, $iv);

ОМГ

 

[Alien85]

ЗЫ: хеш от пароля = хеш от набора данных, в который входит и хеш от пароля хранимый в базе

Пароль: 32 символа + логин: 20 символов + секретное слово 20 символов = 72 символа. Думаете надежно хранить пароль входа на сайт из 72 символов в хеше из 32?

интересно, как остальные делают авторизацию с автовходом?

Духовность™, смешного ничего тут нет, просто прячем ID пользователя, функция то простецкая.

 

[MiksIr]

Пароль: 32 символа + логин: 20 символов + секретное слово 20 символов = 72 символа. Думаете надежно хранить пароль входа на сайт из 72 символов в хеше из 32?

Думаю да. А что именно вас смущает?

 

[Alien85]

Давайте по существу.

Что дает мой метод:
1. У пользователя хранятся 2 куки: SID - хеш php и Memory - зашифрованная строка: user_id+random. Уникальность кук гарантирована PHP и mcrypt.
2. Если человек у друга зашел на сайт и забыл выйти, случайно установив "Запомнить меня", при входе на сайт со своего компьютера, он автоматом выйдет с компьютера друга, т.к. сгенерится новая строчка Memory.
3. Т.к. используются сессии, в большинстве случаев можно не запрашивать из БД информацию о пользователе на каждой открытой странице (id, ip, имя, возраст и т.п.)
4. Если сессия существует и в ней есть переменная $_SESSION['auth'] = TRUE; - значит пользователь вошел на сайт, что может быть проще? - использовать можно в любом php файле.
5. Если вор украдет SID - ему это ничего не даст, т.к. проверяется IP.
6. Если вор украдет Memory, то сможет пользоваться сайтом только до тех пор, пока не войдет настоящий пользователь. После чего Memory сменится вновь, т.к. имеет случайную составляющую.
7. При использовании отдельного сервера для статики, можно авторизоваться на нем с помощью дополнительного случайного хеша в БД (как Memory).

Минусы моего метода:
1. Используется mcrypt, но теоретически, можно обойтись и без него.
2. Несколько усложняется реализация класса авторизации (не проверки, что пользователь вошел, а процесс входа).
3. Если данные о пользователе не запрашиваются каждый раз из БД, соответственно выбросить пользователя с сайта будет затруднительно.


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

 

[MiksIr]

2. Как правило не нужно и вредно. Я хочу пользоваться сайтом дома и на работе, не вводя каждый раз пароль. Но если есть такая необходимость - решается дополнительным апдейтом в базу в таблицу пользователя, типа последний ключ, который так же можно мешать в хеш.
3. Ну да, как сами сказали, это может стать минусом.
4. "использовать можно в любом php файле" - тут не говнокодят
5. Мешаем IP в хеш - тот же результат.
6. п.2.
7. Вообще не имеет отношения к теме, решается отдельно.

Лучше - простотой и понятностью и консистентностью (проверкой пользователя и смены его пароля). Хуже - ну да, придется делать запрос в базу на юзера. Только нужно понимать, что на больших сайтах очень быстро перестают использовать встроенный механизм сессий и используют свой, так что это преимущество может стать недостатком. Кстати, некоторые данные, например то же имя, можно хранить в куках - совершенно не критично по безопасности, зато очень помогает при кешировании в статику.
Ну для небольших сайтов можно тупо пользоваться _SESSION, ага, и хранить в базе на пользователя последнюю заведенную сессию, если требуется п.2, т.е. выкидывание с других компов. Зачем нужна эта ваша вторая криптованная строчка - я до сих пор не понял.

 

[Alien85]

2. Как правило

где вы эти правила нашли?

в вашем подходе пользователи отдельно, сайт отдельно, впринципе это нормально, но не мой метод.

последний ключ, который так же можно мешать в хеш

5. Мешаем IP в хеш - тот же результат.

нарушается целостность данных. От того, что вы все подряд намешаете лучше никому не станет.

4. "использовать можно в любом php файле" - тут не говнокодят

словечко то какое подобрали! простой пример: ajax.php - отдельный файл, который должен без дополнительных накладных расходов выдать информацию. авторизация в нем не нужна, но знать, пользователь вошел на сайт или нет - нужно. или вы запихаете туда весь движок?

6. Если вор украдет Memory

6. п.2.

2. Как правило не нужно и вредно

интересная позиция...

на больших сайтах очень быстро перестают использовать встроенный механизм сессий и используют свой

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

ну вот, еще кеширования тут не хватает. это уже личное дело каждого. и ID пользователя вы тоже в куках хранить будете?

Зачем нужна эта ваша вторая криптованная строчка - я до сих пор не понял.

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

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

 

[MiksIr]

где вы эти правила нашли?

В здравом смысле. А так же в 99% ресурсов, которые требуют авторизации. Я ими пользуюсь с нескольких компьютеров без проблем и постоянных логинов. Проснитесь.

нарушается целостность данных. От того, что вы все подряд намешаете лучше никому не станет.

Лолчто? Какая такая "целостность данных" внутри хеша? Лучше станет. Гораздо. Вы попробуйте

простой пример: ajax.php - отдельный файл, который должен без дополнительных накладных расходов выдать информацию. авторизация в нем не нужна, но знать, пользователь вошел на сайт или нет - нужно. или вы запихаете туда весь движок?

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