Здравствуйте, 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.