ソフトウェア開発者の日常

こだわりなく書きたいことを書いていきます。

パスワードを認証の要素として使えない理由が理解できない

スポンサーリンク

依頼元から、会員番号ある項目を入力して、認証するシステムの作成依頼がありました。
会員番号ある項目を、他社のWebAPIに渡すと、年会費が支払われている会員であれば、OKが戻ります。
年会費が支払われていなかったり、会員番号ある項目の組み合わせが正しくなければ、NGが戻ります。

会員番号ある項目は、本人だけが知っている項目だと思っていたら、以前は公開された情報だったというのがわかりしました。
これでは、公開された情報のときに、他人の分を控えておいた悪意ある人物が、他人の情報を使って認証できてしまいます。

オーソドックスな対策は、パスワードを使う方法なのに…

対策として、会員番号ある項目の他に、パスワードを、他社のWebAPIに渡して、認証する方式への変更を要望しました。

依頼元からは、

  1. 会員番号ある項目に、パスワードを追加するが、パスワードは他社のWebAPIには渡さないで、依頼したシステムでのみ管理する。
  2. システムに初期パスワードは登録しない。
  3. パスワードは初回および忘れたときに新たに登録できる。

という仕様が提示されました。

依頼元はこれで解決できると自信があったようですが、会員番号ある項目が分かっていれば、初回のパスワード登録を、他人ができてしまいます。
パスワードを忘れたときに新たに登録できる仕様なので、初回のパスワード登録は本人が行っても、悪意ある人物が後から他人の情報を使って、パスワードを更新できてしまいます。

全く対策になっていないという点を指摘しました。
合わせて、なぜ他社のWebAPIにパスワードも渡して、認証する方式へ変更できないのか質問しました。

カギ
unsplash-logoCMDR Shane

会員がパスワードを忘れているから、パスワードを使いたくない!?

依頼元からは、お客さんにWebAPIにパスワードも渡して、認証する方式へ変更を要望しているが、パスワードを忘れている会員が多いのでパスワードを使いたくない旨の連絡がありました。

会員が利用するシステムは他にもあって、そちらは会員番号パスワードで認証されています。
このシステムが使われていないのであれば、パスワードを忘れている会員が多いという状況は理解できます。
だからといって今の仕様のままでいいわけではありません。

会員が利用する他のシステムには、パスワードを忘れた際の再設定機能もあります。
パスワードを忘れている会員が多いのであれば、この機能で再設定してもらえば済む話です。


お客さんがパスワードを使うように方針を変えない場合、システムの作成を引き受けないという対処しかないと考えています。