パスワード/秘密情報格納API調査

nmoshにcURLバインディングを追加するにあたって、パスワードを適当なところにストアするAPIについて調べた。
というのも、ユーザに入力させたパスワードを補完する上手い方法が必要とされている。デスクトップには全文検索システムが入っているのがいまや普通なので、平文でパスワードを保管するのはちょっと不味いという事情がある。
重要な要素は:

  • データをログインパスワード由来のデータで保護している

こと。この特徴を持つことで、アプリケーション自体に秘密情報を埋め込む必要が無くなる。以下のAPIはすべてこの特徴を持つ。

Windows

Windowsは大きく2通りの方法がある:    (実際にはもっとあるが、簡単なものだけ)

Credentialは、ID/パスワードの組をシステムに記憶させるためのAPIで、XP以降で使用できる。

DPAPIのCryptProtectDataは、データを暗号化するだけの単機能なAPIで、これもユーザに紐付いた秘密情報を使って暗号化を行うことができる。
一般のアプリケーションだと、CryptProtectDataはそれなりのアプリケーションで使用されているが、Credentialを直接的に使っているアプリケーションはあまり見たことが無い気がする。
...まぁWindowsのCredentialのUI自体の知名度がイマイチというのも有りそう。WindowsAPIの重要な特徴は、コマンドライン用のAPIがちゃんと存在すること。
Windowsのこの手のAPIは、他の実装とちがってアプリケーション毎の許可/不許可にGUIが無い。MacOSgnomeはアクセス許可のダイアログを出せる。

MacOS

MacOSはKeychainが有る。Keychainは近代的なデスクトップOSでは最強の統合度を誇っていて、Wi-Fiパスワードから単純なテキストまで何もかもを格納することができる。

SecKeychainAddGenericPasswordが汎用、他にドメインに紐づいたInternetPasswordもある。
Keychainはキーチェーンアクセスを通してGUI的に操作することができる。

Linux/BSD (gnome)

Linux/BSDは状況が悪い。まず、これらの環境のユーザはGUIすら使っていないケースもあるので、汎用的な手法に頼るのは難しい。なのでnmoshとしても、最後の手段として適当な暗号化で保存するパスはどうしても必要になるように思える。

FedoraUbuntuのようなGNOME系のディストリビューションでは、gnome-keyringが標準で使用できる。ポジションとしてはMacOSのkeychainに近い統合型のサービスで、seahorseがUIとして提供されている。
gnome-keyring daemonSSH Agentに加えてGPG Agentを含んでいるので、ユーザにGPG鍵を作らせ、その鍵を使うという方法も取ることができる。(もっとも、gnome-keyringはちゃんと暗号化ストレージ機能も装備している)
CUI環境では解決策は殆んど無い。例えばPAMはこのような目的に使えない(と思う)し、それなりに普及しているssh-agentもデータのsignしか行わない。まぁ伝統としてファイルのパーミッション以上の保護は行わないのが普通とも言える。
KDEにはKWalletが有るが、LXDEXFCEのような他のデスクトップ環境には該当するものが無い。いわゆる"軽量"デスクトップ環境は人気が有るが、この辺の考察は事実上存在しない。

misc

実は、直前はmozreplのようなブラウザ接続機能を使ってブラウザ経由でアクセスすることを考えていた。秘密情報の管理をブラウザに任せるのが、ユーザにとって一番わかりやすい方法に思える。Windowsでの資格情報の消しかたを知っている人よりは、自分のブラウザに保存しているパスワードの消しかたを知っている人の方が多いだろう。
本来はシステムに統合されたHTTPリクエストの仕組みをそのまま使うのが正当な手法だが、特にWindows上でのIEのシェアを見るとあまり実効性が無いように思える。ユーザにブラウザ選択の自由を与えるのは非常に重要なことだが、セキュリティアーキテクチャは分散してしまった。
この手のセキュリティシステムはどんどん後退している。ユーザデータの分析は大きなビジネスなので、PGPのようなパーソナルセキュリティは全く支持されていない。
むしろOAuthのようにアプリケーションに秘密情報を埋め込むタイプのセキュリティが普及している。この手のアプリケーションに埋め込む秘密情報はサービス提供者のためのもので、エンドユーザの役には立たない。(本来は、ユーザ毎に固有の秘密情報を配れば事足りるが、サービス提供者が規約違反のアプリをまとめてrevokeするためにはアプリケーション単位で秘密情報を発行するしかない)