Пароль от Wi-Fi в открытом виде в файле System.Cfg

Пароль от Wi-Fi в открытом виде в файле System.Cfg, UniFi Network

Ub1qu1ti

Guest

16.12.2016 00:37:00

Всем привет! Меня беспокоит, почему пароль от Wi-Fi хранится в открытом виде в файле System.Cfg. В Windows он находится по пути users/?/Ubiquiti Unifi/data/devices/uap/, а затем в папке с MAC-адресом клиента. Открываешь файл System.Cfg — и там без шифрования видны логин и пароль... Неужели так и должно быть?

disky42

Guest

06.04.2018 19:48:00

Привет, понятно — контроллер всё равно имеет админские права, так что наличие или отсутствие PSK не имеет значения. Спасибо, что прояснили это здесь. Есть ли какая-нибудь документация, которая описывает эти огромные возможности программного обеспечения контроллера вместе с требованиями к безопасности, которые из этого вытекают? В этом есть смысл, но я не знал... (поскольку меня не интересуют функции мониторинга и аналитики) я пока отключу программное обеспечение контроллера, пока оно не понадобится. В моём случае я время от времени включаю и выключаю гостевую Wi-Fi сеть — поэтому буду запускать контроллер только для переключения состояния и сразу же его выключать. С уважением.

mkettler

Guest

02.04.2018 20:48:00

Я бы не сказал, что контроллер уязвим по замыслу. Он *должен* работать на достаточно защищённом сервере внутри подсетей управления вашей сетью, а не болтаться в открытом интернете. Но ты прав, контроллер не обеспечивает безопасность на уровне операционной системы (если это не cloudkey). Защищать контроллер — ваша задача, и делать это нужно обязательно. Даже если там не хранить ключи Wi-Fi, UniFi контроллер по-прежнему имеет полный административный доступ к точкам доступа. Он может обновлять их Linux OS, прошивки, перенастраивать их, менять пароль Wi-Fi, скачивать конфигурацию и управлять ими практически любым способом.

Если кто-то получил доступ к контроллеру, он может просто зайти через него на ваши точки доступа и выудить Wi-Fi ключи. Но тогда уже сам факт кражи ключей — не самый страшный момент. Контроллер — это не просто сборщик статистики. Это основная админская консоль для всего, что под его контролем. Он может перенастроить и администрировать любое устройство Unifi в вашей сети. Да, его нужно защищать соответствующим образом. Если его взломают, это намного хуже, чем потерять Wi-Fi ключ — вы отдаёте злоумышленнику полный административный доступ к точкам доступа. А если у вас ещё есть USG или коммутатор — доступ злоумышленника распространяется и на них.

По поводу функционала: да, контроллер хранит ключи Wi-Fi для удобства, чтобы при повторном присоединении точек доступа не пришлось вручную вводить пароли. Да, можно не хранить ключи на контроллере, но он должен быть частью сети даже лучше защищённой, чем сами точки доступа. К тому же, учитывая, что контроллер имеет админский доступ к точкам доступа, отказ от хранения ключей на контроллере практически не даёт никакой дополнительной безопасности.

Лично я думаю, что точки доступа более «уязвимы по замыслу». Они расположены на периферии сети и доступны для атаки по радио с любого устройства в зоне сигнала (включая устройства с направленными антеннами для увеличения дальности). Хотя они и спроектированы с учётом защиты, чтобы эти атаки были безуспешными, полностью защищёнными их назвать нельзя. К тому же, физическая безопасность точек доступа оставляет желать лучшего... Если контроллер размещён в запертой серверной (и должен там быть), то точки доступа монтируются прямо на потолке в вестибюле. У некоторых даже наружные точки доступа стоят. Эти устройства не защищены от того, кто имеет физический доступ и пару стяжек для быстрого снятия с крепления.

disky42

Guest

02.04.2018 20:24:00

Привет, спасибо за твоё мнение. Во-первых, я назвал это «пароль Wi-Fi», чтобы соответствовать выбранной теме, но ладно, давайте возьмём PSK.

Я понимаю, что точки доступа (и клиенты Wi-Fi) действительно должны хранить свои PSK. Это нормально и ожидаемо.

Точки доступа — это серийные устройства, которые должны быть защищены так, чтобы никому (независимо от усилий) не удалось взломать их. То же самое касается всех точек доступа на рынке, которые сейчас обычно не имеют SecureElement или TPM для защиты PSK — думаю, из-за стоимости.

В отличие от этого, «контроллер» — это программа, которая работает на любом устройстве и не обеспечивает никакой защиты (и не может этого сделать). Но такое ПО обычно создаётся для работы 24/7 с целью сбора аналитических данных. Значит, оно по определению уязвимо, и если его взломают, ущерб должен быть минимальным, так что отключение этой функции может быть разумным решением.

