Впервые столкнулся с ситуацией, когда у одного из клиентов IP меняется каждые 10-30 секунд.
Видимо так странно настроен балансировщих выходных каналов у провайдера.

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

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

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

Здравствуйте, AndrewN, Вы писали:

AN>Впервые столкнулся с ситуацией, когда у одного из клиентов IP меняется каждые 10-30 секунд.
AN>Видимо так странно настроен балансировщих выходных каналов у провайдера.

AN>Из-за этого у клиента постоянно слетает сессия авторизации на одном из наших WEB ресурсов, клиент жалуется.
AN>Насколько общепринятым решением считается учёт адреса, с которого произошло подключение в параметрах сессии?

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

В общем это всё баланс между удобством использования и безопасностью. В интернет-банке это может иметь смысл. У обычного сервиса — имхо, нет. Я рекомендую подумать, какую цель собственно преследует фиксация IP-адреса, какую конкретно угрозу она пытается предотвратить, насколько эта угроза реальна для вашего случая и нет ли у злоумышленника других способов навредить вам в случае реализации этой угрозы. Думаю очевидно, что неудобство использования от такого решения вполне себе реально конкретно у этого пользователя и, вероятно, у многих других, которые просто не пишут вам.

Здравствуйте, AndrewN, Вы писали:

AN>Впервые столкнулся с ситуацией, когда у одного из клиентов IP меняется каждые 10-30 секунд.
AN>Видимо так странно настроен балансировщих выходных каналов у провайдера.

Начиная с HTTP 1.1 можно же не разрывать соединение с клиентом после запроса. Тогда и IP меняться не будет.

AN>Хочу понять, это всё-таки клиенту надо своего провайдера долбить, или мне менять принципы авторизации.
AN>Хотя по-моему сейчас большинство стандартных фреймворков учитывают IP адрес, с которого авторизация происходит, в сессионном ключе.

Только у Сбербанка-онлайн замечал такое. Стоит переключиться на VPN или наоборот отключить, сразу сессия слетает. Обычно ключ сессии в куках хранят.

Здравствуйте, AndrewN, Вы писали:

AN>Из-за этого у клиента постоянно слетает сессия авторизации на одном из наших WEB ресурсов, клиент жалуется.
AN>Насколько общепринятым решением считается учёт адреса, с которого произошло подключение в параметрах сессии?

Я бы не стал привязываться к IP адресу. Какой в этом смысл? А что, если у меня динамический адрес, и он перейдет другому пользователю, то и сессия моя ему перейдет?

Здравствуйте, AndrewN, Вы писали:

AN>Впервые столкнулся с ситуацией, когда у одного из клиентов IP меняется каждые 10-30 секунд.
AN>Видимо так странно настроен балансировщих выходных каналов у провайдера.

