forked from vlsergey/infosec
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathos_passwords.tex
54 lines (38 loc) · 10.2 KB
/
os_passwords.tex
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
\section[Пароли и аутентификация в ОС]{Хранение паролей и \protect\\ аутентификация в ОС}
\selectlanguage{russian}
Для усложнения подбора пароля и избежания словарной атаки перед процедурой хэширования используется добавление к паролю <<соли>> -- случайной битовой строки. \emph{<<Солью>>} (salt)\index{соль} называется (псевдо)случайная битовая строка $s$, добавляемая к аргументу $m$ (паролю) функции хэширования $h(m)$ для рандомизации хэширования одинаковых сообщений.
<<Соль>> применяется для избежания словарных атак. \emph{Словарная} атака заключается в том, что злоумышленник один раз заранее вычисляет таблицы хэшей от наиболее \emph{вероятных} сообщений, то есть составляет словарь пароль-хэш, и далее производит поиск по вычисленной таблице для взламывания исходного сообщения. Ранее словарные атаки использовались для взлома паролей $m$, которые хранились в виде обычных хэшей $h(m)$. Усовершенствованной словарной атакой является метод радужных таблиц, позволяющий практически взламывать хэши длиной до 64--128 бит. Использование <<соли>> делает невозможной словарную атаку, так как значение функции вычисляется уже не от оригинального пароля, а от конкатенации <<соли>> и пароля.
<<Соль>> может храниться как отдельное значение, единственное и уникальное для системы целиком, так и быть уникальной для каждого сохранённого пароля и храниться со значением функции хэширования:
\begin{itemize}
\item $s ~\|~ h(s ~\|~ m)$;
\item $s ~\|~ h(m ~\|~ s)$;
\item $s_1 ~\|~ h(m ~\|~ s_1 ~\|~ s_2)$.
\end{itemize}
В первом случае функция хэширования вычисляется от конкатенации (склеивания) <<соли>> и пароля пользователя. Во втором случае в строке сначала идёт пароль, а потом -- <<соль>>. Это позволяет немного усложнить задачу злоумышленнику при переборе паролей (он не сможет сократить время вычисления значения функции хэширования за счёт одинакового префикса у всех аргументов функции хэширования). В третьем случае используется сразу две <<соли>> -- одна хранится вместе с паролем, а вторая выступает внешним параметром, хранящимся отдельно от базы данных паролей.
В рассмотренной ранее модели построения паролей в виде слогов с элементами небольшой модификации мы получили количество паролей около $2^{70}$ для 12-символьных паролей. Данный объём вычислений уже почти достижим. Следовательно, даже <<соль>> не защищает пароли от взлома, если у злоумышленника есть доступ к файлу с паролями или возможность неограниченных попыток аутентификации. Поэтому файлы с паролями дополнительно защищаются, а в системы аутентификации по паролю вводят ограничения на попытки неуспешной аутентификации.
\subsection[Unix]{Хранение паролей в Unix}
В ОС Unix пароль $m$ пользователя хранится в файле \texttt{/etc/shadow} в виде хэша (SHA, MD5 и~т.~д.) или результата шифрования (DES, Blowfish и~т.~д.), вычисленного с <<солью>> $s$ длиной от 2 (для функции crypt в оригинальной ОС UNIX) до 16-ти (для Blowfish в OpenBSD) ASCII-символов. То, как используется <<соль>>, зависит от используемого алгоритма. Например, в традиционном алгоритме, используемом в оригинальном UNIX, <<соль>> модифицирует s-блоки и p-блоки в протоколе DES.
Файл \texttt{/etc/shadow} доступен только привилегированным процессам, что вносит дополнительную защиту.
\subsection[Windows]{Хранение паролей и аутентификация в \protect\\ Windows}
%[MS-NLMP]: NT LAN Manager (NTLM) Authentication Protocol Specification -- 09/25/2009, Rev. 11.0
%http://blogs.technet.com/authentication/archive/2006/04/07/ntlm-s-time-has-passed.aspx
%http://technet.microsoft.com/en-us/library/cc755284(WS.10).aspx -- Windows Authentication, Updated: February 7, 2008
%http://207.46.16.252/en-us/magazine/2006.08.securitywatch.aspx - The Most Misunderstood Windows Security Setting of All Time, Jesper Johansson
%http://en.wikipedia.org/wiki/NTLM
%http://www.windowsnetworking.com/nt/atips/atips92.shtml
ОС Windows, начиная с Vista, Server 2008, Windows 7, сохраняет пароли в виде NT-хэша, который вычисляется как 128-битовый хэш MD4 от пароля в Unicode кодировке. NT-хэш не использует <<соль>>, поэтому применима словарная атака. На словарной атаке основаны программы поиска (взлома) паролей для Windows. Файл паролей называется SAM (\langen{Security Account Manager}) в случае локальной аутентификации. Если пароли хранятся на сетевом сервере, то они хранятся в специальном файле, доступ к которому ограничен.
В последнем протоколе аутентификации NTLMv2\index{протокол!NTLM}\index{протокол!NTLMv2}~\cite{MS-NLMP} пользователь для входа в свой компьютер аутентифицируется либо локально на компьютере, либо удалённым сервером, если учётная запись пользователя хранится на сервере. Пользователь с именем $user$ вводит пароль в программу-\emph{клиент}, которая, взаимодействуя с программой-\emph{сервером} (локальной или удалённой на сервере домена $domain$), аутентифицирует пользователя для входа в систему.
\begin{enumerate}
\item Клиент $\rightarrow$ Сервер: запрос аутентификации.
\item Клиент $\leftarrow$ Сервер: 64-битовая псевдослучайная одноразовая метка $n_s$.
\item Вводимый пользователем пароль хэшируется в $\textrm{NThash}$ без <<соли>>. Клиент генерирует 64-битовую псевдослучайную одноразовую метку $n_c$, создаёт метку времени $ts$. Далее вычисляются 128-битовые имитовставки\index{имитовставка} $\HMAC$ на хэш-функции MD5 с ключами $\textrm{NT-hash}$ и $\textrm{NTOWF}$:
\[ \textrm{NThash} = \text{MD4}(\text{Unicode}(\text{пароль})), \]
\[ \textrm{NTOWF} = \textrm{HMAC-MD5}_{\textrm{NThash}}(user, domain), \]
%\[ \text{LMv2-response} = \text{HMAC-MD5}_{\text{NTLMv2-hash}}(n_c, n_s), \]
\[ \textrm{NTLMv2-response} = \textrm{HMAC-MD5}_{\textrm{NTOWF}}(n_c, n_s, ts, domain). \]
\item Клиент $\rightarrow$ Сервер: $(n_c, \textrm{NTLMv2-response})$. %LMv2-response,
\item Сервер для указанных имён пользователя и домена извлекает из базы паролей требуемый NT-hash, производит аналогичные вычисления и сравнивает значения имитовставок. Если они совпадают, аутентификация успешна.
\end{enumerate}
В случае аутентификации на локальном компьютере сравниваются значения $\textrm{NTOWF}$: вычисленные от пароля пользователя и извлечённые из файла паролей SAM.
Как видно, протокол аутентификации NTLMv2 обеспечивает одностороннюю аутентификацию пользователя серверу (или своему ПК).
При удалённой аутентификации по сети последние версии Windows используют протокол Kerberos, который обеспечивает взаимную аутентификацию, и, только если аутентификация по Kerberos не поддерживается клиентом или сервером, она происходит по NTLMv2.