私は twitter クライアントを作成しており、ユーザーのログイン情報を保護するさまざまな方法を評価しています。
重要: ユーザーのデータを他のアプリケーションから保護する必要があります。たとえば、ボットがユーザーのデスクトップで実行されているアプリケーションから Twhirl のパスワードや Hotmail/GMail/Yahoo/Paypal を盗み始めたらどうなるか想像してみてください。
明確化: 以前、「重要」な部分を省略して質問しましたが、stackoverflow の UI は、後で Q/A 会話内に詳細を追加するのに役立ちません。
何か案は ？
これはキャッチ22です。ユーザーに毎回パスワードを入力させるか、安全でない方法で保存します（難読化、暗号化など）。
これを修正する方法は、OSXのキーチェーンなどの組み込みのパスワードマネージャーを組み込むオペレーティングシステムを増やすことです。そうすれば、パスワードをキーチェーンに保存するだけで、OSがパスワードを安全に保ち、ユーザーは1つのマスターパスワードを入力するだけで済みます。OS X上の多くのアプリケーション（Skypeなど）は、キーチェーンを使用して、説明していることを正確に実行します。
ただし、おそらくWindowsを使用しているので、難読化と暗号化を行ってください。パスワードを盗むボットについては少し偏見があるかもしれません。アプリケーションに大規模なユーザーベースがない場合、誰かがそれを標的にして、具体的にパスワードを盗もうとする可能性はかなり低くなります。それに加えて、被害者のファイルシステムにもアクセスできる必要があります。その場合、おそらくウイルス/ワームがあり、より大きな問題があります。
ここで全体像を見逃していると思います：
デスクトップが侵害された場合、F#*%ED!
プログラムからパスワードを盗むには、ウイルスがシステム上で管理者として実行されている必要があります。ウイルスがそれを達成した場合、プログラムからパスワードを盗むことは、実行したい悪意のあることのリストのかなり下にあります。
プレーン テキストで保存し、ユーザーに知らせます。
そうすれば、達成したセキュリティのレベルについて誤解が生じることはありません。ユーザーが不満を言い始めた場合は、web サイトで公開されている定数を xor することを検討してください。ユーザーが不平を言い続ける場合は、コード内の定数を「隠し」、セキュリティが悪いことを伝えます。
ユーザーが悪意のある人を箱から出しておくことができない場合、事実上、彼らが持っているすべての秘密データが Dr. Evil に知られてしまいます。暗号化されているかどうかは関係ありません。そして、悪意のある人々を締め出すことができるのであれば、パスワードを平文で保存することを心配する必要はありません。
もちろん、ここで自分のお尻を話すこともできます。パスワードをプレーンテキストで保存すると、難読化して保存するよりもセキュリティが低下することを示す研究はありますか?
Twitterクライアントを作成している場合は、そのAPIを使用します
Twitterには非常に優れたドキュメントがあるので、クライアントを作成する前にすべてを読むことをお勧めします。この質問に関連する最も重要な部分は、パスワードを保存する必要がなく、代わりにOAuthトークンを保存することです。xAuthステージを使用してOAuthトークンを取得してから、必要に応じてこのOAuthトークンで他のTwitterAPIを使用する必要があります。
xAuthは、デスクトップおよびモバイルアプリケーションがユーザー名とパスワードをOAuthアクセストークンと交換する方法を提供します。アクセストークンが取得されたら、xAuth対応の開発者は、ユーザーに対応するログインとパスワードを破棄する必要があります。
あなたがそれで逃げることができるならば、あなたは決してパスワードを保存しません
OAuthを使用すると、発生する可能性のある最悪の事態は、サードパーティ（ブラックハットハッカー）がそのTwitterアカウントにアクセスできるが、パスワードにはアクセスできないことです。これにより、複数のオンラインサービスに同じパスワードを単純に使用するユーザーを保護できます。
ある種のキーホルダーを使用する
最後に、OSXのキーチェーンなどの既成のソリューションを使用して機密性の高いOAuth情報を保存する必要があることに同意します。侵害されたマシンは、現在ロック解除されているキーチェーンの情報のみを公開します。これは、マルチユーザーシステムでは、ログインしているユーザーのみがキーチェーンを脆弱にすることを意味します。
その他のダメージ制限
私が見逃したものがあるかもしれませんが、「ベストセキュリティプラクティス」のためにGoogleを利用して、関連する可能性のあるものを読み始めます。
編集（finnwの望ましい一般的なケースの解決策に応じて）
ユーザー入力がない場合は、オンラインサービスにアクセスする必要があります。これは通常、キーチェーンなどを介して、多くてもユーザーレベルで認証資格情報にアクセスできることを意味します。
OSXキーチェーンを使用したことがないので、SELinuxについて説明します。SELinuxでは、これらの認証クレデンシャルがプログラムにのみ与えられるようにすることもできます。また、OSレベルのものを継続する場合は、起動から暗号化までのすべてのプロセスに署名して、他のプログラムがプログラムを模倣していないことを確認することもできます。これはすべて、通常のユーザーシステムを超えており、このレベルのセットアップを考えると、ユーザーが危険にさらされるほど素朴ではないこと、またはシステム管理者が十分に能力があることを保証できます。このレベルでは、これらの資格情報を保護できます。
これらの資格情報の保護にそれほど踏み込んでいないと仮定すると、システムが危険にさらされていると想定できます。この時点で、認証クレデンシャルが危険にさらされ、ローカル側でこれらのクレデンシャルを難読化/暗号化しても、実際のセキュリティは追加されず、サードパーティサーバーにその一部またはすべてが保存されることもありません。ユーザー入力がない場合、プログラムはそれらの資格情報を取得するためにそれ自体をブートストラップする必要があるため、これは簡単に確認できます。プログラムが入力なしでそれを実行できる場合は、難読化/暗号化/サーバープロトコルをリバースエンジニアリングした人も同様です。
この時点では損傷の制限です。パスワードを認証資格情報として保存しないでください。OAuth、Cookieセッション、ソルトハッシュなどを使用します。これらはすべて、過去のある時点でパスワードを知っていることを証明したことを表す単なるトークンです。どのような優れたシステムでも、これらのトークンは、アクティブなセッション中に取り消されたり、期限が切れたり、定期的に新しいトークンと交換されたりする可能性があります。
トークン（どのような形式であっても）には、他の場所での使用を制限する追加の非ユーザー入力認証情報を含めることもできます。たとえば、ホスト名やIPアドレスをカプセル化できます。これらの形式のクレデンシャルを模倣するには、適切なレベルのネットワークインフラストラクチャにアクセスする必要があるため、これにより、別のマシンでクレデンシャルを使用することが困難になります。
わかりません...なぜ暗号化はダメなのでしょうか? 大きなキーを使用し、そのキーをマシン キー ストアに格納します (Windows を想定)。やった、やった。
さらに熟考すると、私は方法を見つけたと思います。アプリケーション デスクトップ アプリケーションに ASP.net 認証を使用し、それらの資格情報をオンラインで保存し、Internet Explorer のパスワード マネージャーがこのセカンダリ ペアまたは資格情報のローカル キャッシュを処理できるようにします。
最初のログイン時に、Facebook API のようなフォームを介して認証する必要があります。
OSX: キーチェーンを使用する
Windows: CryptProtectData と CryptUnprotectData を使用する
Linux: GNOME キーリングと KDE KWallet を使用する