Защита паролей пользователей в настольных приложениях (Rev 2)
Я делаю клиент для Твиттера и оцениваю различные способы защиты информации для входа в систему.
ВАЖНО: мне нужно защитить данные пользователя от других приложений. Например, представьте, что произойдет, если бот начнет воровать пароли Twhirl или Hotmail/GMail/Yahoo/Paypal из приложений, которые запускаются на рабочем столе пользователя.
Пояснение: я спрашивал об этом раньше без "важной" части, но пользовательский интерфейс stackru не помогает с добавлением деталей позже в диалоге Q/A.
- Хеширование, видимо, не делает этого
- Обфусцировать обратимым образом - все равно что пытаться спрятаться за моим пальцем
- Простой текст звучит и, вероятно, неразборчиво
- Требование от пользователя вводить пароль каждый раз делает приложение утомительным
Есть идеи?
7 ответов
Это подвох-22. Либо вы заставляете пользователя каждый раз вводить свой пароль, либо вы храните его небезопасно (запутанно, зашифровано, что угодно).
Способ исправить это для большего количества операционных систем, чтобы включить встроенные менеджеры паролей - как Цепочка для ключей OS X. Таким образом, вы просто сохраняете свой пароль в связке ключей, ОС сохраняет его в безопасности, и пользователю остается только ввести 1 мастер-пароль. Многие приложения (такие как S kype) в OS X используют Keychain, чтобы делать именно то, что вы описываете.
Но так как вы, вероятно, используете Windows, я бы сказал, что нужно просто запутать и зашифровать. Я думаю, вы можете быть немного параноиком по поводу паролей-воров; если ваше приложение не имеет большой базы пользователей, вероятность того, что кто-то нацелится на него, и, в частности, попытается украсть пароли, довольно мала. Кроме того, они также должны иметь доступ к файловой системе своей жертвы. Если это так, то у них, вероятно, есть вирус / червь и большие проблемы.
Я думаю, что вам не хватает общей картины здесь:
Если рабочий стол скомпрометирован, вы F#*%ED!
Чтобы украсть пароль из вашей программы, в системе должен быть запущен вирус от имени администратора. Если вирус добился этого, то кража паролей из вашей программы окажется в списке вредоносных действий, которые он хочет совершить.
Сохраните его в виде простого текста и дайте знать пользователю.
Таким образом, нет никаких заблуждений о том, какой уровень безопасности вы достигли. Если пользователи начинают жаловаться, рассмотрите возможность размещения на них константы, опубликованной на вашем сайте. Если пользователи продолжают жаловаться, "спрячьте" константу в вашем коде и скажите им, что это плохая безопасность.
Если пользователи не могут держать плохих людей прямо из коробки, то в действительности все секретные данные, которые они имеют, известны доктору Злу. Не имеет значения, зашифровано это или нет. И если они могут не пускать злых людей, зачем беспокоиться о хранении паролей в виде простого текста?
Конечно, я мог бы говорить о своей заднице. Есть ли исследование, показывающее, что хранение паролей в виде простого текста приводит к ухудшению безопасности, чем их запутывание?
Если вы делаете клиент Twitter, используйте его API
Твиттер имеет очень хорошую документацию, поэтому я советую вам прочитать все это, прежде чем делать клиент. Наиболее важной частью этого вопроса является то, что вам не нужно хранить пароли, вместо этого сохраните токен OAuth. Вам нужно использовать этап xAuth для получения токена OAuth, а затем использовать другие API Twitter с этим токеном OAuth, где это необходимо.
xAuth позволяет настольным и мобильным приложениям обмениваться именем пользователя и паролем для маркера доступа OAuth. После получения токена доступа разработчики с поддержкой xAuth должны использовать логин и пароль, соответствующие пользователю.
Вы никогда не храните пароли, если вы можете сойти с рук
При использовании OAuth худшее, что может случиться, - это то, что третья сторона (хакер-хакер) получает доступ к этой учетной записи Twitter, но не к паролю. Это защитит пользователей, которые наивно используют один и тот же пароль для нескольких онлайн-сервисов.
Используйте какой-нибудь брелок
Наконец, я согласен с тем, что готовые решения, такие как цепочка для ключей OSX, должны использоваться для хранения конфиденциальной информации OAuth, а взломанная машина будет раскрывать только информацию о разблокированных в настоящий момент цепочках ключей. Это означает, что в многопользовательской системе только зарегистрированные пользователи становятся уязвимыми для своих цепочек для ключей.
Другие ограничения ущерба
Могут быть вещи, которые я пропустил, взять Google за "лучшие практики безопасности" и начать читать, что может быть актуальным.
РЕДАКТИРОВАТЬ (в ответ на желаемое общее решение для случая)
Вы хотите, если пользователь не вводит, доступ к онлайн-сервису. Обычно это означает, что вы, как правило, имеете контроль доступа на уровне пользователя к учетным данным для аутентификации через что-то вроде связки ключей.
Я никогда не использовал OSX Keychain, поэтому сейчас я расскажу о SELinux. В SELinux вы также можете гарантировать, что эти учетные данные будут предоставлены только вашей программе. И если мы продолжим работу на уровне ОС, вы также можете подписать все процессы от загрузки до криптографии, чтобы быть уверенным, что никакая другая программа не может имитировать вашу программу. Это все за пределами типичной пользовательской системы, и, учитывая этот уровень настройки, вы можете быть уверены, что пользователь недостаточно наивен, чтобы его можно было скомпрометировать, или сисадмин достаточно уступчив. На этом уровне мы могли бы защитить эти полномочия.
Предположим, мы не зашли так далеко, чтобы защитить эти учетные данные, а затем мы можем предположить, что система взломана. В этот момент учетные данные аутентификации становятся скомпрометированными, обфускация / шифрование этих учетных данных на локальной стороне не добавляет никакой реальной безопасности и не сохраняет их часть или все на стороннем сервере. Это легко увидеть, потому что, если пользователь не вводит данные, ваша программа должна загрузить себя, чтобы получить эти учетные данные. Если ваша программа может сделать это без ввода данных, то любой, кто изменил его, может спроектировать ваш протокол обфускации / шифрования / сервера.
На данный момент это ограничение ущерба, не храните пароль в качестве учетных данных аутентификации. Используйте OAuth, сеансы cookie, соленые хэши и т. Д., Все они являются просто токенами, представляющими, что когда-то в прошлом вы доказывали, что знаете пароль. В любой хорошей системе эти токены могут быть отозваны, время истекло и / или обменяться периодическими данными на новый токен во время активного сеанса.
Маркер (в какой бы форме он ни был) также может содержать дополнительную информацию для аутентификации, не связанную с вводом данных пользователем, что ограничивает вашу возможность использовать их в других местах. Например, он может инкапсулировать ваше имя хоста и / или IP-адрес. Это затрудняет использование учетных данных на разных компьютерах, поскольку для имитации этих форм учетных данных потребуется доступ к соответствующему уровню сетевой инфраструктуры.
Я не понимаю... почему шифрование не годится? Используйте большой ключ и сохраните ключ в хранилище ключей компьютера (в предположении Windows). Готово и готово.
При дальнейшем созерцании я думаю, что нашел способ. Я буду использовать аутентификацию ASP.net для настольного приложения своего приложения, хранить их учетные данные в Интернете и позволять диспетчеру паролей Internet Explorer обрабатывать локальное кэширование этой дополнительной пары или учетных данных для меня.
Мне просто нужно, чтобы они проходили аутентификацию через форму Facebook-API во время первого входа в систему.
OSX: используйте связку ключей
Windows: используйте CryptProtectData и CryptUnprotectData
Linux: используйте GNOME Keyring и KDE KWallet