Сведения для защиты и коды проверки учетных записей Майкрософт

Сведения о безопасности используются для подтверждения вашей личности

Сведения для защиты — это дополнительный контактный адрес электронной почты или номер телефона, добавляемый к учетной записи. Если вы забудете пароль или кто-то попытается получить доступ к вашей учетной записи, на этот адрес или номер телефона будет отправлен код проверки. Когда вы отправите этот код обратно нам, мы убедимся, что это действительно вы, и сможем восстановить доступ к вашей учетной записи Майкрософт.

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

Примечание: Эта статья содержит сведения о безопасности. Если вы потеряли или забыли пароль, либо у вас возникли другие проблемы с паролем, см. раздел Изменение или сброс пароля для Windows.

Прежде чем приступить к управлению сведениями о безопасности, убедитесь, что вы получили код проверки.

Если вы хотите сбросить пароль, но код проверки не пришел, см. раздел Не удается войти в учетную запись Майкрософт.

Советы по получению и использованию кодов проверки см. в разделе Устранение проблем с кодом проверки.

Управление сведениями о безопасности

Вы можете изменить пароль, обновить сведения или просмотреть последние действия. Если вы еще не вошли в свою учетную запись Майкрософт, отобразится запрос на выполнение входа.

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

Если вы хотите добавить новый адрес электронной почты или номер телефона, см. раздел Добавление сведений о безопасности к учетной записи Майкрософт.

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

На странице Основные сведения о безопасности нажмите кнопку Обновить сведения. Если вы еще не вошли в свою учетную запись Майкрософт, отобразится запрос на выполнение входа.

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

Вы увидите свои сведения безопасности в разделе Параметры безопасности. Чтобы удалить ненужные данные, выберите пункт Удалить. Возможно, потребуется добавить новые сведения для защиты учетной записи, прежде чем вы сможете удалить старые.

Примечание: При запросе удаления всех сведений о безопасности в вашей учетной записи информация не изменится в течение 30 дней. В течение этого периода мы не сможем принимать внесение других изменений или дополнений в параметры безопасности либо в сведения о выставлении счетов. Ваша учетная запись будет открыта и активна и вы по-прежнему сможете использовать электронную почту, Skype, OneDrive и устройства обычным образом. Мы сообщим вам, когда потребуется ввести новые сведения для защиты учетной записи.

Устранение проблем с кодом проверки

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

Принимает ли ваш телефон SMS-сообщения с неизвестных номеров?
Если нет, измените параметры телефона, а затем выберите У меня нет кода. Мы отправим другой код проверки.

Могло ли письмо с кодом проверки попасть в папку нежелательной почты?

Проверьте, нет ли в ней сообщения из учетной записи Майкрософт, и используйте полученный код. Подлинные коды проверки приходят с электронного адреса @accountprotection.microsoft.com.

Пометьте адрес @accountprotection.microsoft.com в папке «Входящие» в качестве доверенного отправителя для получения кода проверки.

Правильно ли введен ваш номер телефона или адрес электронной почты?
Для защиты ваших данных при входе мы показываем только последние две цифры вашего номера телефона или первые два символа вашего адреса электронной почты.

Чтобы просмотреть правильность сведений о безопасности, выполните следующие действия.

Перейдите на страницу Основные сведения о безопасности, используя свою учетную запись Майкрософт.

Нажмите кнопку Обновить сведения.

Выберите известный вам работающий способ или выберите Я не использую ни один из этих параметров для замены сведений для защиты учетной записи.

Ваш дополнительный адрес электронной почты заканчивается на @outlook.com, @hotmail.com, @live.com или @msn.com?
Если это так, то вы используете одну учетную запись Майкрософт для проверки другой учетной записи Майкрософт. В этом случае сложно отследить, в какую именно учетную запись вы вошли. При входе во вторую учетную запись (для получения кода, отправленного на этот адрес) большинство браузеров автоматически выходят из первой учетной записи (той, для которой фактически нужен код).

Чтобы получить код проверки, сделайте следующее:

С помощью браузера в режиме конфиденциальности войдите со своей первой учетной записью. Это позволит вам оставаться в обеих учетных записях одновременно.

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

Откройте новое окно в режиме конфиденциальности. Для просмотра InPrivate в браузерах Microsoft Edge и Internet Explorer воспользуйтесь сочетанием клавиш CTRL + SHIFT + P Если вы используете другой браузер, поищите в разделе справки информацию о режиме конфиденциальности.

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

Вернитесь в окно, в котором необходимо ввести код проверки. Введите код и следуйте дальнейшим инструкциям.

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

Мы не будем предлагать вам подтвердить сведения для защиты при каждом вашем входе в систему. В некоторых случаях вам может быть предложено повторить проверку — например, если вы долго не выполняли вход. Это значит лишь то, что мы хотим убедиться в актуальности ваших данных.

