Forum Webscript.Ru
Программирование => Perl => Тема начата: Yaroslav от 22 Июня 2006, 14:52:40
-
долго думал и искал способ безопасной авторизации и вот выношу на ваше обозрение следующее:
1. естественно идет сверка логина и пароля с данными на сервере
2. при каждой авторизации запускается код генирации случайного пароля, тоесть он будет все время новый.
3. логин и случайный пароль забиваются в хеш на сервере и в куки пользователю.
естественно что далее уже куки будут сверятся с временным паролем по логину.
очень прошу высказать ваше мнение.
кто знает способ луше также прошу поделиться
-
по-моему, ты описал какой-то аналог переменной сессии
-
а почему оно называется "безопасной"?
-
Greg
может быть, но с сесиями я знаком поверхносно...
и по сравнению с ними тут есть свою плюсы:
1. работа быстрее
2. результат работы сесий надо удалять, а тут нет :))
-
arto
а что опасное? :)
-
а что там именно безопасно?
-
arto
1. лучше чем передавать логин и пароль а куках
2. даже лучше чем передавать просто логин
3. и лучше чем передавать в зашифрованом виде
-
чем лучше? чем логин? :)
а если я перехвачу ваш хеш?
-
Yaroslav
зачем тут куки??????
есть переменные сеанса, почитай сначала про сессии и не пори лабуду
-
arto
это как же если он на сервере лежит?
и при следующем заходе данные будут переписаны
-
Greg
можно и без них, но с ними удобнее, дабы не прикреплять к каждой ссылке $login & $kod
-
"3. логин и случайный пароль забиваются в хеш на сервере и в куки пользователю."
-
а если я перехвачу ваш хеш?
это как же если он на сервере лежит?
и при следующем заходе данные будут переписаны
"3. логин и случайный пароль забиваются в хеш на сервере и в куки пользователю."
максимум - перехватишь случайный код в браузере юзера
но что с ним делать ведь незнаешь?
ну повесишь его себе в куки и пойдешь на главную страницу, где тебя попросят ввести правильный пароль, которого ты не знаешь :)
-
почему на главную?
-
arto
а куда еще?
хотя конечно да, если подсмотрел урл куда надо идти то можно будет зайти при условии:
1. вытащил с куков данные (которые я вешаю на хранение до конца сеанса)
2. повесил кук обратно. на своем апаче.
3. запомнил куда надо идти.
но такими же грехами страдает любая система авторизации
(если даже не больше)
-
arto
но тут можно сделать что б при каждой проверке менять этот код, таким образом шансы "взломать" будут еще меньше, ибо надо будет словить именно последний код.
-
1. снифферов полно.
2. а при чем тут apache?
3. если я станул куки, то скорее всего я стянул весь запрос.
чем ваше лучше?
-
если я ловлю все, то какая проблема с перехватом последнего запроса?
-
если ты стянул весь запрос то ты и пароль стянешь...
тем что это я сам сделал :) :)
-
ну если только...
-
есть одна идейка, писал уже о ней в какой то ветке.
Вобщем при авторизации на сайте, на основе некоторых постоянных заголовков(тип браузера, ип прокси, клиентских и т.д.), передаваемых клиентом на сервер формируется какое то число, это число заносится куда либо, можно просто создавать временный файл(с данным для конкретного пользователя), и удалять скриптом все файлы старее чем 15 минут (таймаут сессии). Особенностью данного способа является безопасность, заключенная в выборке заголовков и формировании числа. А снифером можно получить хоть что, но реально полезной инфы(логин, пасс, ид сессии, хэш) никто не увидит, заисключением самой авторизации.
-
а как вы будете разделять поддельный запрос от неподдельного?
-
arto
а ваши сударь предложения? :)
выдавать 128 битный ключ перед вводом логина и паса и закомпиленной джавой их шифровать перед передачей?
-
зачем?
для уверенности есть ссл, а все остальное для разводки инвесторов.
-
arto
ссл ещё надо купить...
-
смотря для чего.
-
arto
ИМХО спускаемся во флэйм...
-
почему?
авторизацию/аутентификацию не заводят ради нее самой, она должна решать какие-то задачи.
защита финансовых транзакций одно, а клиентские сессии для юзабилити другое.
предложение с постоянной сменой сессионного идентификатора не ведет к существенному поднятию безопасности, по сравнению с остальными методами, на незащищенном канале.
-
arto
слова красивые... давай уже конкретные предложения.. )
-
ssl -- не конкретно?
-
arto
понятно... - дальше будет флэйм.. )
-
как знаете
-
Зачем изобретать велосипед, не проще ли куки привязать к ип адресу (здесь могут быть два варианта - к примеру в профиле пользователя хранится IP адрес с которого можно залогинится, или при создании cookie набора в кукисы вносится информация об ip адресе, и при повторной авторизации с этими куками - проверяем соответствие ip в куках и ip клента. Здесь естессно формат записи ip-адреса в куках не должен быть plain/text.
Еще один интересный вариант авторизации - ключевой файл который требуется подгрузить на сервер для авторизации...
Но в любом случае - все это развалится если весь ваш трафик слушается, и arto прав - для финансовых систем необходим ssl, или...
в http можно инкапсулировать аналог https.
Такие разработки велись кое-где (к примеру форум -http://www.security-teams.net/index.php?showforum=26. а так же обсуждение здесь - http://poizon.net.ru/cgi-bin/ikonboard/ikonboard.cgi?act=ST;f=6;t=17 ) но это все относится в основном к конфидециальному общению, хотя кое-что можно и прикрутить для авторизации.
-
Мое личное мнение SSL - других вариантов пока нет :) С этого то форума с прокси перехватываются логин-пароль вообще в открытом виде перехватчиком траффика, и POST и кукисы. Как и с других форумах при логине. Да не только в форумах-аси, мылы и тд. Хорошо что я работаю в IT-мне то это не нужно ;) В понедельник когда на работу приду скриншот могу дать с Ethereal\'a с прокси-сервера ;) Браузер все равно посылает в открытую дату, если не имеет сертификата SSL...
-
совсем запутали.
что перехватчик трафика не сможет перехватить SSL?
что есть ваще это SSL?
где бы о нем почитать посоветуете?
-
можно начать отсюда: http://www.openssl.org/