Scribble at 2023-10-28 08:46:35 Last modified: unmodified

アプリケーションを設計・開発するときに多くの初心者が陥る思い込みというのは、それこそ膨大な数に登るわけだが、たとえば認証という仕組みを設計する際にも、たかだか自分がユーザとして利用してきたという事実だけに依存して、ウンザリするほど多くの思い込みがあるらしい。これが、原理原則を学問の成果として学んでいない人々の最大の欠陥であり限界でありリスクなのだが、もちろん素人や無能は無知であり無頓着であるがゆえに、自分たちの限界や欠陥を自覚しないし、知ろうともしない。

さほど数多くの経験はないが、僕もインターンや新入社員が自力でウェブ・アプリケーションを設計したり開発する場面に接して、アドバイスするという機会が何度かあった（過去にはエンジニアのインターンなども受け入れていた時期もあった）。そこで、認証という仕組みを設計するときに、専門学校や大学を出たばかりの人々は、とにかく判で押したように「ID」と「パスワード」を入力させるフォームの画面を設計したがる。しかしながら、それは認証システムを設計するときの必要条件でもなければ十分条件でもない。仮に認証が情報セキュリティの triad で言うところの機密性レベルを維持するための施策だとすれば、もし開発しようとしているアプリケーションが社内専用であり、そして誰がどう使っても構わないようなものであるなら（アクセスしたときに氏名を入力して、カレンダーに何かをみんなでそれぞれ予約するようなアプリケーションを想像するとよい）、そこで必要なのは社員のアクセスであるかどうかの判定だけであろう。よって、会社のルータへ割り当てられている固定のグローバル IP アドレスでアクセス制限を追加すれば、ログインなんてしなくても済むだろう。もしログインという操作というか、そういう手順がなくてアプリケーションを使うことに何か不安を感じるという人がいるかもしれないという想像が妥当なら、まず最初にログイン・フォームの代わりになる扉のようなページを設けてボタンをクリックさせたらいいだろう（そんな様式美みたいなものに固執するユーザが多いとは思えないが）。

あるいは、過去にも書いたことはあるが、認証において「ID」と「パスワード」の二つを要求するのは、多くのシステムにおいては、ただの習慣にすぎない。ユーザ自身がパスワードを変更できるシステムでは、別人同士で同じパスワード文字列を設定してしまう可能性があるため、ID とパスワードのペアで一意性（他に同じ ID とパスワードの組み合わせになるユーザはいない）を保つために二つの要素を組み合わせる必要があるのだが、たとえば社内システムの場合には管理側からパスワードを与えるという体裁が取れる（個々のユーザは自分でパスワードを変えられない）。このような場合には、管理側でパスワードを一元的に発行しているため、重複しないパスワード文字列を管理できる。よって、ID なんて要求しなくてもパスワードを入力させるだけで誰がログインしたのか判定できるわけである。

当社でも、情報セキュリティの小テストを運営しているウェブ・アプリケーションで、このような認証方式を採用している。自分でパスワードを変えられるようにすると、この20年近くの経験で僕自身が数多くの事例に接ししてきて知っていることなのだが、はっきり言って碌なパスワードを設定しない。たいていは、桁数を最小にするし、"gundam2010" だの "first99" だの（文字列の一部が当社の社名である）と、辞書型攻撃してくださいと言わんばかりの文字列になる。よって、パスワードなんてユーザの好き勝手に設定できないようにする方がいい。もちろん、パスワードを発行する方がバカだと、いまどき10桁の英数文字列なんていう脆弱な仕様で発行したりするから、運営する方にそれなりの見識が求められる。もちろん、こんなことは ISMS やプライバシーマークを認証・認定されている企業の（まともなレベルの）実務家なら常識だろう。