Нет. Код проверки не заменяет пароль, поэтому не стоит вводить его в поле для пароля. Мы используем коды проверки в дополнение к паролям в качестве дополнительного уровня безопасности на случай, если кто-то другой узнает ваш пароль.

&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbspЛаборатория информационной безопасности

Написание защищённого кода

Задача защиты программного кода от различных уязвимостей — очень важная проблема в современной быстро растущей индустрии IT. XSS, SQL-инъекции, переполнение буффера с последующими получением привилегий — всё это и многое другое следствия ошибок разработчиков, которые, к сожалению, совершают их с каждым днём всё больше и больше. Объясняется это просто: технологии движутся вперёд, объёмы кода сильно растут, а качество мозга людей и соответственно, написанного ими программного кода — не растёт. Или растёт, но не так быстро.

В нынешнее время очень хорошим результатом для гуру-программиста считается 1 серьёзная ошибка на 1000 строк кода. Для примера, в новомодной Windows 8 содержится 7 миллионов строк. Число критических ошибок подсчитать может 9-летний выпускник начальной школы.

Почему же ситуация столь плоха? Что надо делать, чтобы писать защищённый код и ограждаться от множества уязвимостей в собственном ПО? Об этом в сегодняшней статье, основанной на трудах ведущих разработчиков Microsoft М. Ховарда и Дж. ЛеБланка.

Прежде чем писать о защищённости программ и принципах написания защищённого кода, отметим ещё один важный фактор, сильно влияющий на конечный результат. Приложения пишутся людьми, люди склонны к лени, невнимательности и как следствие, — множеству ошибок. Также, люди склонны к личной выгоде, универсалом которой являются деньги. Соответственно, первый и главный аспект написания защищённых приложений — это мотивирование персонала: разработчиков и тестировщиков. О том, как это сделать сказано в замечательной статье о плате за взлом или защите от уязвимостей.

Безопасность приложений

Основная задача написания защищённого кода – создание защищённых программ, т.е. программ, которые обеспечивают конфиденциальность, целостность и доступность информации клиента вашей IT-компании, а также целостность и доступность вычислительных ресурсов, управляемых владельцем системы или системным администратором. Здесь и далее будет идти речь об организациях, занимающихся разработкой ПО. Обеспечить исполнение определённых правил конкретно написания кода мало – прежде всего, надо корректно организовать весь итеративно-инкрементный процесс разработки ПО, а также обеспечить корректное управление безопасностью приложений.

Перечислим общие принципы, которые должны быть включены в политику безопасности, при работе с приложениями и при их написании. Одним из основных девизов компании должен стать девиз «безопасность (безопасность ПО в вышеуказанном смысле) – превыше всего».

Действие №1 . Пропаганда идей безопасности на предприятии, пока идея их обеспечения не станет статьёй в бизнес-плане компании. Для этого, естественно, нужно предъявить начальству весомую аргументацию, прямо касающуюся прибыли компании, после чего убедить начальство в том, чтобы оно само обратилось к сотрудникам с выработанным регламентом политики ИБ.

Действие №2 . Взять в штат специалиста по ИБ, который будет заниматься контролем за соблюдением политики ИБ, поддерживать/обслуживать/обновлять/адаптировать динамическую систему ИБ, вырабатывать новую политику ИБ (модели угроз и т.д.).

Действие №3 . Организация непрерывного обучения штата: обязательность и непрерывность; регулярная рассылка с выявляемыми проблемами и просьба решить эти проблемы тем, в зоне чьей ответственности они находятся; создать ресурс по ИБ в интрасети, пересматривать написанный код с позиции возможных ошибок ИБ и наличия ныне известных и потенциально возможных уязвимостей.

Действие №4 . Классификация ошибок систем ИБ. Можно расширить и назвать данный пункт: составление классифицированной модели угроз. Смысл ясен.

Общие принципы проектирования защищённых приложений:

1. Защита должна ставиться, как неотъемлемая функция создаваемого ПО.

2. На обеспечение безопасности ПО должно быть отведено достаточно времени.

3. Обязательно должна быть составлена модель угроз: декомпозиция ПО с выявлением присущих уязвимостей; определение степени опасности и вероятности возникновения каждой уязвимости/опасности; составление матрицы угроз; определение противодействий, а также действий в случае реализации угрозы.

4. Определение процедуры удаления небезопасных функций и частей в ПО.

5. Должны быть созданы метрики безопасности, соответствующие модели угроз, в которых должны быть определены предельные пороги.

6. Разработка тест-планов и периодическая проверка и контроль процесса создания ПО отделом ИБ на каждом этапе разработки по созданным тест-планам, по возможности, — приглашёнными специалистами.

7. Обязательный контроль безопасности модуля не тем, кто разработал данный модуль.

8. Безопасность должна обеспечиваться в конфигурации по умолчанию и при развёртывании.

