![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Windows 8 отличается от предыдущих версий Windows NT тем, что позволяет организовать вход в систему, защищённый не только паролем, а например, картинкой.
Картинка работает так: пользователь проводит пальцем по определённым областям или линиям, делает это в определённом порядке, и таким образом происходит вход в систему.
Вход по паролю со времён NT4 работает так: к паролю применяется одностороняя функция (MD4) и результат хэширования сравнивается с константой из реестра. Константу из реестра можно конечно заменить, но по крайней мере плейнтекст пароля так и останется неразгаданным (мало ли где ещё он применяется?). Конечно, по хорошему там должен быть HMAC и salt как минимум, а в идеале вообще PBKDF2, однако, как говорится, "не стреляйте в пианиста — он играет, как умеет".
Возникает ряд вопросов: каким образом хэшируется траектория перемещения пальцем по экрану и соответствующие паузы? В каких пределах допускается отклонение от траектории? Как вообще говоря, соединить неточную траекторию и точный хэш? Манхэттенская метрика не подойдёт, ведь в этом случае можно будет легко подобрать траекторию по хранимому хэшу методом последовательного перебора траекторий и сравнения начальных бит в цепочке. Другие линейные и локально-линейные преобразования не подойдут по той же причине. А нелинейные, перемешивающие, криптографически стойкие преобразования приведут к тому, что малейшее отклонение в траектории приведёт к изменению в среднем 50% битов хэша, и Windows не сможет определить, что полученная траектория близка к требуемой.
Как же Microsoft решила эту проблему? Применяет грубую квантификацию пространства? Может, какой-то feature extraction: выделение прямых, дуг, колец? Фильтрацию высоких частот в радиусе кривизны параметрически заданной кривой? Может, они нашли какой-то хитрый инвариант для этих кривых? Хранят/вычисляют хэши сразу для 1024*1024 разных близких траекторий? Разбивают изображение на неровные плитки на основе анализа краёв/областей и рассматривают далее эти плитки как аналог кнопок на клавиатуре? Или может, они вынесли операцию сравнения траектории с эталоном в облако?
Корректна ли постановка задачи, вообще? Достаточно ли энтропии в этой кривой? Сравнима ли энтропия с 14-символьным паролем? А если взять с учётом упрощений, необходимых для надёжного "узнавания" серии похожих кривых? Какова стойкость метода к полному перебору кривых? Какова стойкость метода к направленному перебору кривых, на основе границ между монотонно окрашенными областями изображения?
Расслабьтесь. Всё намного проще. Они просто берут плейнтекстовый пароль и данные об опорных точках аутентифицирующей кривой ипишут их на диск обратимо шифруют AESом и пишут на диск, в файл %SYSTEM_DIR%/config/systemprofile/AppData/Local/Microsoft/Vault/4BF4C442-9B8A-41A0-B380-DD4A704DDB28. Мастер-ключ для AES хранится рядом.
http://www.passcape.com/index.php?section=blog&cmd=details&id=27&setLang=2
Разумеется, никто не мешает расшифровать это всё обратно. Не одна ж винда такая хитрая, для других тоже не секрет, что такое AES.
Так что если юзер закрыл вход в систему с помощью картинки, по которой надо провести пальцем, то всё вообще замечательно: имея специальный LiveCd, можно не только сбросить ему пароль, как это было раньше, но и восстановить пароль в плейнтексте. А вместе с паролем и траекторию. Причём восстановить мгновенно, без перебора по словарю и без rainbow-таблиц. А он и знать не будет, бедолага.
Интересно, можно ли таким макаром на рабочей станции, включённой в домен, загрузить для локального изучения аутентифицирующие кривые для всех аккаунтов в домене?
Картинка работает так: пользователь проводит пальцем по определённым областям или линиям, делает это в определённом порядке, и таким образом происходит вход в систему.
Вход по паролю со времён NT4 работает так: к паролю применяется одностороняя функция (MD4) и результат хэширования сравнивается с константой из реестра. Константу из реестра можно конечно заменить, но по крайней мере плейнтекст пароля так и останется неразгаданным (мало ли где ещё он применяется?). Конечно, по хорошему там должен быть HMAC и salt как минимум, а в идеале вообще PBKDF2, однако, как говорится, "не стреляйте в пианиста — он играет, как умеет".
Возникает ряд вопросов: каким образом хэшируется траектория перемещения пальцем по экрану и соответствующие паузы? В каких пределах допускается отклонение от траектории? Как вообще говоря, соединить неточную траекторию и точный хэш? Манхэттенская метрика не подойдёт, ведь в этом случае можно будет легко подобрать траекторию по хранимому хэшу методом последовательного перебора траекторий и сравнения начальных бит в цепочке. Другие линейные и локально-линейные преобразования не подойдут по той же причине. А нелинейные, перемешивающие, криптографически стойкие преобразования приведут к тому, что малейшее отклонение в траектории приведёт к изменению в среднем 50% битов хэша, и Windows не сможет определить, что полученная траектория близка к требуемой.
Как же Microsoft решила эту проблему? Применяет грубую квантификацию пространства? Может, какой-то feature extraction: выделение прямых, дуг, колец? Фильтрацию высоких частот в радиусе кривизны параметрически заданной кривой? Может, они нашли какой-то хитрый инвариант для этих кривых? Хранят/вычисляют хэши сразу для 1024*1024 разных близких траекторий? Разбивают изображение на неровные плитки на основе анализа краёв/областей и рассматривают далее эти плитки как аналог кнопок на клавиатуре? Или может, они вынесли операцию сравнения траектории с эталоном в облако?
Корректна ли постановка задачи, вообще? Достаточно ли энтропии в этой кривой? Сравнима ли энтропия с 14-символьным паролем? А если взять с учётом упрощений, необходимых для надёжного "узнавания" серии похожих кривых? Какова стойкость метода к полному перебору кривых? Какова стойкость метода к направленному перебору кривых, на основе границ между монотонно окрашенными областями изображения?
Расслабьтесь. Всё намного проще. Они просто берут плейнтекстовый пароль и данные об опорных точках аутентифицирующей кривой и
http://www.passcape.com/index.php?section=blog&cmd=details&id=27&setLang=2
Разумеется, никто не мешает расшифровать это всё обратно. Не одна ж винда такая хитрая, для других тоже не секрет, что такое AES.
Так что если юзер закрыл вход в систему с помощью картинки, по которой надо провести пальцем, то всё вообще замечательно: имея специальный LiveCd, можно не только сбросить ему пароль, как это было раньше, но и восстановить пароль в плейнтексте. А вместе с паролем и траекторию. Причём восстановить мгновенно, без перебора по словарю и без rainbow-таблиц. А он и знать не будет, бедолага.
Интересно, можно ли таким макаром на рабочей станции, включённой в домен, загрузить для локального изучения аутентифицирующие кривые для всех аккаунтов в домене?