Так в чём смысл вообще хранить PSK на контроллере? Я могу предположить, что это сделано для удобства при добавлении новых точек доступа к существующим сетям... Есть ли ещё какие-то варианты?

И вообще, зачем нужен API для запроса PSK? В чём тут кейс использования?

Или хотя бы, пожалуйста, задокументируйте факт хранения PSK, чтобы клиенты знали (или могли знать), что делать в случае взлома контроллера.

С наилучшими пожеланиями.

mkettler

Guest

02.04.2018 17:19:00

редактирую: Хорошо, твой вопрос немного точнее, чем я сначала понял... Тем не менее, каждая точка доступа в твоей сети обязана хранить этот ключ. Если не сохранять его на контроллере, это экономит *одно* место для хранения, но не меняет того факта, что он всё равно хранится на каждой точке доступа в твоей сети.

Во-первых: Wifi PSK — это *НЕ* пароль. Это предварительно общий ключ. Если тебе кажется, что они одинаковые — это не так. Поэтому перестань называть WiFi PSK паролями. Все называют их «wifi паролями», но единственный wifi-режим, где есть пароли — это enterprise mode, где для аутентификации используется RADIUS-сервер. Любой режим с «PSK» в названии не поддерживает пароли, там используются предварительно общие ключи.

В чём разница? Пароли нужны для аутентификации пользователей. Чтобы их авторизовать, и так далее. Серверам нужно только проверить, что пользователь знает правильный пароль, поэтому пароли можно хранить в зашифрованном (хешированном) виде. Серверу не нужно использовать сам пароль, он лишь проверяет его и тут же забывает.

Ключи нужны для защиты передачи данных с помощью шифрования. Ключи должны использоваться с обеих сторон, чтобы правильно понимать друг друга. Если шифрование симметричное (как в WiFi PSK), обе стороны обязаны использовать одинаковый ключ, чтобы корректно общаться.

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

Это абсолютно неотъемлемая часть работы WiFi PSK режима. И да, это ужасная безопасность.

Так что отвечая на твой вопрос: почему этот «пароль» хранится? Потому что это не пароль. Это предварительно общий ключ.

Если хочешь «вводить его заново каждый раз», тебе придётся вводить его на *ОБЕИХ* устройствах, каждый раз. То есть каждый раз, когда ты приходишь домой, надо вводить ключ на клиенте, потом подключаться к твоей точке доступа с каким-то проводным клиентом и там тоже вводить ключ, чтобы соединиться. Для кого-то это возможно, но очень неудобно.

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

И я имею в виду *КАЖДЫЙ* раз. Включаешь Xbox — вводишь ключ, бежишь к точке доступа и вводишь его там тоже. Выключаешь на ночь и снова включаешь завтра? Делаешь то же самое с обеих сторон. Едешь на работу и возвращаешься домой? Лучше каждый раз вводить ключ с обеих сторон, чтобы телефон смог переподключиться, каждый день.

Я не знаю ни одного производителя WiFi-устройств, который реализует вариант без сохранения ключа в PSK режиме, потому что это непрактично. Все WiFi-устройства, которые я когда-либо использовал (iPhone, Android, Windows, Mac, IP-камеры, медиаплееры, игровые приставки, точки доступа пяти разных брендов) хранят ключ, если работает PSK режим.

Режим PSK сильно снижает безопасность ради удобства.

Тот факт, что ключи должны быть доступны в открытом виде на обеих сторонах при установлении соединения — часть этой компромисса.

Хочешь пароли? Для этого есть enterprise mode. Пользуйся им.

Не хочешь настраивать RADIUS? Тогда PSK — твой единственный вариант, но помни, у тебя теперь общий ключ, и он хранится с обеих сторон.

disky42

Guest

01.04.2018 11:10:00

Привет!
Кроме того,
1) пароль хранится в открытом виде в файле базы данных «ace.0» контроллера UniFi 5.6.26 (%>strings ace.0 | less --> например, ищите x_passphrase для беспроводных паролей).
2) Есть API, который выдает пароль от Wi-Fi в открытом виде: %>unifi_sh_api's «unifi_api /info/wlanconf/».

Так в чём вообще смысл хранить этот пароль?
Я считаю, что лучше сразу отправлять его всем подключенным WLAN-устройствам для настройки и потом забыть — если будут установлены новые точки доступа, клиент сможет ввести пароль заново.
По крайней мере, я не ожидал, что ПО контроллера сохраняет мой Wi-Fi пароль в открытом виде — это точно должно быть ясно задокументировано!
С уважением.

mkettler

Guest

13.05.2017 13:11:00

