Если вы делаете клиент для Твиттера, используйте его API
Твиттер имеет очень хорошую документацию , поэтому я советую вам прочитать все это перед тем, как сделать клиента. Наиболее важной частью этого вопроса является то, что вам не нужно хранить пароли, вместо этого сохраните маркер OAuth . Вам нужно использовать этап xAuth , чтобы получить токен OAuth, а затем использовать другие API Twitter с этим токеном OAuth, где это необходимо.
xAuth позволяет настольным и мобильным приложениям обмениваться
имя пользователя и пароль для токена доступа OAuth. Однажды токен доступа
разработчики с поддержкой xAuth должны избавиться от имени входа и
пароль, соответствующий пользователю.
Вы никогда не будете хранить пароли, если вам это сойдет с рук
При использовании OAuth худшее, что может случиться, - это то, что третье лицо (хакер-хакер) получает доступ к этой учетной записи Twitter, но не пароль . Это защитит пользователей, которые наивно используют один и тот же пароль для нескольких онлайн-сервисов.
Использовать какую-нибудь цепочку для ключей
Наконец, я согласен с тем, что предварительно созданные решения, такие как цепочка ключей OSX, должны использоваться для хранения конфиденциальной информации OAuth, а взломанная машина будет раскрывать только информацию о разблокированных в данный момент цепочках ключей. Это означает, что в многопользовательской системе брелки становятся уязвимыми только для зарегистрированных пользователей.
Другие ограничения урона
Могут быть вещи, которые я пропустил, взять Google за «лучшие практики безопасности» и начать читать то, что может иметь отношение.
РЕДАКТИРОВАТЬ (в ответ на желаемое общее решение случая)
Вы хотите, если пользователь не вводит, доступ к онлайн-сервису. Обычно это означает, что вы, как правило, имеете контроль доступа на уровне пользователя к учетным данным для аутентификации через что-то вроде связки ключей.
Я никогда не использовал OSX Keychain, поэтому сейчас я расскажу о SELinux. В SELinux вы также можете гарантировать, что эти учетные данные будут предоставлены только вашей программе. И если мы продолжим работу на уровне ОС, вы также можете подписать все процессы от загрузки до криптографии, чтобы быть уверенным, что никакая другая программа не может имитировать вашу программу. Это все за пределами типичной пользовательской системы, и, учитывая этот уровень настройки, вы можете быть уверены, что пользователь недостаточно наивен, чтобы быть скомпрометированным, или системный администратор достаточно соблюдает требования. На этом уровне мы могли бы защитить эти полномочия.
Предположим, мы не зашли так далеко, чтобы защитить эти учетные данные, тогда мы можем предположить, что система взломана. В этот момент учетные данные аутентификации становятся скомпрометированными, обфускация / шифрование этих учетных данных на локальной стороне не добавляет никакой реальной безопасности и не сохраняет их часть или все на стороннем сервере. Это легко увидеть, потому что, если пользователь не вводит данные, ваша программа должна загрузить себя, чтобы получить эти учетные данные. Если ваша программа может сделать это без ввода данных, то любой, кто изменил его, может спроектировать ваш протокол обфускации / шифрования / сервера.
На данный момент это ограничение ущерба, не храните пароль в качестве учетных данных для аутентификации. Используйте OAuth, сеансы cookie, соленые хэши и т. Д., Все они - просто токены, представляющие, что когда-то в прошлом вы доказывали, что знаете пароль. В любой хорошей системе эти токены могут быть отозваны, время истекло и / или обменяться периодическими изданиями на новый токен во время активного сеанса.
Маркер (в какой бы форме он ни был) может также содержать дополнительную информацию для аутентификации, не связанную с вводом данных пользователем, что ограничивает вашу возможность использовать их в других местах. Например, он может инкапсулировать ваше имя хоста и / или IP-адрес. Это затрудняет использование учетных данных на разных компьютерах, поскольку для имитации этих форм учетных данных потребуется доступ к соответствующему уровню сетевой инфраструктуры.