Jump to content

НТЛМ

(Перенаправлено из NT LAN Manager )

В Windows сети NT (Новая технология) LAN Manager ( NTLM ) представляет собой набор протоколов безопасности Microsoft, предназначенных для обеспечения аутентификации, целостности и конфиденциальности пользователей. [1] [2] [3] NTLM является преемником протокола аутентификации в Microsoft LAN Manager (LANMAN), более старом продукте Microsoft. Набор протоколов NTLM реализован в Security Support Provider , который объединяет протокол аутентификации LAN Manager , протоколы сеансов NTLMv1, NTLMv2 и NTLM2 в одном пакете. Используются ли эти протоколы или могут ли они использоваться в системе, которая управляется параметрами групповой политики , для которых разные версии Windows имеют разные настройки по умолчанию.

Пароли NTLM считаются слабыми, поскольку их можно подобрать с помощью современного оборудования. легко [4]

Протокол

[ редактировать ]

NTLM — это протокол аутентификации типа «запрос-ответ» , который использует три сообщения для аутентификации клиента в среде, ориентированной на соединение (без установления соединения аналогично), и четвертое дополнительное сообщение, если требуется целостность. [5] [6] [7] [8]

  1. Сначала клиент устанавливает сетевой путь к серверу и отправляет NEGOTIATE_MESSAGE, сообщая о своих возможностях. [9]
  2. Затем сервер отвечает CHALLENGE_MESSAGE, который используется для установления личности клиента. [10]
  3. Наконец, клиент отвечает на запрос сообщением AUTHENTICATE_MESSAGE. [11]

Протокол NTLM использует одно или оба из двух хешированных значений пароля, оба из которых также хранятся на сервере (или контроллере домена) и которые из-за отсутствия подсоливания эквивалентны паролю . Это означает, что если вы получите хэш-значение с сервера , вы можете пройти аутентификацию, не зная фактического пароля. Это хэш LM ( функция на основе DES , применяемая к первым 14 символам пароля, преобразованная в традиционную 8-битную кодировку ПК для этого языка) и хеш NT ( MD4 с прямым порядком байтов) UTF-16 Unicode пароля . ). Оба хеш-значения имеют длину 16 байт (128 бит) каждое. [12]

Протокол NTLM также использует одну из двух односторонних функций , в зависимости от версии NTLM; NT LanMan и NTLM версии 1 используют одностороннюю функцию LanMan на основе DES (LMOWF), а NTLMv2 использует NT MD4 (NTOWF). одностороннюю функцию на основе [12] [13]

Сервер аутентифицирует клиента, отправляя 8-байтовое случайное число — запрос. Клиент выполняет операцию, включающую запрос и секрет, общий между клиентом и сервером, в частности, один из двух хэшей паролей, описанных выше. Клиент возвращает 24-байтовый результат вычисления. Фактически, в NTLMv1 вычисления обычно выполняются с использованием обоих хешей и отправляются оба 24-байтовых результата. Сервер проверяет, что клиент вычислил правильный результат, и на основании этого делает вывод о владении секретом и, следовательно, о подлинности клиента.

Оба хеша создают 16-байтовые величины. Добавляются пять байтов нулей, чтобы получить 21 байт. 21 байт разделен на три 7-байтовых (56-битных) количества. Каждая из этих 56-битных величин используется в качестве ключа для DES шифрования 64-битного запроса . Три шифрования запроса воссоединяются, чтобы сформировать 24-байтовый ответ. В качестве ответа возвращаются как ответ с использованием хеша LM, так и хеша NT, но это можно настроить.

C = 8-byte server challenge, random
K1 | K2 | K3 = NTLM-Hash | 5-bytes-0
response = DES(K1,C) | DES(K2,C) | DES(K3,C)

NTLMv2, представленный в Windows NT 4.0 SP4. [14] (и изначально поддерживается в Windows 2000) — это протокол аутентификации типа «запрос-ответ». Он задуман как криптографически усиленная замена NTLMv1, повышающая безопасность NTLM за счет усиления защиты протокола от многих спуфинговых атак и добавления возможности серверу аутентифицироваться на клиенте. [1] [15] [16]