Пароли всегда нужно хранить с помощью одностороннего хэширования? Конечно, да. Совместимо ли это с тем, чтобы устройство сохраняло пароль и автоматически входило за вас? Нет. Но... Нет, серьёзно, просто так сохранить данные в необратимом виде и при этом иметь возможность использовать их в оригинальном виде по требованию и войти в систему — невозможно. Заявление Victorhooi совершенно справедливо. Хранить пароли так, чтобы устройства или программы могли автоматически входить за вас — это риск для безопасности, потому что устройство или программа должны хранить этот пароль в формате, обратимом для восстановления. Можно попытаться усложнить хранение, но сделать его по-настоящему односторонним нельзя, иначе вход будет невозможен. Сохранение паролей — риск для безопасности, который многие соглашаются принять, потому что вручную вводить пароль каждый раз, когда хочешь проверить почту, утомительно. Кто-то осознаёт, на что идёт, другие предполагают, что это безопасно. Если вы хотите обеспечить безопасность, всегда храня пароли в хэшированном виде:
- Никогда не позволяйте устройству сохранять пароль и входить за вас. Всегда вводите пароль самостоятельно каждый раз, когда это требуется.
- Никогда не пользуйтесь системами с PSK (предварительно распределённый ключ), если не вводите пароль вручную на обеих сторонах каждый раз.
Если это неудобно, берите на себя осознанный риск, но понимайте, что именно вы рискуете.

mkettler

Guest

13.05.2017 11:07:00

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

Однако это значит, что хэш ни при каких обстоятельствах нельзя использовать там, где нужно хранить пароль для автоматического входа. Как только пароль хранится в виде хэша, его нельзя ни восстановить, ни использовать для входа.

PSK (предварительно установленный ключ), по самой своей сути, не может храниться в виде хэша на обеих сторонах соединения. PSK — это общие ключи, а не пароли. Они должны храниться в обратимом виде или вводиться вручную на обеих концах каждый раз, когда используется соединение. Это изначально небезопасно, если кто-то получит доступ к устройству с сохранённым PSK, так что если это тебя беспокоит — никогда не используй PSK, включая все варианты PSK в Wi-Fi.

То же самое относится к почтовым клиентам/приложениям, которые хранят твой пароль. Чтобы почтовый клиент мог автоматически входить в аккаунт, он должен хранить пароль в обратимом виде, потому что ему нужно авторизоваться. Если тебя это напрягает — не сохраняй пароль почты на телефоне.

Эти ситуации могут вызывать у тебя дискомфорт, и это нормально, но никакое ПО не изменит этой базовой истины. Чтобы войти в систему, нужна именно оригинальная форма пароля либо нечто равноценное по использованию (например, приватный ключ в сертификате). Это что-то должно где-то храниться, и лучшее место — твоя голова. Если что-то вводит пароль автоматически... то устройство знает твой пароль. Оно может пытаться не показывать его, но однозначно хранит его в обратимом виде.

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

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

Хэшированные пароли — это немного как замки: они проверяют ключ, но сами по себе не являются ключом. Правда, аналогия не идеальна, потому что с хэшем нельзя восстановить пароль (хотя если пароль слишком простой, можно пытаться угадать его, и хэш подтвердит правильность). Но если разобрать замок, можно понять, какой ключ в него подходит. Так что лучше аналогий я не придумал.

PSK хуже, потому что ключ должен быть у обеих сторон одновременно. По крайней мере при аутентификации паролем “сервер” хранит пароль в хэше. С PSK так не получится.

Понимай риски, которые ты берёшь, когда используешь PSK или позволяешь программам входить автоматом.

Если хочешь, чтобы твой Wi-Fi пароль никогда не хранился в открытом виде, используй корпоративный режим и не позволяй клиентскому устройству хранить пароль — вводи его вручную каждый раз при подключении. Если это слишком неудобно, тогда решай, какой риск готов принять.

WiflyGuy Guest	#9 06.05.2017 12:40:00 Я знаю, что это очень старая запись, но я чувствую необходимость ответить. Это утверждение... «К тому же, как я уже сказал — это как в любой программе, где пароли сохраняются локально: что бы ты ни делал, это всего лишь обфускация, системе всё равно нужен способ прочитать пароли с диска (если только ты не вводишь пароль каждый раз при запуске службы Unifi controller)»... — абсолютно неверно. Пароли никогда не должны храниться в открытом виде, их нужно хранить в виде «солёных» хешей. Хеширование — это односторонний механизм «шифрования», то есть пароли можно захешировать, но нельзя обратно расшифровать. Я мог бы написать целое сочинение о том, почему пароли не стоит хранить в открытом виде, но интернет уже прекрасно об этом рассказал.

Читают тему (гостей: 1)