Защита паролей пользователей в настольных приложениях (ред. 2)

Question

Я создаю клиент Twitter и оцениваю различные способы защиты данных для входа пользователя.

ВАЖНЫЙ:Мне нужно защитить данные пользователя от других приложений.Например, представьте, что произойдет, если бот начнет воровать пароли Twhirl или Hotmail/GMail/Yahoo/Paypal из приложений, запускаемых на рабочем столе пользователя.

Уточнение:Я уже спрашивал об этом без «важной» части, но пользовательский интерфейс stackoverflow не помогает добавлять детали позже в беседе вопросов и ответов.

• Хеширование, видимо, этого не делает
• Обфусцировать обратимым образом — это все равно, что пытаться спрятаться за пальцем.
• Простой текст звучит и, возможно, является беспорядочным.
• Требование от пользователя каждый раз вводить свой пароль сделало бы приложение утомительным.

Есть идеи ?

Answer 1

Это уловка-22.Либо вы заставляете пользователя каждый раз вводить свой пароль, либо храните его небезопасно (запутанно, зашифровано и т. д.).

Чтобы исправить это, нужно, чтобы большее количество операционных систем включало встроенные менеджеры паролей, такие как Keychain в OS X.Таким образом, вы просто сохраняете свой пароль в связке ключей, операционная система сохраняет его в безопасности, и пользователю нужно ввести только 1 мастер-пароль.Многие приложения (например, Skype) в OS X используют Keychain, чтобы делать именно то, что вы описываете.

Но поскольку вы, вероятно, используете Windows, я бы посоветовал просто использовать запутывание и шифрование.Я думаю, у вас может быть небольшая паранойя по поводу ботов, ворующих пароли;Если ваше приложение не имеет большой базы пользователей, вероятность того, что кто-то нацелится на него и попытается украсть пароли, довольно мала.Кроме того, им также потребуется доступ к файловой системе жертвы.Если это так, то, вероятно, у них есть вирус/червь и у них более серьезные проблемы.

Answer 2

Я думаю, что здесь вы упускаете более широкую картину:

Если рабочий стол взломан, вы F#*%ED!

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

Answer 3

Сохраните его в виде обычного текста и сообщите пользователю.

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

Если пользователи не могут исключить из коробки плохих людей, то в результате все секретные данные, которыми они располагают, известны доктору.Зло.Не имеет значения, зашифровано оно или нет.И если они могут не допускать злых людей, зачем беспокоиться о хранении паролей в виде обычного текста?

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

Answer 4

Если вы создаете клиент Twitter, используйте их API.

В Твиттере очень хорошо документация, поэтому советую прочитать все это прежде, чем делать клиента.Самая важная часть этого вопроса заключается в том, что вам не нужно хранить пароли, храните OAuth токен вместо этого.Вам необходимо использовать xAuth этап, чтобы получить токен OAuth, а затем при необходимости использовать другие API Twitter с этим токеном OAuth.

Xauth предоставляет возможность для настольных и мобильных приложений обменять имя пользователя и пароль на токен OAuth Access.Как только токен доступа будет извлечен, разработчики с поддержкой Xauth должны избавиться от входа в систему и пароля, соответствующего пользователю.

Вы никогда не храните пароли, если это вам сойдет с рук

При использовании OAuth худшее, что может случиться, это то, что третья сторона (хакер в черной шляпе) получит доступ к этой учетной записи Twitter, но не к пароль.Это защитит пользователей, которые по наивности используют один и тот же пароль для нескольких онлайн-сервисов.

Используйте какой-нибудь брелок

Наконец, я согласен с тем, что для хранения конфиденциальной информации OAuth следует использовать готовые решения, такие как связка ключей OSX, скомпрометированная машина раскроет только информацию о разблокированных в данный момент связках ключей.Это означает, что в многопользовательской системе цепочки для ключей становятся уязвимыми только у вошедших в систему пользователей.

Другие ограничения по повреждению

Возможно, я что-то пропустил. Возьмите в Google «лучшие методы обеспечения безопасности» и начните читать, что может быть актуально.

РЕДАКТИРОВАТЬ (в ответ на желаемое общее решение)

Вы хотите, без участия пользователя, получить доступ к онлайн-сервису.Это означает, что обычно у вас есть максимум контроль доступа на уровне пользователя к учетным данным аутентификации с помощью чего-то вроде Keychain.

Я никогда не использовал OSX Keychain, поэтому теперь я расскажу о SELinux.В SELinux вы также можете гарантировать, что эти учетные данные аутентификации будут переданы только вашей программе.И если мы продолжим работу на уровне ОС, вы также можете подписать все процессы от загрузки до криптографически, чтобы быть уверенным, что никакая другая программа не может имитировать вашу программу.Все это выходит за рамки типичной пользовательской системы, и при таком уровне настройки вы можете быть уверены, что пользователь не настолько наивен, чтобы его можно было скомпрометировать, или системный администратор достаточно компетентен.На этом уровне мы могли бы защитить эти учетные данные.

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

На данный момент это ограничение ущерба, не сохраняйте пароль в качестве учетных данных для аутентификации.Используйте OAuth, сеансы cookie, соленые хеши и т. д. — все это всего лишь токены, свидетельствующие о том, что в какой-то момент в прошлом вы доказали, что знаете пароль.В любой хорошей системе эти токены могут быть отозваны, по истечении времени и/или периодически обмениваться на новые токены во время активной сессии.

Токен (какой бы формы он ни был) также может содержать дополнительную информацию для аутентификации, не вводимую пользователем, что ограничивает вашу возможность использовать их где-либо еще.Например, он может инкапсулировать ваше имя хоста и/или IP-адрес.Это затрудняет использование учетных данных на других машинах, поскольку для имитации этих форм учетных данных потребуется доступ к соответствующему уровню сетевой инфраструктуры.

Answer 5

После дальнейшего размышления я думаю, что нашел способ.Я буду использовать аутентификацию ASP.net для своего настольного приложения, хранить их учетные данные в Интернете и позволить диспетчеру паролей Internet Explorer обрабатывать локальное кэширование этой вторичной пары или учетных данных за меня.

Мне просто нужно, чтобы они прошли аутентификацию через форму, подобную Facebook-API, во время первого входа в систему.

Answer 6

Я не понимаю...почему шифрование бесполезно?Используйте большой ключ и сохраните его в хранилище ключей компьютера (при условии, что Windows).Готово и сделано.

Answer 7

ОС:Используйте брелок

Окна:Используйте CryptProtectData и CryptUnprotectData.

Линукс:Используйте GNOME Keyring и KDE KWallet.