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

Ответ 1

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

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

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

Ответ 2

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

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

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

Ответ 3

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

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

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

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

Ответ 4

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

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

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

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

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

Использовать цепочку ключей какого-то типа

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

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

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

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

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

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

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

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

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

Ответ 5

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

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

Ответ 6

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

Ответ 7

OSX: используйте брелок

Windows: используйте CryptProtectData и CryptUnprotectData​​p >

Linux: используйте GNOME Keyring и KDE KWallet