他にもageを使ったパスのようなパスワードマネージャーがあるよ。一つの開発者が比較表を作ってる： https://gitlab.com/retirement-home/seniorpw/-/tree/02dc02d1e.... （開示：表の中のpagoは俺のやつ。）

wg経由でリモートアクセスする理由は何かある？syncthingじゃなくて？Androidでwgを使ってどうやってアクセスしてるのかも気になるな。

keepassxc.cliも忘れないで！これを使うとプログラム的に秘密を設定したり取得したりできるよ。インターフェースはかなりユーザーフレンドリーで、ちょっと難解だけど。暗号化された秘密のバンドルを作る必要があった時に使った（長いパスワードで一時的にAPIキーをアンロックするため）。単一のファイルとそれをアンロックするための「Makefile」を生成できたし、適切な環境にキーを渡すこともできた。最初にGNUのpassを使おうとしたけど、残念ながらgnupgの管理が必要で、これはデフォルトオプションが悪いことで有名な地雷原で、シェルに統合されるべきだと仮定してユーザープロファイルディレクトリに保存するから（呼び出す場所に対して相対的なディレクトリを使わない）。これが私のファイル一つのワークフローを危険にさらしたから、普及しているにもかかわらず、諦めざるを得なかった。

デスクトップ用には「passmenu」スクリプトがあって、これをDE/WMのキーにバインドできるよ。

「ノーマルな人たち」？すべては相対的だと思う。俺は1Passwordを使ってて、あとはうまくいくことを願ってる。

ちょっと宣伝。ターミナルでKeepassアーカイブを管理するツール[1]を作ったんだけど、ここで読んでることのいくつかを解決できるかも。TUIがあって、他のコマンドにパイプすることもできるよ。[1]: https://github.com/shikaan/keydex

Keepassでは解決できない唯一のケースは、直接接続せずに2台の別々のマシンでパスワードを作成して、後でそれを統合することだね。

Keepassには、あまり話題にならないけど、複数のボールトを持てて、それらを同時に開いて検索できるという非常に評価されていない機能があるよ（少なくとも、君が言ってた2つのアプリはそれをサポートしてる）。ほとんどのパスワードマネージャーは1つのボールトに基づいていて、すべてのパスワードを最大限のセキュリティが必要だと扱わなきゃいけない問題がある。私の場合、たぶん70%のパスワードは重要じゃないサイト用で、他の誰かがその認証情報を手に入れても大した問題じゃないと思う。でも、そのサイトにログインするたびに長いマスターパスワードを入力しなきゃいけない。Keepassを使えば、その70%を別のボールトに入れて、タイプが早い短いマスターパスワードを使えるから、完全に安全かどうかわからないコンピュータでそのボールトを開くときもあまり心配しなくて済むんだ。

これを試してみようかな。今まではkeepassでローカルファイルだけ使ってたんだ。俺の場合、SynologyのNASにファイルを保存してて、2.5インチのSSDが2つ入った2ベイのやつを使ってる。メモや音楽、その他のものも入れてるし、wgもね。

KeepassXCを使いたいんだけど、妻とクレデンシャルを共有するのが簡単じゃないんだ。専用のボールトを使うこともできるけど、既存のクレデンシャルを共有するためにコピペしなきゃいけないからね。だから今のところ、Vaultwardenに落ち着いてて、意外と安定してるよ。

現在の雇用主は1passwordを使っていて、「ボールト」をグループで共有するような便利な機能がいくつかあるし、.envファイルを使って秘密を注入する「op run」コマンドや、CIでパスワードを取得するためのサービスアカウントなどもあるよ。

同意です。

Bitwardenは結構使いやすいよ。うちの組織でも使ってるし、企業利用にはまだ少し粗いところもあるけど、どんどん良くなってる。

実際の経験はまだないけど、企業内のチーム向けにパスワード共有ソリューションの市場を評価したことがある。そこの別の選択肢は https://www.passbolt.com/ で、公開鍵/秘密鍵のアプローチを使ってて、平文のパスワードはローカルマシンから出ないし、共有パスワードは各ユーザーの公開鍵で再暗号化される。