Т.е. речь про публичный маршрутизируемый IP? По идее, такое может быть, если едешь в поезде или машине и переключаешься с вышки на вышку (или как умеют современные сотовые, перескакивать между WiFi-хотспотами и мобильной сеткой.

Здравствуйте, AndrewN, Вы писали:

AN>Из-за этого у клиента постоянно слетает сессия авторизации на одном из наших WEB ресурсов, клиент жалуется.

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

Здравствуйте, Mr.Delphist, Вы писали:


MD>Т.е. речь про публичный маршрутизируемый IP? По идее, такое может быть, если едешь в поезде или машине и переключаешься с вышки на вышку (или как умеют современные сотовые, перескакивать между WiFi-хотспотами и мобильной сеткой.

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

Видимо будем убирать привязку сессий к IP

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Здравствуйте, AndrewN, Вы писали:

AN>>Из-за этого у клиента постоянно слетает сессия авторизации на одном из наших WEB ресурсов, клиент жалуется.

ЕМ>Хм, мне всегда казалось, что веб-сеанс в пределах сеанса работы браузера идентифицируется какой-то сеансовой информацией браузера (подробно в это не вникал), но никак не IP-адресом клиента. Если у клиента произошел разрыв соединения, и он подключился с другим IP, не закрывая браузера (или вкладки) — сервер должен его опознать. И только если браузер закрывался, остается лишь возможность опознания по кукам.

Попробуйте так подключиться к любому онлайн банку и потом поменять IP.
Хотя в случае с онлайн банкингом возможно это и оправдано

Здравствуйте, AndrewN, Вы писали:

AN>Попробуйте так подключиться к любому онлайн банку и потом поменять IP.
AN>Хотя в случае с онлайн банкингом возможно это и оправдано

Чем оправдано? При работе через HTTPS вся идентификация должна выполняться по ключам. При правильной реализации протокола смена IP не создает никаких рисков.

Здравствуйте, AndrewN, Вы писали:

AN>Попробуйте так подключиться к любому онлайн банку и потом поменять IP.

И что будет? Зачем им нужен IP, разве что для логгирования и последующего расследования в случае чего.

Здравствуйте, AndrewN, Вы писали:

AN>Т.е. люди сидят в офисе внутри организации — подключаются к внешнему ресурсу, и для этого ресурса выглядит, что каждый запрос приходит с нового адреса из некоторого пула адресов.

А, вот оно как. Тут да, надо смотреть что там за маршрутизатор — может быть и самопал на основе какой-то линукси, или невменяемо сконфигурённая циска или микротик и т.п.

AN>Видимо будем убирать привязку сессий к IP

Да, надо убирать. Главное чтобы сессионные данные в урле тогда у вас не выставлялись наружу (иначе любой сграбивший урлу сможет угнать и сессию).

Здравствуйте, AndrewN, Вы писали:

AN> Насколько общепринятым решением считается учёт адреса, с которого произошло подключение в параметрах сессии?

Учитывать не нужно и даже вредно. Разве что дать параноикам возможность включить себе этот учет где-нибудь в параметрах профиля, но по умолчанию должно быть отключено. Смена адреса есть вполне себе штатная ситуация (например, обычный NAT).

Здравствуйте, AndrewN, Вы писали:

AN>Видимо будем убирать привязку сессий к IP

Как вариант: сделайте это опциональной галочкой в настройках пользователя. Кому надо, те уберут.

Здравствуйте, AndrewN, Вы писали:

AN>Насколько общепринятым решением считается учёт адреса, с которого произошло подключение в параметрах сессии?

Это вредная стратегия. IP адрес отражает всего лишь физический аспект подключения, но не логический! А сессия пользователя это как раз логическая сущность.

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

Просто ставьте cookie с токеном сессии.

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Чем оправдано? При работе через HTTPS вся идентификация должна выполняться по ключам. При правильной реализации протокола смена IP не создает никаких рисков.

Технически HTTPS позволяет идентифицировать клиента по клиентскому сертификату, но на практике в вебе эта возможность почти не используется.

Здравствуйте, Sharov, Вы писали:

AN>>Попробуйте так подключиться к любому онлайн банку и потом поменять IP.

S>И что будет? Зачем им нужен IP, разве что для логгирования и последующего расследования в случае чего.

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

Здравствуйте, Pzz, Вы писали:

Pzz>Я как-то поменял сим-карту в телефоне на другую карту того же оператора и с тем же номером. Так вот, ситибанк это каким-то образом прочухал, и мне пришлось отдельным телодвижением убеждать их, что это по-прежнему я. Причем мобильным банкингом я у них не пользовался, только СМСки получал и изредка с ними голосом разговаривал.
Это никакого отношения к смене IP не имеет. Нормальная, правильная мера. Потому что замена симкарты — это очень популярный способ угона банковского аккаунта.

Здравствуйте, Sinclair, Вы писали:

Pzz>>Я как-то поменял сим-карту в телефоне на другую карту того же оператора и с тем же номером. Так вот, ситибанк это каким-то образом прочухал, и мне пришлось отдельным телодвижением убеждать их, что это по-прежнему я. Причем мобильным банкингом я у них не пользовался, только СМСки получал и изредка с ними голосом разговаривал.
S>Это никакого отношения к смене IP не имеет. Нормальная, правильная мера. Потому что замена симкарты — это очень популярный способ угона банковского аккаунта.

Да я не спорю. Удивляюсь, как они пронюхали, что я сим-карту сменил.

Здравствуйте, Pzz, Вы писали:

Pzz>Да я не спорю. Удивляюсь, как они пронюхали, что я сим-карту сменил.

Гы-гы, Ватсон, это ж элементарно (ц)

Так там целая связка идентификаторов: IMEI для телефона, IMSI для абонента, ICCID для самой симки, не говоря уже про идентификаторы сотовых сетей, где регистрируется абонент, ключи шифрования в симке и т.п. Телефонный номер — лишь красивый human-friendly фасад поверх этого.

Всё это даёт очень широкое поле для аналитики (например, оператор может хранить список всех симок, которые когда-либо были вставлены в телефон, и сопоставив их с IMSI разных абонентов, понять что тут в Ваш телефон вставлена симка Вашего друга).

Здравствуйте, Mr.Delphist, Вы писали:

MD>Всё это даёт очень широкое поле для аналитики (например, оператор может хранить список всех симок, которые когда-либо были вставлены в телефон, и сопоставив их с IMSI разных абонентов, понять что тут в Ваш телефон вставлена симка Вашего друга).

Это не опсос пронюхал. Это банк пронюхал. Получается, что опсосы предоставляют банкам свои сугубо технические сведения о своих абонентах.

Здравствуйте, Pzz, Вы писали:

Pzz>Получается, что опсосы предоставляют банкам свои сугубо технические сведения о своих абонентах.

Не обязательно. Банки заключают с опсосами договоры на создание и поддержку "авторизованных" (обычно коротких) номеров. Там может предусматриваться фиксация ICCID на момент регистрации клиента в банке. Если клиент меняет симку, опсос может просто уведомить банк об этом факте, а банк уже решает, продолжать использовать этот номер для отправки кодов и прочего, или потребовать от клиента личного подтверждения.

Здравствуйте, Pzz, Вы писали:

Pzz>Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>>Чем оправдано? При работе через HTTPS вся идентификация должна выполняться по ключам. При правильной реализации протокола смена IP не создает никаких рисков.
Pzz>Технически HTTPS позволяет идентифицировать клиента по клиентскому сертификату, но на практике в вебе эта возможность почти не используется.
Я вклинюсь немного, но не напрямую чтобы с вами пообсуждать, а для топик-стартера, для разговора в контексте сертификатов и сессий.
В процессе обсуждения с сессий перешли к идентификации, это связанные, но несколько разные вещи. Возможно, вы имели в виду схему с аутентификацией по сертификату, используемую SSHD, но она предполагает что у вас есть доступ к серверу, что подразумевает, что вы отдаете себе отчет между компромиссом в удобстве и безопасности, контролируете обе стороны и понимаете, что если клиент будет взломан, то сервер тоже. Ну или копирование ключей клиента приведет к копированию пользовательской авторизации. Это более строгая задача, чем требуется, и она не заменяет требования контроля за сессией. Сессионный ключ для SSH генерируется на основе публичных ключей из сертификата, но не идентичен и не однозначен ему. То есть, с одного клиента может быть много сессий, что не идентифицирует сессию по клиентскому сертификату. Симметричный ключ, который генерируется для HTTPS сессии уже после рукопожатия как бы автоматически идентифицирует клиента, но всё это прокинуть до менеджера сессий — надо очень хорошо постараться. Эту штуку не зря прячут за всякими API, уж большо всё непросто там. И опять-таки, архитектурно притянуть зависимость к HTTPS, ну как бы оно не сильно кошерно.

Насколько я понимаю, в случае онлайн сервиса, для правильной идентификации клиента по его сертификату, нужно верифицировать клиентский сертификат, а это накладно с точки зрения вычислительных ресурсов, да и задержка может быть долгой — надо получить все сертификаты в цепочке, чтобы проверить подлинность конечного сертификата. Учитывая зоопарк клиентов и политик безопасности в разных организациях, это может быть нетривиально, особенно если сертификат подписан внутренним CA организации, к которому нет доступа извне. Или же сделать в другую сторону и выдать клиенту сертификат, который тот должен использовать. Вот слегка написано про mutual trust aka mutual authentication
Ну даже если мы упростим строгость и не будем валидировать сертификат, а просто использовать его хэш как идентификатор. Один и тот же сертификат может быть использован на разных клиентах, например, у нас виртуальная машина, которую мы клонировали пару-тройку раз. Если открыть с них сессии до одного и того же сервера, то может получиться конфуз.
Опять-таки есть Single Sign On, который не отменяет необходимости контроля за сессией, но позволяет упростить аутентификацию пользователя между разными сервисами.

Поэтому выбран разумный компромисс: сервер под нашим контролем и сертификат мы используем подписанный известным CA с короткой цепочкой до рута — это чтобы клиенту было проще. Клиент идентифицируется более удобным способом типа логин+пароль или специальным ключом, генерированным на их основе (типа RSA hardware token).
Я попытался дать идею, что не все так просто с идентификацией по клиентскому сертификату.

Дальше вступает в игру сессия. Сервер генерирует клиенту сессионный идентификатор/токен. Дальше вопрос как ими обмениваться. Часто клиент посылает его с каждым запросом к серверу в заголовке запроса. Если клиент — браузер, то используем URL или cookies. И все это зашифровано через HTTPS или TLS. Для пущей надежности необходимо также верифицировать этот ID/key другим способом, но это сложно. Для URL это более актуально, так как пользователь может выслать URL другому и даже если мы шифруем URL при общении через HTTPS, то он все равно может утечь. Ну и куки могут быть украдены через XSS, но это уже наша забота на сервере, чтобы предотвратить. Куку можно прочитать через через взлом файловой системы или тот же XSS, ну и пр. Но нам надо где-то провести черту параноидальности.
В итоге все это не гарантирует на 100%, но дает достаточно хорошую защиту. Для особых случаев типа банков и пр, ID может выдаваться на каждый запрос. Тайм-аут сессии достаточно небольшой, ну и прочая. Тут опять хороша отвязка от HTTPS/TLS сессии и его ключа, поскольку тот тайм-аут задается на другом уровне, и т.д.

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

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Здравствуйте, AndrewN, Вы писали:

AN>>Попробуйте так подключиться к любому онлайн банку и потом поменять IP.
AN>>Хотя в случае с онлайн банкингом возможно это и оправдано

ЕМ>Чем оправдано? При работе через HTTPS вся идентификация должна выполняться по ключам. При правильной реализации протокола смена IP не создает никаких рисков.
Давайте разнесём сессии онлайн банка и сетевые соединения.
Смена IP сбрасывает соединение из-за создания нового сокета (Берклиевские сокеты — 5-tuple: (IP+port)*2+protocol). HTTPS растет сверху сокета, соответственно HTTPS соединение тоже разрывается.
Переживет ли банковская сессия переустановление HTTPS соединения — это другой вопрос. Есть TLS Session resumption, которую HTTPS может использовать и тогда HTTPS сессия переживет разрыв HTTPS соединения. Не знаю, используют ли браузеры это, возможно да. Сервер должен это поддерживать тоже, чтобы оно работало.

Здравствуйте, WPooh, Вы писали:

WP> Если открыть с них сессии до одного и того же сервера, то может получиться конфуз.

В чем этот конфуз будет выражаться?

Здравствуйте, Sharov, Вы писали:

S>Здравствуйте, WPooh, Вы писали:
WP>>Один и тот же сертификат может быть использован на разных клиентах, например, у нас виртуальная машина, которую мы клонировали пару-тройку раз. Если открыть с них сессии до одного и того же сервера, то может получиться конфуз.
S>В чем этот конфуз будет выражаться?
Ну зависит от множества деталей, но если таки используется один и тот же сертификат для двух разных клиентов, то их сессии сольются вместе, даже если пользователи разные. Конфуз? Чаще да, чем нет.

Это возможный сценарий. Я во все детали не углублялся, но выбор клиентского сертификата из набора доступных — это некоторая задача, решаемая несколькими способами. Например, браузер может спросить пользователя, какой из установленных на машине сертификатов использовать для соединения. Либо сервер высылает список CA которым он доверяет, тогда выбор может быть сделан автоматически, и т.д.
Но главное — склонировали виртуалку, или установили одинаковый сертификат для разных пользователей, и если этот сертификат использовался двумя разными пользователями, то оба пользователя попадут в одну и ту же сессию.
Это если мы привязываем сессии к клиентским сертификатам, о чем и шла речь выше.
Оно может и работать, если у вас специальный клиент (не браузер) и вы генерируете самоподписанные сертификаты или раздаете их централизованно и привязываете к адресу или какому-то ID чтобы клонов отличить, и т.д., но речь шла про общий случай, который можно разрулить более просто без возни с клиентскими сертификатами.

AN>Впервые столкнулся с ситуацией, когда у одного из клиентов IP меняется каждые 10-30 секунд.
AN>Видимо так странно настроен балансировщих выходных каналов у провайдера.

AN>Из-за этого у клиента постоянно слетает сессия авторизации на одном из наших WEB ресурсов, клиент жалуется.
AN>Насколько общепринятым решением считается учёт адреса, с которого произошло подключение в параметрах сессии?

Этой проблеме уже больше 20-ти лет (когда на один и тот же IP сервера один и тот же клиент попадает с разных IP адресов и в результате пропадает авторизация, например, из-за того, что NAT у провайдера настроен на пул адресов и для каждого нового подключения IP может выдаваться разный). Кажется, неприятности с авторизацией, когда у клиента меняется IP были еще у ICQ98 (лучшая версия). В результате все квалифицированные сетевые админы делали так, чтобы для каждого диапазона IP клиентов выдавался единственный IP в NAT (что создавало некоторые неудобства, зато ICQ и другие похожие приложения у всех работали надежно), а квалифицированные разработчики серверных приложений не привязывались к IP клиента, либо делали галочку при авторизации, чтобы привязка была опциональной по желанию пользователя (тут, наверное, тоже могут быть мелкие неудобства).

Однако, похоже, еще не до всех дошло, что привязка к IP клиента создает неудобства...

Кстати, а что будешь делать, если клиент с мобилкой вышел из офиса и переключился с WiFi на GSM (там IP поменяется в 99,999% случаев и клиенту это будет неудобно)?

AN>>Из-за этого у клиента постоянно слетает сессия авторизации на одном из наших WEB ресурсов, клиент жалуется.

ЕМ>Хм, мне всегда казалось, что веб-сеанс в пределах сеанса работы браузера идентифицируется какой-то сеансовой информацией браузера (подробно в это не вникал), но никак не IP-адресом клиента. Если у клиента произошел разрыв соединения, и он подключился с другим IP, не закрывая браузера (или вкладки) — сервер должен его опознать. И только если браузер закрывался, остается лишь возможность опознания по кукам.

Там авторизация идет по кукам и по IP. Расчет на то, что если у тебя украдут куки, то IP у злоумышленника будет другой и он не сможет у тебя украсть деньги из банк-клиента, например. Такое вполне работает для разных банковских программ или еще чего-то с ценными ресурсами (в панелях хостеров такое раньше было). Работает при условии, что твой внутренний IP NAT'ится на единственный IP (на офисном шлюзе, например). Если же ты работаешь из дома, где у тебя приватный IP, а у твоего домашнего провайдера настроено, что все домашние пользователи (тыщь 100) оптом NAT'ятся на пул адресов xxx.xxx.xxx.0/23, то есть шанс, что каждое новое tcp подключение будет исходить с нового IP.