NTLMv2 отправляет два ответа на 8-байтовый запрос сервера . Каждый ответ содержит 16-байтовый хеш HMAC - MD5 запроса сервера, полностью или частично случайно сгенерированный запрос клиента , а также хэш HMAC-MD5 пароля пользователя и другую идентифицирующую информацию. Эти два ответа различаются по формату запроса клиента. В более коротком ответе для этого запроса используется 8-байтовое случайное значение. Чтобы проверить ответ, сервер должен получить как часть ответа на запрос клиента. Для этого более короткого ответа 8-байтовый запрос клиента, добавленный к 16-байтовому ответу, образует 24-байтовый пакет, который соответствует 24-байтовому формату ответа предыдущего протокола NTLMv1. В некоторой неофициальной документации (например, DCE/RPC Over SMB, Leighton) этот ответ называется LMv2.

Второй ответ, отправленный NTLMv2, использует запрос клиента переменной длины, который включает в себя (1) текущее время в формате NT Time , (2) 8-байтовое случайное значение (CC2 в поле ниже), (3) имя домена и (4) некоторые материалы стандартного формата. Ответ должен включать копию этого запроса клиента и, следовательно, имеет переменную длину. В неофициальной документации этот ответ называется NTv2.

И LMv2, и NTv2 хэшируют запрос клиента и сервера с помощью NT-хэша пароля пользователя и другой идентифицирующей информации. Точная формула состоит в том, чтобы начать с хеш-кода NT, который хранится в SAM или AD, и продолжать хешировать, используя HMAC - MD5 , имя пользователя и имя домена. В поле ниже X обозначает фиксированное содержимое поля форматирования.

SC = 8-byte server challenge, random
CC = 8-byte client challenge, random
CC* = (X, time, CC2, domain name)
v2-Hash = HMAC-MD5(NT-Hash, user name, domain name)
LMv2 = HMAC-MD5(v2-Hash, SC, CC)
NTv2 = HMAC-MD5(v2-Hash, SC, CC*)
response = LMv2 | CC | NTv2 | CC*

Сеанс NTLM2

[ редактировать ]

Протокол сеанса NTLM2 аналогичен MS-CHAPv2. [17] Он состоит из аутентификации NTLMv1 в сочетании с безопасностью сеанса NTLMv2.

Вкратце, применяется алгоритм NTLMv1, за исключением того, что 8-байтовый запрос клиента добавляется к 8-байтовому запросу сервера и хешируется по MD5. Меньшая 8-байтовая половина результата хеширования — это запрос, используемый в протоколе NTLMv1. Запрос клиента возвращается в одном 24-байтовом слоте ответного сообщения, 24-байтовый рассчитанный ответ возвращается в другом слоте.

Это усиленная форма NTLMv1, которая сохраняет возможность использовать существующую инфраструктуру контроллера домена, но позволяет избежать атаки по словарю со стороны мошеннического сервера. Для фиксированного X сервер вычисляет таблицу, в которой местоположение Y имеет значение K, такое что Y=DES_K(X) . Без участия клиента в выборе запроса сервер может отправить X , найти ответ Y в таблице и K. получить Эту атаку можно сделать практичной, используя радужные таблицы . [18]

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

NTLMv1
  Client<-Server:  SC
  Client->Server:  H(P,SC)
  Server->DomCntl: H(P,SC), SC
  Server<-DomCntl: yes or no

