информационная безопасность без паники и всерьез  подробно о проекте
			Анализ криптографических сетевых...   Модель надежности двухузлового...   Специальные марковские модели надежности...   Очередное исследование 19 миллиардов...   Оптимизация ввода-вывода как инструмент...   Зловреды выбирают Lisp и Delphi
	главная обзор RSN блог библиотека закон бред форум dnet о проекте
	bugtraq.ru / форум / programming		Имя Пароль

	если вы видите этот текст, отключите в настройках форума использование JavaScript

ФОРУМ
	все доски
	FAQ
	IRC
	новые сообщения
	site updates
	guestbook
	beginners
	sysadmin
	programming
operating systems
theory
web building
software
hardware
networking
law
hacking
gadgets
job
dnet
humor
miscellaneous
scrap
регистрация

Легенда:   новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение

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

		а если IP-шник принадлежит NAT-хосту, а за ним пол-сотни человеков которые к тебе лезут? ;0)) 20.04.04 17:28  Число просмотров: 1459 Автор: RazDolBai Статус: Member <"чистая" ссылка>
		<programming>

[Perl] авторизация без куки 21.03.04 18:26   Автор: !? <!?> Статус: Member <"чистая" ссылка>

subj... искал в нете, но тк ничего путного не нашёл, обращаюсь к господам шарящим кодЁрам ;) (это, типа, не лесть) мне нужно, чтобы авторизация передавалась в строке и не была валидна у другого человека, если даже он и узнает ключ. на данный момент я сделал очбанально: crypt($pass, crypt($login, $ENV{'REMOTE_ADDR'})) но хочу лучше) буду премногоблагодарен за советы, не ведущие на ya.ru...

	"пуленепробиваемая" аутентификация 17.04.04 08:15   Автор: !? <!?> Статус: Member <"чистая" ссылка>
	вот придумал ещё одну меру защиты: при авторизации привязывать к аккаунту его ip, и использовать его при аутентификации. про Log OFF'е, ясен пень, потирать :0). может ещё к чему привязать, для надёжности? :0)

		а если IP-шник принадлежит NAT-хосту, а за ним пол-сотни человеков которые к тебе лезут? ;0)) 20.04.04 17:28   Автор: RazDolBai Статус: Member <"чистая" ссылка>

			дык... привязка к броузеру+ http_x_forwarded_for :0) 21.04.04 03:16   Автор: !? <!?> Статус: Member <"чистая" ссылка>

				а мы не то же самое тут ровно месяц назад обсуждали? :) 21.04.04 03:53   Автор: dl <Dmitry Leonov> Отредактировано 21.04.04 03:54  Количество правок: 1 <"чистая" ссылка>
				Хэш с REMOTE_ADDRESS - достаточно надежная привязка к IP клиента.

					почти :). 21.04.04 04:15   Автор: !? <!?> Статус: Member <"чистая" ссылка>
					но при варианте, который получился тогда, можно было просто поискать на этом компе в хистори хэш и воспользоваться им. а вот если учесть логон/логофф, тогда и хэш ничего не даст. сейчас я включил поддержку логона/логоффа и в инфе состояния храню ip. а вопрос заключался в том, что тамлучшехранить. :) или этого достаточно и на тему можно забить? :)

						Хранить состояния сессии (логон/логофф с возможным... 21.04.04 04:32   Автор: dl <Dmitry Leonov> <"чистая" ссылка>
						> но при варианте, который получился тогда, можно было просто > поискать на этом компе в хистори хэш и воспользоваться им. > а вот если учесть логон/логофф, тогда и хэш ничего не даст. > сейчас я включил поддержку логона/логоффа и в инфе > состояния храню ip. а вопрос заключался в том, что там >лучшехранить. :) > или этого достаточно и на тему можно забить? :) Хранить состояния сессии (логон/логофф с возможным принудильным логофом по таймауту) - штука практически обязательная :) А вот хранить ip где-то еще помимо участия в формировании сессии несколько избыточно. Хуже от этого конечно не будет, но дополнительной защиты это практически не добавит - все равно при утаскивании на другую машину этот хэш ничем не поможет.

							ок. сЭнкс. буду хранить не ip а время последнего хита. 21.04.04 04:54   Автор: !? <!?> Статус: Member <"чистая" ссылка>

	чудес не бывает 21.03.04 21:06   Автор: dl <Dmitry Leonov> <"чистая" ссылка>
	Сессию можно строить только из того, что передает клиент. REMOTE_ADDR, HTTP_USER_AGENT, HTTP_ACCEPT_LANGUAGE, HTTP_ACCEPT, вот, пожалуй, и все, что можно использовать, если забыть о куках. Ну а уж каким способом это скрещивать с логином/паролем, это дело вкуса.

		так лучше? можёт ещё что добавить? 27.03.04 08:42   Автор: !? <!?> Статус: Member <"чистая" ссылка>
		#переменная $auth передаётся в строке видом login:hash @pairs = split(/:/, $auth); #... опеределяется $pass @g3tz= ($ENV{"REMOTE_ADDR"}, $ENV{"HTTP_USER_AGENT"}, $ENV{"HTTP_ACCEPT_LANGUAGE"}, $ENV{"HTTP_ACCEPT"}); foreach $g3tz (@g3tz) { foreach $p1 (split("", $g3tz)) { $auth0z+= ord($p1); } } print "¤", $auth0z, "¤", substr(crypt($auth0z, $pass), 2, 8), "¤", $pass, "¤"; if (@pairs[1] eq substr(crypt($auth0z, $pass), 2, 8)) { } #есть ещё предложения? (или жалко? :) )

			нормально 27.03.04 16:13   Автор: dl <Dmitry Leonov> <"чистая" ссылка>
			В принципе, можно еще добавить HTTP_X_FORWARDED_FOR, чтоб хоть немного снизить вероятность подсовывания идентификатора сессии с соседней машины в каком-нибудь дисплейном классе, где большинство настроек совпадает.

				добавил. грейт сЭнкс. 28.03.04 14:22   Автор: !? <!?> Статус: Member <"чистая" ссылка>

1

Copyright © 2001-2025 Dmitry Leonov

Page build time: 0 s

Design: Vadim Derkach