Впервые столкнулся с ситуацией, когда у одного из клиентов 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 разных абонентов, понять что тут в Ваш телефон вставлена симка Вашего друга).

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