FOKSの上に何か素敵なものを作れそうだと思うよ。(https://foks.pub)

俺と友達は「pa」を会社で使ってて、めっちゃ成功してるよ: https://git.j3s.sh/pa これ、ageを使ってて、複数のキーで暗号化できるんだ。

「企業のパスワードマネージャーとして、誰がどのシークレットにアクセスしたかを知る方法はないから、常に全てのパスワードを変更しなきゃならない。」 異なるキーを使うために異なるディレクトリを設定できるし、各パスワードに対して1つのキーに制限する必要もない。複数のキーを使える。だから、こんな構造を設定できる:

• admins/.gpg-id "admin\n"
• techs/.gpg-id "admin\ntech\n" ここでadminとtechは異なるグループのための2つのキー。adminはより多くのアクセス権を持ってる。さらに良いのは:
• site_foo/.gpg-id "bob\nalice\n"
• site_bar/.gpg-id "bob\nrobert\n" ここで各従業員は自分のキーを持ってる。だから、従業員が退職したときにどのパスワードを変更する必要があるか、どのパスワードに個々の従業員がアクセスできるかを微調整できる。どのパスワードをどの従業員が知っているかを制御するためにgitサブモジュールを設定できるし、gitを使っているから、個々の従業員がいつどのパスワードにアクセスできたか、時間とともにそのアクセスが変わったかを知ることができる。

共有してくれてありがとう。私の解決策は、こんな小さなスクリプトを~/binに置くことだよ：#!/bin/sh set -eu k=$(pass ARG) oathtool -b --totp "$k"

このアプリは古いバージョンのAndroid用に作られたため、あなたのデバイスでは利用できません。 それに、あのアプリはあまりうまく動かないよ、だってちょっと使いにくいGPGアプリが関わってるから。

msfjarvisによるAndroid Password Storeアプリは昨年アーカイブされたよ。agrahnによってフォークされて大幅に更新された。GitHub ReleasesやF-DroidにはAPKがあるけど、Google Playストアにはないよ。 https://github.com/agrahn/Android-Password-Store

リカバリーコードやAPIキーのためにパスボールトも役立つよね これについてはもう知ってるかもしれないけど、Bitwardenにはこの目的で使えるCLIクライアントもあるよ、少なくともカジュアルにはね。

どのパスワードマネージャーにも当てはまることだね。データベースやストアがアンロックされていると（つまりマスターパスワードがキャッシュされているかRAMにある場合）、全てのパスワードが抽出できちゃう。必要ないときはパスワードマネージャーをロックしないとね。実際、Bitwardenではキャッシュされたパスワードが、広い攻撃面を持つブラウザにさらされてる（ランダムなリモートサーバーとのやり取りも含む）。最近、Bitwardenを含むほとんどのブラウザベースのパスワードマネージャーに脆弱性があって、リモート攻撃者がユーザーにパスワードを送信させることができるようになってた。Bitwardenは使ってるけど、主に重要じゃないパスワード用だね。

どうやってかは覚えてないけど、私の環境ではBraveブラウザとFirefox、モバイルでもpassが動いてる。これが唯一のパスワードマネージャーだよ。多分、ブラウザのプラグインだと思う。

パスワードは暗号化されたファイルパーティションのsqliteデータベースに保存してる。俺のスクリプトがパスを取得したら、すぐにパーティションを閉じるようにしてるよ。個別の暗号化ファイル（パスワードごとに1つ）にパスワードを暗号化して、パスファイルを復号化した後にgpgエージェントをクリアするようにスクリプトを組むこともできる。

うまく動かすのにちょっと時間がかかったけど、ここではYubiKeyを使ってるし、おすすめだよ。たまに探して差し込む必要があるけど、全体的にはずっと差しっぱなしでもいいかな。操作ごとにタッチが必要な設定にしてる。

YubiKeyを設定して、GPGキーの使用を認証するためにPINやタッチが必要になるようにできるよ。passに関しての私の主な問題は、YubiKeyでiOSではあまりうまく動かないことだね。

bitwardenは、ロック解除された状態でもパスワードを保護できるの？

USBポートに余裕があれば、ずっと差しっぱなしにできるNanoキーの一つを使えるよ。誰かが私のYubiKeyのPINを盗んでも、全部のパスワードを盗むためには、1000回以上タップさせる必要があるからね。

• 本質的に非構造化データだから、一般的に扱うのが難しい。ユーザー名とパスワードがあって、それをスクリプトで使う必要があるなら、必要なスクリプトごとにシェル言語で独自のパーサーを実装しなきゃいけない。 それはそうだけど、自分の慣習を使うこともできるよ。 > - pass generateで新しいパスワードを生成する際、上記の理由からか、デフォルトでパス値のすべてを置き換えちゃう。例えば、パスワードと秘密の質問の答えがあった場合、generateを使って新しいパスワードを取得すると、秘密の質問の答えが消えちゃう。site/passやsite/secret-questionに分けておけばいいよ。ディレクトリツリーを使ってるのはかなりいい感じ。 > 履歴を確認するのがすごく難しい。しばらく前に使うのをやめたけど、すべてが暗号化されてるからgit diffでは役に立たないし、そもそも生成されたパスワードに対してgit diffを実行するのは変なことだよ。重要なのは、パスワードやサイトの最後の変更がいつだったかをgit logで知っておけば、必要ならgit checkout -dで戻せること。 > 名前のせいでターミナルで検索するのがほぼ不可能。$ passは通常、関連するパッケージを示唆するからね。

「pass generate」には、ファイル内のパスワードだけを置き換える-iフラグがあるよ（最初の行だと仮定される）。

構造については、フォルダを作って3つの主要なファイルを用意することで「解決」したよ。具体的には、Websites/foo.com/username、Websites/foo.com/password、Websites/foo.com/emailって感じ。たまに「/notes」っていうファイルを追加して、構造化されてないテキストを入れたり、特別なケース用に「/json」っていうファイルを作ってJSON形式の機械可読なものを入れたりしてる。完璧ではないけど、メタデータが暗号化されてないのはちょっと嫌だけど、全体的にはこの解決策に満足してる。

履歴を確認するのは非常に難しい。しばらく前に使うのをやめたけど、すべてが暗号化されてるから git diff では役に立つ情報が得られないし、確かコマンドラインツールはパスワードのレビューや復元をするのがすごく難しかったと思う。passは .gitattributes を設定して、gpgファイルをカスタムドライバーを通じてテキストに変換するようにgitを設定する。これにより、暗号化された内容のテキスト差分がすぐにできるようになる（少なくとも、これをテストするために設定したストアではね）。 ~/.password-store # cat .gitattributes *.gpg diff=gpg ~/.password-store # cat .git/config # ... [diff "gpg"] binary = true textconv = gpg2 -d --quiet --yes --compress-algo=none --no-encrypt-to --batch --use-agent

ユーザー名には「user:」を行の先頭に置くっていう決まりがあるんだ。ファイルの最初の行にはできないけど、それ以外は順番に依存しないよ。ブラウザのプラグインやAndroidアプリもこれを実装してて、自動入力もこれに基づいてる。メインサイトでも推奨されてるしね。もし「generate」でパスワードを生成したら、それはgitに入ってるから復元可能だよ。passにとって便利なのは、最初の行だけに自動挿入するフラグかもしれないけど、それがなくてもpwgenで十分だし、passの裏側でも使われてる。

クリップボードにパスワードを挿入するための自動化を使いたいなら、ちょっとした構造が必要だよ。パスワードは最初の行に来るし、その次にユーザー名が来る。そこから先は、めちゃくちゃ自由だよ。ここには、オンボーディングのメールが丸ごと入ったpassエントリーが浮いてるんだ…

似たようなことに取り組んでるんだけど…これはシェルスクリプトじゃないんだ…

似たようなことに取り組んでるんだけど、もうちょっと大きな範囲でね（コンテナやサンドボックス内で使うことを想定してる）。 https://github.com/andrewbaxter/passworth > 暗号化されたsqlite3に保存されてるんだけど、暗号化されたsqlite3って言葉に惹かれたよ。READMEにSQLCipherを使ってるって書いてくれるといいな。

passで経験した他の重要な問題はこんな感じだね： - 重要なプロセスが文書化されてない。例えば、別のコンピュータとpassリポジトリを共有するのは明らかじゃない：.password-store/ディレクトリ以上のものをコピーする必要がある... - パッケージ化されてないとインストールが難しい。ヘッドレスNASにpassをインストールしようとしたけど、gpgが必要で、aarch64にクロスコンパイルするのは難しそうだった。 - passはgpgの軽量インターフェースだから、GPGの問題を全部抱えてる。gpg-agentでいくつかイライラしたことがある。多くの組織がGnuPGを捨てて、ageみたいなシンプルで良い暗号ツールに切り替えようとしてる。 https://github.com/FiloSottile/age - Androidでのpassは最悪だった。公式パッケージはメンテされてなかったし、フォークはF-Droidにパッケージ化されてなかった。UIも使いにくかった。明らかに良いユニバーサルソリューションがないから、今でもpassを使ってる。FiloSottile/passageはgpgをageに置き換えるだけの最小限の変更だけど、Androidはなし。もっと良い代替はgopassで、全てのUnixでポータブルで、passと互換性があって、ageプラグインもある。でも、Androidのパッケージはまだない。 https://www.gopass.pw

このスレッド全体がカニンガムの法則を体現してるのが好きだね。 https://en.wikipedia.org/wiki/Ward_Cunningham#%22Cunningham'...

これまでのところ、どうだった？俺も似たような状況で、同じ理由で同じことを考えてるんだけど、オフラインでの体験がどうなのか気になるんだ。接続が悪い時期が多いから、オフラインで認証情報を調べたり更新したりできるのはすごく便利だと思ってる。vaultwardenでどれくらいできるのか分からないし、まだ試す時間が取れてないんだ。

いや、マジで、Androidアプリが棚上げされてるとは気づかなかった。フォークを見てみたけど、あそこではいい仕事してるみたいだね。両方のメンテナが移管について話し合わなかったのはちょっと驚きだな。アクティブなフォークが引き継ぐのが一番いいのに。他に何か問題があったのかな、例えばセキュリティの方針で意見が合わなかったとか。

「しばらくの間、ブラウザに貼り付けるためにpass -cのワークアラウンドを使ってたけど、理想的じゃないね。」 実はこれ、わざとやってるんだ。プラグインを最後にチェックしたとき、Firefox起動時にgpgキーが解除されるように見えたんだよね。パスワードプロンプトの時じゃなくて。あと、プラグイン作成者が勝手に自分のパスワードを送信できるのが嫌だった。Firefoxとpassは信頼できるからそんなことはしないけど、知らない人がやるのはリスクが高すぎる。

最近、passから乗り換えたばかりだよ。君とほぼ同じくらいの期間、約400個のシークレットを保存してた。結局、複数のデバイス間で簡単に同期できるものが欲しかったんだ。最近はもっと本格的に旅行するようになって、スマホやノートパソコンに重要なパスワードを数個だけ保存しておくわけにはいかなくなった。KeePassXCで1つのファイルを同期するのがずっと楽だったし、選べるAndroidアプリも2つあった。手動で全部移すのに3時間くらいかかったけど、その機会に整理してリファクタリングしたから、CSVインポート機能は使わなかった。パスワードマネージャーは「たまに書き込んで、頻繁に読む」アプリだから、3つのデバイスを同期させるために1つのファイルをローカルネットワークで送るのは全然苦じゃないよ。

「しばらくの間、ブラウザに貼り付けるためにpass -cのワークアラウンドを使ってたけど、理想的じゃないね。」 passにはpassmenuもあるよ。それを呼び出すキーを設定すれば、メニューでパスワードを選択してクリップボードにコピーしてくれる。コマンドプロンプトを呼び出してからpass -cを手動で入力する必要がなくなるよ。

パスフレーズを共有するのは、リスクがさらに大きくなる。なぜなら、攻撃される面積が広がって、たくさんの認証情報が漏れることにつながるから。

これ、2日前にSECUSOのパスワードジェネレーターで見つけたんだ: https://secuso.aifb.kit.edu/english/105.php 最初はよくわからなかったけど、決定論的なパスワード生成アプローチを使ってることに気づいた。 余談だけど、SECUSOはすごくいいオープンソースアプリのコレクションがあるよ。

パスワードジェネレーターのアイデアには魅力を感じたよ、主にボールトの不安からね。この大事なボールトなしではリソースにアクセスできないって考えが好きじゃなかった（今でも）。家にいるときは道具があるからいいけど、そうじゃないときは、正しいハッシュ関数を教えてもらえれば、PBKDF2を使ってパスワードを生成できるんだ。でも、メタデータ（例えばパスワードルールに対処するため）を導入すると、そのアイデアの魅力がほとんど失われちゃう。そんなものを公に投稿するのは、ボールトを公開するのと同じくらい気が引けるよ。