9. Особый контроль за предоставлением прав на внесение изменений в ПО.

10. «Площадь уязвимости» (потенциальная) должна быть как можно меньше (всевозможные открытые TCP/UDPпорты, запускаемые и зависимые службы, динамические веб-страницы, части приложения или службы, запускаемые с высокими привилегиями и т.д.).

11. Должны быть защищены все уровни (независимо друг от друга и от других уровней защиты).

12. Используйте правило минимальных привилегий (и + грамотно составленный ACL).

13. Следует вести разработку с учётом аксиомы: внешние системы по умолчанию не защищены.

14. Разработайте план действий на случай сбоев или отказов.

15. Не стройте систему безопасности на ограничении информации о ПО.

16. Разделяйте код и данные (исключение любой смеси данных и JS- или SQL-кода).

17. Исправляя ошибки в защите, проверяйте всю систему – все модули, пытаясь найти там те же проблемы.

Общие принципы безопасного кодирования:

1. Не предоставляйте взломщику никакой информации.

2. Не позволяйте информации просочиться через заголовки.

3. Не включайте ничего лишнего в код!

4. Следите за квотами, буферами и сериализацией.

5. Используйте стандартные средства операционной системы.

6. Не рассчитывайте, что пользователи всегда принимают правильные решения: проверяйте все входные данные в широком смысле.

7. Не размещайте никаких пользовательских файлов в каталоге \Program Files.

8. Безопасно создавайте временные файлы (GetTempPath, GetTempFileName)

9. Никаких внутрикорпоративных имен в приложении!

10. Ведите журналы безопасности в приложении.

11. Перенос кода, написанного на С/С++, на управляемый язык (C#).

Безопасность написания защищённого кода на конкретных примерах

Поговорим об основных проблемах и принципах программирования, связанных с написанием безопасного приложения:

1. Переполнение буфера (стека, кучи, переполнение в результате ошибок индексации массивов, переполнение в результате использования некорректной кодировки). Способ лечения: строгая проверка всех входных данных на корректность во всех отношениях, аккуратность при обработке данных; проверка корректности подаваемых на вход strcpy/strlenи т.д. данных; использование параметра компиляции /gs компилятора gcc/VisualС++ .NET.

2. Использование злоумышленниками ПО или его службы, запущенного/ой с высокими привилегиями (примеров много, и они очевидны). Решение: а) Выясните, какие ресурсы нужны ПО; б) выясните, какие APIиспользует ПО; в) определите, какая требуется учётная запись и какой ей нужен маркер; г) Отладка ошибок, возникающих из-за ограничения привилегий.

3. Слабые случайные числа. Решение: использовать ГСЧ на основе хороших блочных шифров с полным набором раундов, работающих в режимах CBC, CFBили OFB (хотя допускается и режим ECB). Генерация – только на основании пароля, который в свою очередь должен удовлетворять определённым условиям сложности (в ПО должна быть проверка).

4. Слабая криптография. Решение: использование по возможности краткосрочных (сеансовых) ключей. Аутентификационные данные должны храниться строго централизованно, а обрабатываться – локально. В случае возникновения задачи обмена ключами по небезопасному каналу – использовать ассиметричную криптографию, передавая таким способом лишь ключи к симметричному шифру. В случае оборота ЭД, использовать механизм ЭЦП.

5. Универсальная защита конфиденциальных данных. Проблема: её нет. Решение: шифрование данных мощным симметричным алгоритмом (AES, RC6, Blowfish, 3DESи т.д.), хранение пароля в надёжном разделе реестра (в случае несистемного использование – вообще нехранение пароля!), требование ввода пароля, защита списками ACLфайла и раздела реестра.

6. Опасность входных данных (SQL-injection, XSSи многое другое). Проблема: очевидна. Решение: особое внимание всякого рода регулярным выражениям; строгий контроль корректности и длины входных данных и их фильтрация. Указывайте полные пути в адресах, представленные в канонической форме.

7. Опасности работы с БД. Решения: а) Использование параметризованных запросов к БД, отсутствие конструирования запросов внутри приложения; жёсткий контроль корректности отправляемых запросов; б) не подключаться к БД от имени system; г) Используйте безопасно хранимые процедуры.

8. Защита от XSS-атак: а) кодирование выходных данных; б) использование двойных кавычек во всех атрибутах тэга; в) Как можно чаще используйте innerText; г) Используйте только одну кодовую страницу.

Выводы

Итак, мы рассмотрели основные правила и принципы написания защищённого кода в приложениях; способах защиты его от узявимостей и проблемах программирования. Конечно, данные методы не являются исчерпывающими и не претендуют на полноту — они лишь показывают основные закономерности, тенденции и принципы граммотного проектирования архитектуры проекта и моментов, стоящих внимания. Не стоит забывать и об организационной безопасности, роль которой сложно переоценить, а также принципах информационной безопасности в общем.