Покритикуйте алгоритм авторизации

← →
UserInet777 (2009-04-15 07:09) [0]

Задача - сделать максимально простую и надежную авторизацию пользователей на сайте. чтобы не заводить сессии и т.д.

самое простое что приходит на ум - просто в куки записывать пароль и имя пользователя, но это слишком небезопасно (как делается в "стандартной" авторизации Apache htaccess)

Так вот моя идея чтобы на сервере делать:

ID= MD5(IP + User Agent + ник + пароль) и посылать этот ID в куки при логине .

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

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

Минусы - возможная криптографическая неустойчивость MD5 - тут я ничего про это не знаю и прошу совета у знающих в этом)

← →
UserInet777 (2009-04-15 07:13) [1]

ой самое главное - перед ip еще вставлять "secret string" чтобы перебором нельзя было получить пароль

secret string = "ramtSC2g0hkvqd51X7EFwy6ZL"; (известно тока серверу)

ID= MD5(secret string + IP + User Agent + ник + пароль)

← →
test © (2009-04-15 08:01) [2]

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

← →
test © (2009-04-15 08:45) [3]

Впрочем если защита паролем особо не нужна то можно так и оставить.

← →
tButton © (2009-04-15 08:51) [4]

> то он тоже определиться как правильный

по идее - нет
поскольку ИД включает в себя ИП машины
я бы еще добавил имя удалённого хоста
потому что ип может совпасть (при определенных условиях)

← →
DVM © (2009-04-15 09:05) [5]

> UserInet777

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

← →
tButton © (2009-04-15 09:30) [6]

re [5]
не факт, иногда проще заполучить базу паролей
и через веб-интерфейс спокойно делать то что надо
хотя для полученя пароля проще использовать связку троян+соц.инжиниринг

← →
tesseract © (2009-04-15 10:01) [7]

> не факт, иногда проще заполучить базу паролей

И восстанавливать их по хэшам? Не очень эффетивно, перебор на "123" и "07071987" как правило быстрее.

← →
antonn © (2009-04-15 15:16) [8]

на всякий - http://www.php.ru/forum/viewtopic.php?t=17779 (и там по тому подфоруму вдруг еще чего полезное найдется)

на клиенте в куках пишется user_id (число), соль (md5 от времени, рандома и тп, просто случайная фигня), и хеш md5, который формируется на основе user_id, соли, useragent, remote_ip и еще хрен знает чем на сервере. Возможно добавлять некую уникальную соль хранимую в таблице юзеров на сайте и так же ее использовать. Таким образом, на клиенте не хранится и намека на пароль пользователя. Но поддерживается "автоматически входить на сайт" с разных машин и браузеров (в случае с динамическим IP придется его не трогать) с такой кукой.

← →
UserInet777 (2009-04-15 16:28) [9]

DVM ©

> Почему боитесь хранить на сервере кое-какие данные?

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

test ©

> Если твой кук скопируют на другую машину то он тоже определиться
> как правильный?

нет конечно, другой IP и с этим куком зайти уже не смогут

tButton ©

> я бы еще добавил имя удалённого хостапотому что ип может
> совпасть (при определенных условиях)

а это идея, спасибо за совет

← →
UserInet777 (2009-04-15 16:29) [10]

antonn ©
спс гляну

← →
DVM © (2009-04-15 16:44) [11]

> UserInet777 (15.04.09 16:28) [9]

> не боюсь, но хотелось бы упростить для снижения нагрузки
> на сервер и упрощения кода скрипта

Мне кажется напрасно, загрузка сервера этими вещами просто ничтожная, а вот код скрипта скорее усложнится, чем упростится имхо.

← →
Ega23 © (2009-04-15 16:51) [12]

А чем сессии не нравятся?

← →
stas © (2009-04-15 17:05) [13]

Ega23 © (15.04.09 16:51) [12]
на SQL.RU читал по этому поводу целые дебаты что использовать сессию или куки. Там и там есть достоинства и недостатки с точки зрения уязвимости.
Я в начале использовал сессию, но это в итоге не подошло т.к. хостер тупо рубил сессию через 2 минуты...

← →
Ega23 © (2009-04-15 17:15) [14]

> Я в начале использовал сессию, но это в итоге не подошло
> т.к. хостер тупо рубил сессию через 2 минуты...

Ты из-за компа ушёл, а кто-то за тебя делов понаделал...

← →
antonn © (2009-04-15 19:23) [15]

сессия хранится в куках (или переменная в GET/POST, если куки не поддерживаются), т.ч. все равно что там держать :)

← →
UserInet777 (2009-04-16 00:58) [16]

Ega23 ©

> А чем сессии не нравятся?

они иногда криво настроены у хостеров и не хочется возиться с ними.

поэтому такая идейка с MD5
данные некритичные и слишком навороченную авторизацию делать нет смысла, сперва хотелось использовать htaccess но там совсем уж незащищено)

← →
tButton © (2009-04-16 01:19) [17]

> И восстанавливать их по хэшам?

с полпинка
обширные базы MD5 хешей уже есть =)
при желании их можно найти

← →
имя (2009-04-16 01:23) [18]

Удалено модератором

← →
UserInet777 (2009-04-16 04:31) [19]

> Ты из-за компа ушёл, а кто-то за тебя делов понаделал...

кнопка выхода будет ))

> tButton ©

а добавление большой "секретной" строки в начало должно же сделать невозможным перебор или восстановление хеша? (при условии что потенциальный атакующий не будет знать строку)

> невозможным перебор или восстановление хеша?

http://ru.wikipedia.org/wiki/MD5#.D0.9F.D1.80.D0.B8.D0.BC.D0.B5.D1.80.D1.8B_.D0.B8.D1.81.D0.BF.D0.BE.D0.BB.D1 .8C.D0.B7.D0.BE.D0.B2.D0.B0.D0.BD.D0.B8.D1.8F

> а добавление большой "секретной" строки в начало должно
> же сделать невозможным перебор или восстановление хеша?

при возможности узнать эту соль - все равно :)

> а добавление большой "секретной" строки в начало должно
не должно =)
имея две результативных строки можно вычислить секретную
другое дело - использовать её в качестве ключа

← →
Кщд (2009-04-16 14:41) [23]

>UserInet777 (15.04.09 07:09)
пытаетесь выдумать кривобокий аналог digest auth)

← →
b z (2009-04-16 15:52) [24]

Если всякий раз авторизоваться, все-равно что не иметь авторизацию. :)

Покритикуйте алгоритм авторизации Найти похожие ветки