Владимир Дубровин

На практике в современных браузерах этот вектор в XSS не эксплуатируется из-за URI энкода. Последними популярными браузерами где этот вектор был эксплуатируем были IE 6/7, они не URI-енкодили GET-параметры при редиректе. Однако вставка URI без HTML-енкода в любом случае является ошибкой, даже если не приводит к XSS, например по стандарту должен HTML-енкодиться символ &, который может присутствовать в урлах.

Желательно отфильтровать весь трафик к защищаемому хосту сделав исключение для cloudflare, особенно если высока вероятность DDoS атак. Это есть в рекомендациях Cloudflare. Если этого не сделать, то действительно высока вероятность что IP адрес можно будет обнаружить и атаковать в обход Cloudflare. Например shodan или аналогичные сканеры могут идентифицировать хост по SSL-сертификату или ответу по дефолтному хостнейму, или на сайте может быть функциональность которая делает запрос с сайта наружу (наприме загрузка картинки по URL) с его реального IP в обход Cloudflare.

Windows хранит NT-хеши паролей, "расшифровать" их в открый текст нельзя, можно только сбрутить. Сравнить их с базой haveibeenpwned не получится, т.к. формат хешей разный. А если вы их сбрутите, то сравнивать не имеет смысла - раз вы смогли сбрутить, значит пароль заведомо плохой, поэтому можете их просто побрутить.

Смотрите не в сторону дампа паролей, а в сторону механизма passfilt.dll - он позволяет проверять пароль в открытом тексте в момент когда его меняет пользователь, в этот момент вы можете проверить стойкость пароля в т.ч. по базе haveibeenp0wned и по словарям. Напишите свою библиотечку passfilt.dll или поищите готовую, подключите и инициируйте смену пароля пользователям.

Вариантов довольно много, например JWS - каждый сервис выдает пользователю подписанный токен в который "зашита" информация о пользователе в сервисе. Схема может быть, например, такой
Сервис 1 выдает JWS1 авторизованному пользователю
Пользователь приходит с JWS1 в сервис 2, сервис 2 видит что пользователь авторизован в Сервис 1 и те данные которые сервис 1 подписал, дополнительного межсервисного взаимодействия при этом не требуется.
При необходимости межсервисного взаимодействия между сервисами дополнительно делается разделяемый секрет
Сервис 2 делает межсерверный запрос в Сервис 1 с секретом сервиса и JWS1. Таким образом сервис 2 может делать запросы только по тем пользователям, которые в него пришли

Есть два вида отечественных сертификатов:
1. Сертификаты с криптографией по ГОСТ (признаются как криптографическая защита) - сертификат выдается одним из аттестованных центров, поддерживается в Яндекс Браузер с установленным CryptoPro, криптография не совместима с международными стандартами.
2. Сертификаты Национального Удостоверяющего Центра - можно получить через Госуслуги, совместимы с международными стандартами и поддерживаются в любых браузерах, но только в российских браузерах (Яндекс Браузер, Атом) корневой удостоверяющий центр добавлен в доверенный, в остальных придется это сделать вручную.

Такой подход нарушает принцип Кергофса. Взломать ваш алгоритм можно двумя способами:
1. Подобрав алгоритм генерации, это можно сделать, например, перебирая функционалы составляющие функцию вашего алгоритма.
2. В вашем варианте алгоритм к тому же не устойчив к known plaintext атакам. Предположим Алиса передает Бобу сообщение которое известно атакующему - тогда зная это сообщение и проксорив его с "шифрованым" текстом можно получить сгенерированную последовательность и в дальнйшем дешифровать любое сообщение, поэтому в современные алгоритмы обязательно вносится обратная связь и/или какой-нибудь nonce.

P.S. предположу, что вы пытаетесь переизобрести потоковый шифр

Никогда не городите самопальной криптографии и методов авторизации, если вы не криптограф и не appsec-специалист соответственно, используйте стандартные подходы и проверенные библиотеки. В вашем случае надо использовать HTTP basic-авторизацию и стандартные механизмы которые ее реализуют.

Вы (или атакующий) можете сконфигурировать себе в качестве PTR или указать в запросе к серверу любой домен/поддомен/имя, в т.ч. не существующие.

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

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

Скорей всего, у вас нет доверию к сертификатам ISRG Root X1 / ISRG Root X2, обновите системный список корневых сертификатов или вручную установите корневые сертификаты Let's encrypt в корневые доверенные.

DST Root CA X3 экспайрится в сентябре, поэтому для новых сертификатов его больше не используют.

NTFS поддерживает шифрование файлов и можно поставить галочку "шифрованная" на папку, тогда все файлы в этой папке будут шифроваться.
Но то, какой метод для вас лучший зависит от того, как вы работаете с файлами и папками и от каких атак вы хотите защититься. Если порнуху спрятать от мамы, это одно, если какие-то данные от госструктур которые могут диск изъять - совсем другое, и одним шифрованием папок скорей всего не устраняется.

Вроде все написано. Эта сигнатура требует поддержки JA3, которая не включена. JA3 must be enabled in the Suricata config file (set ‘app-layer.protocols.tls.ja3-fingerprints’ to ‘yes’).

Вот вам пароль, ломайте: qwerty23457823

Пароль нельзя сломать, можно сломать либо хеш пароля (восстановив пароль)с, либо шифрование, где пароль используется как ключ либо сервис или оборудование, где пароль используется для аутентификации. В первых двух случаях все зависит от уникальности и энтропии ("случайности") пароля и от криптографического алгоритма, например подбор хеша scrypt, argon2, yescrypt даже по словарю может быть затратным и требовать такой конфигурации оборудования, которую дорого собрать дома и практически невозможно получить в облаке или хостинге. В случае аутентификации все зависит от реализуемых алгоритмов защиты от перебора и credentials stuffing.

То, что пишет Касперский это просто оценка энтропии без учета других факторов переведенная в попугаи, понятные пользователю (оценка типа 40 бит энтропии ему обычно не понятна, а 4 года на взлом - уже лучше), к реальному времени оно отношения не имеет. Оценка энтропии это тоже некое шарлатанство, делается обычно эмпирическими методами, в которые заложены типичные шаблоны применяемые пользователем и учитываемые при брутфорсе. Ваш пароль может быть очень энтропийным, но если он уже засвечен в какой-то из утечек, времени на его подбор надо примерно 0.