認証の実装ルールの整備 @02455

1：ikemo 2020/10/22 22:34 ID:c64

開発者としても困ることがあるが、
主にユーザーとして困ることに、パスワードのルールがある。

シングルサインオンがあるサービスも増えているが、実装が容易なのと、
ユーザからもあえて連携させたくないためにパスワード認証を使うケースも多々あり、
今後も(しばらくは?)使われていくのは間違いない。

自分は数百のWebサービスに登録しているが、もちろんパスワードの使い回しなどするはずがなく、
かと言って1つ1つ覚えられるはずがないので、
英数字20〜30桁程度のパスワードを、パスワードマネージャを使用して自動生成している。

しかしこのパスワードマネージャに対応していないサイトがあり、困っている。
以下がその一例。

・パスワードの長さに制限がある(そもそも制限をつけるべきではない)
・「パスワードの確認」フィールドがペースト不可(何を考えているのか)
・記号が必須だが記号の文字種に制限がある(記号必須もやめて欲しい)

ユーザとしても苦痛だが、このような仕様を実装するのは開発者にとっても苦痛であり、
むしろセキュリティ的にはマイナスになっている。

あと、パスワードのルールは年々変わっていくにもかかわらず、記述が古いものが見られる。
例えば「パスワード IPA」で検索したこのサイト、例えばIPAで公開されているこのページも、明らかに現状では間違っているルール。
www.ipa.go.jp/chocotto/pw.html

これではユーザとしても開発者としても困るため、以下のようにして欲しい。

1. 認証に関する情報の一元化
先ほどのIPAのサイトのように、明らかに間違っているルールは有害無益であり、削除して欲しい。
パスワードを含め、認証方式はこれからも変わる可能性があるため、継続的にメンテナンスされる1つのサイトでまとめて欲しい。
もちろんパスワード認証に限らず、二要素認証、生体認証、OpenID Connectなどのシングルサインオンの情報も加えて欲しい。

2. パスワードマネージャとの親和性の高いパスワード認証実装方式のガイドライン
OSやブラウザにパスワードマネージャが組み込まれている現状を踏まえ、
パスワードマネージャの動作を妨げない、パスワード認証の実装方式をガイドラインとして作成して欲しい。
正直なところ、強制力があっても構わない。

2：j 2020/10/22 22:53 ID:8c8

脆弱性がないようにやればいいだけの話じゃん

国家がそんな箸の上げ下げみたいな幼稚なことまで面倒みなきゃ
今どきのプロは何にもできないのかね
つまらんね

3：j 2020/10/22 23:58 ID:8c8

国の税金を使ってそんなことやったって世界に知られたら
恥ずかしいなー

4：0014akira 2020/10/23 00:16 ID:b05

中立

パスワードを受け入れる側のシステムは何でも受け入れる設定にしておいて、ユーザーが好きなパスワードを設定するのが一番幸せ。
仮に一文字パスワードでもシステム側は悪くない、設定したユーザーが悪い。

5：m.hidehiro 2020/10/23 11:58 ID:c67

賛成

趣旨は賛成です。
例えば、アメリカの
NIST 800-63-3　Digital Identity Guidelines
pages.nist.gov/800-63-3/
openid-foundation-japan.github.io/..l/sp800-63-3.ja.html
みたいな奴ですよね。まさにデジタル庁がやる仕事だと思います。

一方で一つご教示いただきたいのですが

＞ IPAで公開されているこのページも、明らかに現状では間違っているルール。
＞ www.ipa.go.jp/chocotto/pw.html

これが間違っていると言うご見解ですが、もう少し詳細をご教示いただけないでしょうか。
確かに、サイトから連想できる言葉は使わないように、ぐらいは追加した方がいいと思いますが、私には、一般向けに比較的強度のあるパスワードを、忘れずに作るキャンペーンとしてはそれなりによくできていると思っています。

6：ikemo 2020/10/23 13:52 ID:c64

賛成

>>5

> NIST 800-63-3

まさにそれです。

> これが間違っていると言うご見解ですが、もう少し詳細をご教示いただけないでしょうか。

引っかかったのは安全なパスワードにある『パスワードの中に数字や「@」、「%」、「"」などの記号も混ぜている。』の記号のところです。少なくとも必要条件ではありません。

NISTが出しているガイドラインですが、パスワードは長さより複雑さが重要だと言っています。
www.itmedia.co.jp/..2003/02/news061.html

実際、英数字15桁の方が、英数字+記号12桁より組み合わせが多いです。ユーザが覚えやすいなら記号を使っても構いませんが、システム側がそれを強制するのはおかしいです。そういうシステムに限ってパスワードの最大長が短いんですよね。

あと同じくNISTですが、パスワードの定期変更も不要(漏洩した確証がある場合のみ)、ペーストできるようにというガイドラインがあります。
japan.zdnet.com/article/

7：u 2020/10/23 15:02 ID:b8e

反対

目的や趣旨は理解できますが、ユーザ認証の実装方法の教科書を政府が発行してください、と言っているようにしか思えない。
他の方も書いていますが、プロなら自分で調べて知っているべき情報ではないかと思います。

8：m.hidehiro 2020/10/23 20:23 ID:c67

賛成

>>6

ご回答ありがとうございます。
なるほど、そこですね。
でもそのページは利用者向けの広報なので、例えばシステムが短いパスワードを強制している場合等でもこうやればいいというのを教えているような気がします。

>>7
仰る通りだと思います。
思いますが、現実問題、プロと言っても玉石混淆なので、理想はそれとしても、こういうものを整備しないと環境の底上げは難しいのではないかと思っています。

たぶんそう言う人に、英語で行われている議論をきちんとおって、論文読めと言っても絶対読まないですし……。

9：ikemo 2020/10/23 21:02 ID:c64

賛成

>>8

そうですね。
開発者としてはこれくらい当たり前の知識なんですが、
セキュリティは利便性と対立することが多く、
仕様がエンジニアだけで決められないので、
説明に苦労することが多いです。
(苦労するだけならまだマシ)

現状の仕様に問題があっても(平文で保存してるとか！)、
無視されるケースがほとんどです。

9.1：wqmskvplcv 2020/12/18 12:35 ID:???

??????????? | ???????? | ??????
<a href="www.g84i4eaz4h95ms6b314c61zqr07xl51ls.org/..wqmskvplcv</a>
[url=www.g84i4eaz4h95ms6b314c61zqr07xl51ls.org/]uwqmskvplcv[/url]
wqmskvplcv www.g84i4eaz4h95ms6b314c61zqr07xl51ls.org/