(no subject)
Sep. 21st, 2013 03:31 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
cat_muciusБезопасность, разное.
1. В Windows 8 появилась такая штука: возможность логиниться с "microsoft account" a.k.a Live ID. Великолепный ход. С одной стороны, юзеру это реально удобно: один аккаунт для массы всего. С другой, юзера ко всей микрософтовской экосистеме привязывает ещё крепче. С третьей, от потрёпаной юзерской privacy оттяпали ещё один солидный кус. А с четвёртой, впервые ключи к миллионам личных компьютеров (а также хранимым на них паролям к другим ресурсам и приватным ключам от сертификатов и инфокарт) передаются - совершенно легально и добровольно - на хранение напрямую доброй корпорации Microsoft.
Причём для некоторых сценариев даже неважно, к примеру, хранит ли Микрософт пароли в криптованном виде и может ли их расшифровать: кто подтверждающий токен выдаёт, тот систему и контролирует, извините... Так что пользоваться не советую, мнээ, не советую. Съедят. Стоит лишь захотеть съесть, конечно.
В общем, мы сейчас имеем счастье наблюдать схему очень дешёвого, но поразительно результативного подкупа в миллионных масштабах.
(Кстати. Я сейчас провёл несколько часов в попытках найти какую-то нормальную документацию по этому делу - message flows, диаграммы, описание протоколов и криптоопераций. Не нашёл ни черта - ни через гугл, ни на MSDN, ни на Technet. Скажите, это я дурак и параноик, или оно действительно нигде не опубликовано? Выглядит это очень странно, учитывая, что очень подробная информация по Керберосу, или PKI, или инфокартам, или ADFS находится на том же Технете с полпинка).
Полезно рассмотреть с этой точки зрения также Azure ACS. Вкратце идея: допустим, у нас есть сайт, на который мы хотим пускать юзеров - но не заставляя их заводить очередной местный аккаунт, а позволяя логиниться с существующими: от Гугла, Твиттера, Фейсбука, того же Микрософта. Но для этого надо налаживать траст между сайтом и гуглом-твиттером, надо, чтобы сайт умел использовать протоколы всех перечисленных. А они разные. Приходит Микрософт и говорит: дорогой вебмастер, не волнуйся! Используй нашу замечательную службу-посредник ACS, наладь траст только с ней - а уж она с гуглами-фейсбуками сама договорится.
Чтож, замечательно. Это реально удобно. Одно но: это значит, что доступ к сайту контролирует не юзер, и даже не identity provider, которому юзер выбрал доверять - а Микрософт. И к данным юзера на сайте Микрософт при желании добирается как нефиг делать, безо всякой нужды знать его пароли.
2. Без связи с предыдущим. Читаю очередную статью и в который раз натыкаюсь: Kerberos, мол, замечательный протокол, но вне корпоративных сетей неприменим, поскольку, дескать, какой же админ решится KDC в интернет обнажить беззащитным 88-м портом? Вот, думаю: а почему бы нет, собственно? Чем это он так уязвим, что ADFS выставлять в Сеть можно, а его нет? Шифрование на месте по определению, на то и Цербер. DoS? Вроде нет.
(Вообще интересно: а насколько реально опасно domain controllers целиком поместить в Сеть, если провести нормальный hardening, поубирать всё лишнее, типа NTLM, включить IPsec где можно? Много работы, но и результат может быть стоящий).
Иное дело, что а.) тем, у кого нет аккаунта в домене и кто не сидит на доменном компе, доступный KDC ничем не поможет, б.) степень беспарольности, которую даёт Керберос, будучи применённой вне родной сети, админов может и напрягать.
1. В Windows 8 появилась такая штука: возможность логиниться с "microsoft account" a.k.a Live ID. Великолепный ход. С одной стороны, юзеру это реально удобно: один аккаунт для массы всего. С другой, юзера ко всей микрософтовской экосистеме привязывает ещё крепче. С третьей, от потрёпаной юзерской privacy оттяпали ещё один солидный кус. А с четвёртой, впервые ключи к миллионам личных компьютеров (а также хранимым на них паролям к другим ресурсам и приватным ключам от сертификатов и инфокарт) передаются - совершенно легально и добровольно - на хранение напрямую доброй корпорации Microsoft.
Причём для некоторых сценариев даже неважно, к примеру, хранит ли Микрософт пароли в криптованном виде и может ли их расшифровать: кто подтверждающий токен выдаёт, тот систему и контролирует, извините... Так что пользоваться не советую, мнээ, не советую. Съедят. Стоит лишь захотеть съесть, конечно.
В общем, мы сейчас имеем счастье наблюдать схему очень дешёвого, но поразительно результативного подкупа в миллионных масштабах.
(Кстати. Я сейчас провёл несколько часов в попытках найти какую-то нормальную документацию по этому делу - message flows, диаграммы, описание протоколов и криптоопераций. Не нашёл ни черта - ни через гугл, ни на MSDN, ни на Technet. Скажите, это я дурак и параноик, или оно действительно нигде не опубликовано? Выглядит это очень странно, учитывая, что очень подробная информация по Керберосу, или PKI, или инфокартам, или ADFS находится на том же Технете с полпинка).
Полезно рассмотреть с этой точки зрения также Azure ACS. Вкратце идея: допустим, у нас есть сайт, на который мы хотим пускать юзеров - но не заставляя их заводить очередной местный аккаунт, а позволяя логиниться с существующими: от Гугла, Твиттера, Фейсбука, того же Микрософта. Но для этого надо налаживать траст между сайтом и гуглом-твиттером, надо, чтобы сайт умел использовать протоколы всех перечисленных. А они разные. Приходит Микрософт и говорит: дорогой вебмастер, не волнуйся! Используй нашу замечательную службу-посредник ACS, наладь траст только с ней - а уж она с гуглами-фейсбуками сама договорится.
Чтож, замечательно. Это реально удобно. Одно но: это значит, что доступ к сайту контролирует не юзер, и даже не identity provider, которому юзер выбрал доверять - а Микрософт. И к данным юзера на сайте Микрософт при желании добирается как нефиг делать, безо всякой нужды знать его пароли.
2. Без связи с предыдущим. Читаю очередную статью и в который раз натыкаюсь: Kerberos, мол, замечательный протокол, но вне корпоративных сетей неприменим, поскольку, дескать, какой же админ решится KDC в интернет обнажить беззащитным 88-м портом? Вот, думаю: а почему бы нет, собственно? Чем это он так уязвим, что ADFS выставлять в Сеть можно, а его нет? Шифрование на месте по определению, на то и Цербер. DoS? Вроде нет.
(Вообще интересно: а насколько реально опасно domain controllers целиком поместить в Сеть, если провести нормальный hardening, поубирать всё лишнее, типа NTLM, включить IPsec где можно? Много работы, но и результат может быть стоящий).
Иное дело, что а.) тем, у кого нет аккаунта в домене и кто не сидит на доменном компе, доступный KDC ничем не поможет, б.) степень беспарольности, которую даёт Керберос, будучи применённой вне родной сети, админов может и напрягать.
