В настоящее время в моей службе только для IPv4 пользователи могут занести свой IP-адрес в белый список, что позволяет им обходить двухфакторную аутентификацию электронной почты при входе в систему. Когда они это делают, мы заносим в белый список только этот единственный IP-адрес, поскольку предполагается, что каждый клиент ISP получает собственный IPv4-адрес (по крайней мере, в США).
Мы хотим включить поддержку IPv6, и после исследования того, как работает подсети IPv6, мы выяснили, что нам нужно внести в белый список всю подсеть IPv6, а не один адрес.
При поиске других вопросов IPv6 о сбое сервера обнаруживается противоречивая информация о том, какая подсеть делегирована каждому конечному пользователю интернет-провайдера. Видеть этот ответ:
/ 56: блок из 256 базовых подсетей. Несмотря на то, что текущие политики позволяют интернет-провайдерам раздавать блоки размером до / 48 каждому конечному пользователю и по-прежнему считают использование своего адреса вполне оправданным, некоторые интернет-провайдеры могут (и уже делают) выделить / 56 клиентам потребительского уровня в качестве компромисса. между распределением
/ 48: блок из 65536 базовых подсетей и рекомендуемый размер блока, который должен получить каждый конечный сайт клиента ISP.
Основываясь на этом ответе, уже есть 3 конфликтующих утверждения о том, какой блок IPv6 получает каждый пользователь:
Итак, какой блок IPv6 подходит для службы, в которой IP-адреса используются для внесения в белый список? Должен ли я позволить пользователю решать? (Пользователи достаточно хорошо разбираются в технологиях и знают, что такое подсеть)
Префиксы бывают разного размера, потому что разные организации имеют больше или меньше сетей, и некоторые оправдывают необходимость своего провайдера. В моей резиденции есть / 48 через туннель Hurricane Electric, просто нажав кнопку. (Хорошо, я не необходимость это, но все просто работает, если каждая из сетей Wi-Fi захватывает / 64.)
По сути, вы, кажется, относитесь к IP-адресу как к аутентификатору, но это не так. IP-адреса все время динамически переназначаются, покупаются и (неправильно) маршрутизируются.
Рассмотрите возможность использования двух факторов для первоначального входа в систему, но не последующих. (Используя существующий файл cookie, билет Kerberos или что-то еще.) Запросите один фактор аутентификации при изменении конфиденциальных настроек, или после нескольких дней отсутствия аутентификации, или если ваша система может обнаружить подозрительную активность в их учетной записи.
Для организации стандартизации США см. NIST 800-63B. IP-адрес не может считаться секретом аутентификатора или устройством. И максимальное время, в течение которого пользователь может пройти без повторной аутентификации, может составлять часы или дни. Если это соответствует вашим требованиям безопасности, вы можете оставить пользователя в системе всю неделю. Без белого списка IP-адресов.