クライアントログイン - クレデンシャルをクライアント側に安全に保存する方法

Question

多くのAPIがユーザーとパスワードの組み合わせでデータにリモートからアクセスできるように、 私は、それらを直接接続するために、（100％不可能であっても）それらを毎回尋ねることなく。

Answer 1

私は3つのアプローチのいずれかをお勧めします。

• は、認証トークンを使用してのすべてのパスワードを保存することは避けてください。このモデルでは、ユーザーは一度ログインし、サーバーは固有の大きなスパーストークンを生成し、クライアントはログインして「パスワード」として使用できます。サーバーは一度に1つのクライアントからのみこのトークンを受け入れます。したがって、2つのクライアントが同時に使用しようとすると、トークンは無効になります。また、トークンは通常、一定期間（1週間、2週間、1年、適切なもの）の後に無効にされます。トークンが無効化されると、ユーザーは手動で再度ログインし、プロセスが繰り返されます。これは、基本的にGmailやそれに類するウェブサイトのログイン方法です。

• パスワードを保存する必要がある場合は、OSに依存して管理することをお勧めします。 WindowsとMacの両方には、安全なストレージシステム（それぞれDPAPIとKeychain）があります。しかし、Linuxには常時利用可能な優れたソリューションがないため、市場によって異なります。 OSを使用する利点は、OSがあなた自身が簡単には提供できない保護機能を提供できることです。ユーザーは、再現されにくいレベルまでOSストレージ（スマートカードなどを使用）全体の保護を一元的に管理できます。 OSセキュアストアは、通常、ユーザにとっては非常に便利です。

• いずれもオプションでない場合は、アプリを起動するたびに入力する必要があるマスターパスワードで暗号化されたファイルを保存します。これはFirefoxの仕組みです（少なくとも私が最後に見たのは、しばらくありました）。これは合理的には安全ですが、ユーザーにとってはあまり便利ではありません（そして、利便性が低いことはしばしばユーザーによる採用の低さ、または単純なパスワードによる不適切な使用などを意味します）。私はこれを実装する方法の例として、Firefoxコードを調査します。

Answer 2

最善の方法は、他の人にそれらを保存し、代わりにその当事者を信頼させることです。しかし、コントロールが必要な場合は、安全なシステムで良い本を読んでから、再び考えてみることをお勧めします。考慮すべき多くの変数がありますが、リスクとコストを緩和するだけの時間がほとんどです。

Answer 3

KeePassも、開発者用に使用するためにAPIを提供します。