NTLM2 Session
  Client<-Server:  SC
  Client->Server:  H(P,H'(SC,CC)), CC
  Server->DomCntl: H(P,H'(SC,CC)), H'(SC,CC)
  Server<-DomCntl: yes or no

Наличие и использование NTLM

[ редактировать ]

С 2010 года Microsoft больше не рекомендует NTLM в приложениях: [19]

Разработчики должны знать, что NTLM не поддерживает какие-либо современные методы шифрования, такие как AES или SHA-256. Он использует циклический избыточный контроль (CRC) или MD5 для целостности и RC4 для шифрования.

Получение ключа из пароля описано в RFC1320 и FIPS46-2. Поэтому приложениям обычно не рекомендуется использовать NTLM.

Несмотря на эти рекомендации, NTLM по-прежнему широко используется в системах. [ нужна ссылка ] Основная причина — обеспечение совместимости со старыми системами. Однако в некоторых случаях этого можно избежать. [ как? ]

Microsoft добавила хэш NTLM в свою реализацию протокола Kerberos для улучшения совместимости (в частности, типа шифрования RC4-HMAC). По мнению независимого исследователя, такое конструктивное решение позволяет обманным путем заставить контроллеры домена выдать злоумышленнику билет Kerberos, если известен NTLM-хэш. [20] Microsoft приняла Kerberos в качестве предпочтительного протокола аутентификации для Windows 2000 и последующих доменов Active Directory. [16] Kerberos обычно используется, когда сервер принадлежит домену Windows Server . Microsoft рекомендует разработчикам не использовать напрямую Kerberos или поставщика поддержки безопасности NTLM (SSP). [21]

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

Использование поставщика поддержки безопасности NTLM

[ редактировать ]

NTLM SSP используется в следующих ситуациях:

  • Клиент проходит аутентификацию на сервере, который не принадлежит домену или домен Active Directory не существует (обычно называемый «рабочей группой» или «одноранговой сетью»).
    • На сервере должна быть включена функция «общего доступа, защищенного паролем», которая не включена по умолчанию и является взаимоисключающей с HomeGroup в некоторых версиях Windows.
    • Когда сервер и клиент принадлежат к одной и той же домашней группе протокол, аналогичный Kerberos, аутентификация пользователей между пользователями на основе криптографии с открытым ключом . , вместо NTLM будет использоваться [22] Домашняя группа, вероятно, является самым простым способом совместного использования ресурсов в небольшой сети, требующим минимальной настройки, даже по сравнению с настройкой нескольких дополнительных пользователей на использование общего доступа, защищенного паролем, что может означать, что он используется гораздо чаще, чем общий доступ, защищенный паролем. малые сети и домашние сети.
  • Если сервер представляет собой устройство, поддерживающее SMB , например устройства NAS и сетевые принтеры, NTLM SSP может предлагать единственный поддерживаемый метод аутентификации. Некоторые реализации SMB или более старые дистрибутивы, например Samba, могут привести к тому, что Windows согласует NTLMv1 или даже LM для исходящей аутентификации с SMB-сервером, позволяя устройству работать, хотя оно может быть загружено устаревшим, небезопасным программным обеспечением, независимо от того, было ли это новое устройство. .
  • Если сервер является членом домена, но Kerberos использовать невозможно.
    • Клиент проходит аутентификацию на сервере, используя IP-адрес (и обратное разрешение имен недоступно).
    • Клиент проходит проверку подлинности на сервере, принадлежащем другому лесу Active Directory, имеющему устаревшее доверие NTLM вместо транзитивного доверия между лесами.
    • В противном случае брандмауэр ограничил бы порты, необходимые для Kerberos (обычно TCP 88).

Использование версий протокола

[ редактировать ]

После того как разработчик приложения или поставщик общих служб согласования принял решение использовать NTLM SSP для аутентификации, групповая политика определяет возможность использования каждого из протоколов, реализуемых NTLM SSP. Существует пять уровней аутентификации. [23]

  • Отправка ответов LM и NTLM . Клиенты используют аутентификацию LM и NTLM и никогда не используют сеансовую безопасность NTLMv2; Контроллеры домена принимают аутентификацию LM, NTLM и NTLMv2.
  • Отправить LM и NTLM — использовать сеансовую безопасность NTLMv2, если согласовано : клиенты используют аутентификацию LM и NTLM, а также используют сеансовую безопасность NTLMv2, если сервер ее поддерживает; Контроллеры домена принимают аутентификацию LM, NTLM и NTLMv2.
  • Отправлять только ответ NTLM : клиенты используют только аутентификацию NTLM и используют сеансовую безопасность NTLMv2, если сервер ее поддерживает; Контроллеры домена принимают аутентификацию LM, NTLM и NTLMv2.
  • Отправлять только ответ NTLMv2 : клиенты используют только аутентификацию NTLMv2 и используют сеансовую безопасность NTLMv2, если сервер поддерживает ее; Контроллеры домена принимают аутентификацию LM, NTLM и NTLMv2.
  • Отправлять только ответ NTLMv2\отказаться от LM : клиенты используют только аутентификацию NTLMv2 и используют сеансовую безопасность NTLMv2, если сервер ее поддерживает; Контроллеры домена отказываются от LM (принимают только аутентификацию NTLM и NTLMv2).
  • Отправлять только ответ NTLMv2\отказаться от LM и NTLM : клиенты используют только аутентификацию NTLMv2 и используют сеансовую безопасность NTLMv2, если сервер ее поддерживает; Контроллеры домена отказываются от LM и NTLM (принимают только аутентификацию NTLMv2).

DC будет означать контроллер домена, но использование этого термина сбивает с толку. Любой компьютер, выступающий в качестве сервера и аутентифицирующий пользователя, выполняет роль контроллера домена в этом контексте, например компьютер Windows с локальной учетной записью, такой как Администратор, когда эта учетная запись используется во время входа в сеть.

До Windows NT 4.0 с пакетом обновления 4 поставщик общих служб согласовывал NTLMv1 и возвращался к LM, если другой компьютер его не поддерживал.

Начиная с Windows NT 4.0 с пакетом обновления 4, SSP будет согласовывать сеанс NTLMv2 всякий раз, когда и клиент, и сервер поддерживают его. [24] Вплоть до Windows XP включительно на компьютерах за пределами США использовалось либо 40-, либо 56-битное шифрование, поскольку в то время в США существовали строгие ограничения на экспорт технологий шифрования. Начиная с Windows XP SP3, 128-битное шифрование можно было добавить путем установки обновления, а в Windows 7 128-битное шифрование будет использоваться по умолчанию.

В Windows Vista и более поздних версиях LM отключен для входящей аутентификации. Операционные системы на базе Windows NT, включая Windows Server 2003, хранят два хэша паролей: хэш LAN Manager (LM) и хэш Windows NT. Начиная с Windows Vista , есть возможность хранить оба файла, но один из них по умолчанию отключен. Это означает, что проверка подлинности LM больше не работает, если в качестве сервера выступает компьютер под управлением Windows Vista. Предыдущие версии Windows (начиная с Windows NT 4.0 с пакетом обновления 4) можно было настроить на такое поведение, но это не было по умолчанию. [25]

Слабости и уязвимости

[ редактировать ]

NTLM остается уязвимым для атаки с передачей хэша , которая является вариантом атаки с отражением , устраненной в обновлении безопасности Microsoft MS08-068. Например, Metasploit во многих случаях можно использовать для получения учетных данных с одного компьютера, которые можно использовать для получения контроля над другим компьютером. [3] [26] Набор инструментов Squirtle можно использовать для использования атак с использованием межсайтовых сценариев на веб-сайтах для атак на близлежащие ресурсы через NTLM. [27]

В феврале 2010 года компания Amplia Security обнаружила несколько недостатков в реализации механизма аутентификации NTLM в Windows, которые нарушили безопасность протокола, позволив злоумышленникам получить доступ для чтения/записи к файлам и удаленного выполнения кода. Одна из представленных атак включала возможность прогнозировать псевдослучайные числа и запросы/ответы, генерируемые протоколом. Эти недостатки присутствовали во всех версиях Windows на протяжении 17 лет. Рекомендации по безопасности, объясняющие эти проблемы, включали полностью работающие эксплойты для проверки концепции. Все эти недостатки были исправлены MS10-012. [28] [29]

В 2012 году было продемонстрировано, что любую возможную перестановку хэша 8-значного пароля NTLM можно взломать менее чем за 6 часов. [30]

В 2019 году это время сократилось примерно до 2,5 часов за счет использования более современного оборудования. [4] [31] Кроме того, таблицы Rainbow доступны для восьми- и девятизначных паролей NTLM. Более короткие пароли можно восстановить методом перебора. [32]

В 2019 году ЗлойМог [33] [34] опубликовал инструмент под названием ntlmv1-multitool [35] форматировать ответы на запросы NTLMv1 в формате взлома, совместимом с hashcat. При наличии hashcat и достаточной мощности графического процессора NTLM-хэш может быть получен с использованием атаки с использованием известного открытого текста путем взлома ключей DES в режиме hashcat 14000, как продемонстрировано атомом. [36] на форумах hashcat.

Обратите внимание, что хэши, эквивалентные паролю, используемые в атаках с передачей хеша и взломе паролей, сначала должны быть «украдены» (например, путем взлома системы с разрешениями, достаточными для доступа к хешам). Кроме того, эти хэши не совпадают с «хешем» NTLMSSP_AUTH, передаваемым по сети во время обычной аутентификации NTLM.

Совместимость с Linux

[ редактировать ]

Реализации NTLM для Linux включают Cntlm. [37] и winbind (часть Samba ) [38] разрешить приложениям Linux использовать прокси-серверы NTLM.

FreeBSD также поддерживает хранение паролей через Crypt (C) в небезопасной форме NT-Hash. [39]

См. также

[ редактировать ]
  1. ^ Перейти обратно: а б «Введение» , Спецификация протокола аутентификации NT LAN Manager (NTLM) , Microsoft , получено 15 августа 2010 г.
  2. ^ «Сведения о безопасности сеанса» , Спецификация протокола аутентификации NT LAN Manager (NTLM) , Microsoft , получено 15 августа 2010 г.
  3. ^ Перейти обратно: а б Такахаши, Т. (17 декабря 2009 г.), «Размышления об отражении NTLM» , блог FrequencyX , IBM Internet System Security (ISS), заархивировано из оригинала 31 декабря 2009 г. , получено 14 августа 2010 г.
  4. ^ Перейти обратно: а б Клэберн, Томас (14 февраля 2019 г.). «Используете 8-значный пароль Windows NTLM? Не делайте этого. Любой пароль можно взломать менее чем за 2,5 часа» . www.theregister.co.uk . Проверено 26 ноября 2020 г.
  5. ^ «Microsoft NTLM» , MSDN , Microsoft , получено 15 августа 2010 г.
  6. ^ «Синтаксис сообщения | раздел 2.2» , Спецификация протокола аутентификации NT LAN Manager (NTLM) , Microsoft , получено 15 августа 2010 г.
  7. ^ «Ориентированный на соединение» , Спецификация протокола аутентификации NT LAN Manager (NTLM) (изд. 3.1.5.1), Microsoft , получено 15 августа 2010 г.
  8. ^ «Без установления соединения» , Спецификация протокола аутентификации NT LAN Manager (NTLM) (изд. 3.1.5.2), Microsoft , получено 15 августа 2010 г.
  9. ^ «NEGOTIATE_MESSAGE» , Спецификация протокола аутентификации NT LAN Manager (NTLM) (изд. 2.2.1.1), Microsoft , получено 15 августа 2010 г.
  10. ^ «CHALLENGE_MESSAGE» , Спецификация протокола аутентификации NT LAN Manager (NTLM) (изд. 2.2.1.2), Microsoft , получено 15 августа 2010 г.
  11. ^ «AUTHENTICATE_MESSAGE» , Спецификация протокола аутентификации NT LAN Manager (NTLM) (изд. 2.2.1.3), Microsoft , получено 15 августа 2010 г.
  12. ^ Перейти обратно: а б «Аутентификация NTLM v1» , Спецификация протокола аутентификации NT LAN Manager (NTLM) (изд. 3.3.1), Microsoft , получено 15 августа 2010 г.
  13. ^ «Аутентификация NTLM v2» , Спецификация протокола аутентификации NT LAN Manager (NTLM) (изд. 3.3.1), Microsoft , получено 15 августа 2010 г.
  14. ^ Что нового в пакете обновления 4 для Windows NT 4.0?
  15. ^ Как включить аутентификацию NTLM 2 , Служба поддержки, Microsoft, 25 января 2007 г. , получено 14 августа 2010 г.
  16. ^ Перейти обратно: а б «Конфигурация безопасности» , Руководство по усилению безопасности Microsoft Windows 2000 , TechNet, Microsoft , получено 14 августа 2010 г.
  17. ^ Гласс, Эрик, «NTLM» , Давенпорт , Source forge
  18. ^ Варугезе, Сэм (февраль 2006 г.). «Взлом Rainbow и безопасность паролей» . Частокол. Архивировано из оригинала 1 июня 2010 г. Проверено 14 августа 2010 г.
  19. ^ «Вопросы безопасности для разработчиков» , Спецификация протокола аутентификации NT LAN Manager (NTLM) , Microsoft , получено 16 августа 2010 г.
  20. ^ «Раскрытие уязвимости Active Directory: слабое шифрование позволяет злоумышленнику изменить пароль жертвы без входа в систему — Aorato» . Архивировано из оригинала 6 октября 2014 г. Проверено 5 октября 2014 г.
  21. ^ «Майкрософт НТЛМ» . Библиотека ТехНет . Майкрософт . Проверено 2 ноября 2015 г.
  22. ^ «Обзор аутентификации пользователей на основе криптографии с открытым ключом» . Библиотека ТехНет . Майкрософт . Проверено 2 ноября 2015 г.
  23. ^ «Уровень аутентификации LAN Manager» . Библиотека MSDN . Майкрософт . Проверено 2 ноября 2015 г.
  24. ^ «Аутентификация Windows» . Библиотека ТехНет . Майкрософт. 29 июня 2011 года . Проверено 2 ноября 2015 г.
  25. ^ Йеспер Йоханссон. «Самая непонятая настройка безопасности Windows всех времен» . Журнал ТехНет . Майкрософт . Проверено 2 ноября 2015 г.
  26. ^ ХД Мур. «MS08-068: Metasploit и SMB Relay» .
  27. ^ Курт Груцмахер (8 августа 2008 г.). Забейте гроб, NTLM мертв . Дефкон 16.
  28. ^ Эрнан Очоа и Агустин Азубель (28 июля 2010 г.). Понимание уязвимости Windows SMB NTLM Weak Nonce (PDF) . Блэкхэт США 2010.
  29. ^ Эрнан Очоа и Агустин Азубель. «Рекомендации по безопасности уязвимости Windows SMB NTLM Weak Nonce» .
  30. ^ Гудин, Дэн (10 декабря 2012 г.). «Кластер из 25 графических процессоров взламывает любой стандартный пароль Windows менее чем за 6 часов» . Арс Техника . Проверено 23 ноября 2020 г.
  31. ^ hashcat (13 февраля 2019 г.). «Настроенная вручную бета-версия hashcat 6.0.0 и 2080Ti (штатные тактовые частоты) превосходят отметку скорости взлома NTLM в 100 ГГц/с на одном вычислительном устройстве» . @хэшкэт . Проверено 26 февраля 2019 г.
  32. ^ Пример использования современного радужного стола
  33. ^ «Этический хакер Дастин Хейвуд, он же EvilMog: «Моя миссия — сделать компании безопаснее» » . Глобус и почта . 09.12.2019 . Проверено 12 октября 2023 г.
  34. ^ «Дастин Хейвуд: «злой» хакер, использующий свой нейроотличный разум во благо» . Отдел новостей IBM . Проверено 12 октября 2023 г.
  35. ^ Хейвуд, Дастин (11 октября 2023 г.), обновления от 10 ноября 2020 г. , получено 12 октября 2023 г.
  36. ^ «Как использовать режим DES KPA» . hashcat.net . Проверено 12 октября 2023 г.
  37. ^ «Cntlm: быстрый прокси-сервер аутентификации NTLM на C» .
  38. ^ «NTLM-аутентификация — MoodleDocs» .
  39. ^ «Хеш пароля NT MD4 как новый метод шифрования паролей для FreeBSD» . Mail-archive.com . Проверено 2 декабря 2018 г.
[ редактировать ]
Arc.Ask3.Ru: конец переведенного документа.
Arc.Ask3.Ru
Номер скриншота №: a22bcd62779c8fb72b3226c17f7178d1__1718987640
URL1:https://arc.ask3.ru/arc/aa/a2/d1/a22bcd62779c8fb72b3226c17f7178d1.html
Заголовок, (Title) документа по адресу, URL1:
NTLM - Wikipedia
Данный printscreen веб страницы (снимок веб страницы, скриншот веб страницы), визуально-программная копия документа расположенного по адресу URL1 и сохраненная в файл, имеет: квалифицированную, усовершенствованную (подтверждены: метки времени, валидность сертификата), открепленную ЭЦП (приложена к данному файлу), что может быть использовано для подтверждения содержания и факта существования документа в этот момент времени. Права на данный скриншот принадлежат администрации Ask3.ru, использование в качестве доказательства только с письменного разрешения правообладателя скриншота. Администрация Ask3.ru не несет ответственности за информацию размещенную на данном скриншоте. Права на прочие зарегистрированные элементы любого права, изображенные на снимках принадлежат их владельцам. Качество перевода предоставляется как есть. Любые претензии, иски не могут быть предъявлены. Если вы не согласны с любым пунктом перечисленным выше, вы не можете использовать данный сайт и информация размещенную на нем (сайте/странице), немедленно покиньте данный сайт. В случае нарушения любого пункта перечисленного выше, штраф 55! (Пятьдесят пять факториал, Денежную единицу (имеющую самостоятельную стоимость) можете выбрать самостоятельно, выплаичвается товарами в течение 7 дней с момента нарушения.)