Open eternal-flame-AD opened 1 week ago
samunohito
commented
1 day ago 僕個人としても推進したい所ではありますが、懸念がいくつかあります。
セキュリティ方面はAdmin権限があるユーザーは信頼レベルは極めて高い
上記の通りな方もいれば、残念ながらあまり関心のない方もいらっしゃるので、とても難しい話だと思います…。 アクセストークンの発行は少しでも防御力の高い状態で使ってほしい機能だと認識しています。なので…2FA設定済みの場合のみ実行可能なようにするなどいかがでしょう？（参考までに…Gmailがサードパーティアプリ向けに発行するパスワードは2FA設定済みであることが条件のようです）
また、開発用途である場合はprocess.env.NODE_ENV !== 'production'での条件を追加するなども有りだと考えています。
eternal-flame-AD
commented
1 day ago 全体として、あなたの意見は非常に貴重で有効であり、提案に感謝し、体系的に実装されるべきであると思いますが、この問題のセキュリティ問題であるとは思わないし、この問題は新しいセキュリティの問題を開いていません。
私がセキュリティについての配慮は：
アタッカーがSigninできるまたは他の手段でユーザートークンが手に入れた場合は、アクセストークンがなくでも作成できる。２FAは前提条件が高めるでもこのフィーチャーが自身のセキュリティ問題ではないと思います。
アタッカーが普通なアクセストーケン(admin許可がない)がある場合は、作成できない。
深刻なデータリークまたはトークン構成ミスでadmin許可があるトークンがある場合は、create-accountだけ許可があるの可能性が低いと思います。他のwrite:admin:delete-account write:invite-codes "write:admin:meta" "write:admin:reset-password" (2FAも無効する) などサーバーを新しい始まりに持ち込みできる許可がありますと思います。
限られたトークンを使用できなくなら、ユーザーはこれに完全なユーザートークンを使用するために頼ることができ、実際に他の問題を紹介するかもしれませんだと思います＞
eternal-flame-AD
commented
1 day ago すべでの*::admin::*トーケンの作成は2FAが必要はとても良いと思います。後でこれを追跡するために新しい問題を開くことはいかがでしょうが
samunohito
commented
1 day ago たしかに。 トークン発行者のセキュリティ事情を考え始めると/admin/accounts/createだけのお話じゃなくなりますね。
samunohito
commented
1 day ago 仰る通り、以下は別問題として分けて考えた方が良いですね。
他のメンバーの意見も聞いてみたい所ではありますが… ひとまず、自分の意見としては1を解消してから2（このissue）に取り組んだ方が良いと考えています。
eternal-flame-AD
commented
1 day ago userpassもリークされた (パスワード再利用など) の方面で、2FAをセットアップする前に、許可検証の目的で、WebUI Signinでもユーザーを管理者と見なさないといいと思います。
Summary
write:admin:create-accountpermission がサーポートしてほしい。Purpose
正当な自動化でユーザーを作成場合は何だかあると思います？ 例えば
セキュリティ方面はAdmin権限があるユーザーは信頼レベルは極めて高いので、アカウントが自動化作成はアタックベクターであるそうとは言えないと思います。
Ref impl: https://forge.yumechi.jp/yume/yumechi-no-kuni/commit/738877016ceb50d404e66d35f149140d3909220f
Example Script: https://forge.yumechi.jp/yume/yumechi-no-kuni/commit/60eb7e1dc94d2abcf0f3767272d324b4e71e1c43
Do you want to implement this feature yourself?