Pull to refresh
83
0
Владимир Дубровин @z3apa3a

Пользователь

Send message
Универсальный совет, который годится всем, давать сложно. Напрямую привязывать смену пароля конкретного пользователя к конкретным интервалам времени — некорректно. Например, есть исследование Microsoft, в соответствии с которым принуждение пользователя к частой смене пароля или слишком жесткая парольная политика дают негативные результаты. Т.е. совет «меняйте пароль каждый месяц» будет не самым удачный. Но совершенно точно, необходимо менять пароль, когда меняются какие-либо внешние обстоятельства, прямо или косвенно связанные с эккаунтом и возможностью того, что он утечет — вы меняете место работы, компьютер, антивирус, девушку, знакомых, или начинаете использовать эккаунт для каких-то других целей. То, что большая часть пользователей меняет пароли реже раза в год, говорит о том, что какие-то обстоятельства они явно игнорируют.
Есть еще интересный момент: процент респондентов, которые заявляют о взломе эккаунтов в соц. сетях меньше, чем процент респондентов, которые замечали, что из под их эккаунта рассылался спам. Т.е. многие даже не подозревают о том, что они взломаны. Сейчас мошенники стараются себя вести именно таким образом, «паразитировать» в чужом эккаунте длительное время, рекламные сообщения или лайки могут поститься раз в 2-4 недели максимально незаметно для хозяина, что делает такой взлом трудно отслеживаемым.
Возможно такие и есть, но средства автоматического аудита в любом случае требуют настройки под конкретный сервис, поэтому лучше сразу использовать тулзы типа skipfish и включить CSP в режиме Content-Security-Policy-Report-Only чтобы отслеживть mixed content.
Разумеется, но по опыту в реальной жизни так не бывает. Если бы разработчики думали о совместимости между протоколами, то они бы сразу думали и о https-версии.
Поднять SSL на сервере и перейти на https — не одно и тоже. Переход на https подразумевает, что вы как минимум перелопатите все содержимое и скрипты сервера, чтобы избежать mixed content, разберетесь с куками, чтобы они стали secure и настроите HSTS для поддоменов. Без этого практического толку от поднятия ssl ноль. Вы как были уязвимы к MitM так и остались.
Пока вы предоставили 4 отлупа, которые были даны на действительно несуществующие адреса. Поэтому не понятно, о какой проблеме идет речь.
Если обнаружится действительная проблема — например отлуп на заведомо работающий адрес — пишите сразу в личку, не стесняйтесь.
На самом деле, в течении многих лет именно такой порядок tabindex (логин-домен-пароль) и был. Сейчас мы запоминаем использованные домены и предлагаем их по умолчанию, поэтому для 90% пользователей переход на поле ввода домена вообще не требуется и выбор домена, как опциональный, намеренно перенесен после ввода пароля.
Если вы не попадаете в 90%, не расстраивайтесь — в поле логина можно вводить полный логин, вместе с собакой и доменом, выбор домена при этом не требуется.
Приведите пожалуйста пример отлупа в личку. Ответы о несуществующем пользователе и заблокированном эккаунте даются только в случае несуществующего пользователя или заблокированного эккаунта и не зависят от того, с какого адреса вы пишете. Единственное исключение — когда пользователь вручную настроил фильтр, который дает ответ о несуществующем адресе.

Ответа о квотах у mail.ru не бывает ввиду отсутствия квот.

Скорее всего вы получаете какой-то другой отлуп, возможные причины и рекомендации перечислены здесь и здесь.
На самом деле, кроме In-Reply-To: используется еще заголовок References:, для построения цепочки достаточно чтобы присутствовал любой из них.
Оба заголовка определяются самыми базовыми стандартами электронной почты (RFC 822 и более поздними), генерируется MUA (почтовой программой пользователя).
Мы протестировали практически все основные почтовые клиенты, включая мобильные и почтовые сервисы.
Carbon Copy (CC) это обычная «Копия», такая опция в почте, разумеется, есть.
Наверное, имеется ввиду установить адрес для ответов (Reply-To)?

Ответы как раз очень удобно просматривать в цепочках — идете в «отправленные», и там будет отправленное письмо со всеми ответами на него в одной цепочке, даже если это письмо в список рассылки.
На самом деле, хотя автор вряд ли имел это ввиду, есть такая штука XTND XMIT. Ее достаточно долго поддерживали серверы отпочковавшиеся от BSD popper (qpopper, imap-uw).
Из современных серверов ее вроде бы до сих пор поддерживает Communigate.
Адрес отправителя можно подделать и без этой уязвимости. DMARC у банков популярности еще не заработал.
Вопрос был про VNC. Трафик VNC передается не между сервером и клиентом, а между клиентом и терминалом. Передаются при этом изменения областей экрана. Поэтому мигания баннера приводят к всплескам трафика.
Не знаю таких тонкостей о VNC. Если можно задать фреймрейт — то да, это хорошая защита. Но все равно остаются «но»: могут быть тайминг атаки путем нагрузки процессора через внедрение джаваскрипта в страницу, нагрузка процессора может влиять на реальные интервалы между фреймами. Могут быть ошибки реализации, например неудачный выбор паддинга.
VNC — да, вполне можно пометить. Например, внедрить в страницу баннер, который будет «мигать» в определенной последовательности. При просмотре страницы мигание баннера будет генерировать весьма характерный трафик в VNC.
Оборудование СОРМ не обслуживается провайдерами, провайдеры не имеют к нему доступа, оно обслуживается ФСБ.
Искать не надо, оборудование включено постоянно, достаточно чтобы прохождение такой метки генерировало отслеживаемое событие, точно так же, как его генерирует обращение к определенным ресурсам или ключевые фразы.

Вероятность, что такие приемы в ближайшее время будут использовать наши спецслужбы как раз не высока, т.к. ими контролируется очень небольшой сегмент сети. Зато очень высока вероятность того, что этот прием уже использует АНБ, у него все необходимое есть. АНБ это может делать даже в том случае, если пользователь из России через тор обращается к ресурсу из России, достаточно чтобы вами и точкой входа и между точкой выхода и сервером были наблюдаемые сети.
Да, прошу прощения, ложные воспоминания. Действительно передается клиентом не как MD4-хэш, а шифрованный RC4 со старым MD4-хэшем в качестве ключа.
Сервер никогда не получает пароль в открытом тексте, получает только MD4-хэш, ограничения парольные работают на клиенте, а не на сервере.
ОК, обращайтесь.

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

Information

Rating
5,144-th
Location
Нижний Новгород, Нижегородская обл., Россия
Works in
Date of birth
Registered
Activity