認証処理の心得【初心者向け】

前置き

認証処理、所謂ログイン機能を作らなきゃ、でも初めてでよく分からないって人向けに、
ログイン機能を作るうえでの、「基本だろ！」ってレベルの事も含めて説明する。
単純な機能ながらセキュリティ的にも気をつけなきゃいけないことも多い。だけど、気をけなきゃいけないことは決まってて、その対処もお作法が確立している。だからポイントを押さえてしまえば大丈夫。

今から説明する認証方式は、一般的に広く使われる、「ログインID」と「パスワード」を使用した方式について説明する。

精査仕様

1. 単項目精査
   単項目精査というのは、「半角英数字のみ」だとか「異なる文字種を3種類以上」だとかその項目に対する条件を精査すること。
   入力フォームなのでそういった精査をやりたくなりがちだが、ログイン時は不適である。
   悪意のあるユーザにログインエラーメッセージから、ログインIDやパスワードの設定ポリシーの情報が推測されてしまうからである。
   基本的に成功か失敗かが分かればよく、エラーメッセージは「ログインIDまたはパスワードが間違っています」と出せば良い。
2. DB精査
   多くの場合、ユーザ情報はDB(データベース)に格納されているという前提で話す。
   ログインIDとパスワードを条件に検索をかけて、一致するレコードが存在するかで、精査を行う。
   1. パスワード暗号化
      パスワードは暗号化を行って保存し、DB検索時も暗号化をかけてから検索する。
      これもセキュリティ上の理由で、DBデータが漏洩した場合も元パスワードだけは分からないようにする保険的対策である。
      また、暗号化の方式には大きく、可逆暗号化と不可逆暗号化(ハッシュ化)の2つがある。
      • ・可逆暗号化：暗号化したあと復号が可能。DBデータが漏洩した場合、最悪解読される可能性がある。
      • ・不可逆暗号化(ハッシュ化)：復号が不可能(現実的には非常に困難)。パスワードは仕様的に平文を使用することも少ないはずなのでこちらの方式とするのが基本である。「パスワードリセットした時にメールでパスワードが送られて来た！」となると、ハッシュ化されてない事が分かり、叩かれる。
   2. SQLインジェクション対策
      上述の通り、DB検索をかけるので、SQLインジェクション対策は必ず行うこと。(認証処理に限ったことではないが)
      「ログインID」「パスワード(暗号化)」はサニタイジングして、決してログインID・パスワードがわからなくても検索結果が取得出来てしまうようなことが無いように。これらはパラメータ化してSQLに埋め込むようにしよう。

セッション

• セッションフィクセーション対策
  セッションフィクセーション(セッション固定化)攻撃対策のためのお作法。
  ログインID/パスワードが合っていて、ログインが通ったら、それまでのセッション情報を無効化し、新規にセッションを発行する。再発行を行わないと、悪意のあるユーザが正規のユーザにセッション(未ログイン)を送りつけてログインをさせて、セッションハイジャックする（要するにアカウントの乗っ取り）ことが出来てしまう。
  認証完了後はセッション再発行と覚えておけば良い。
• セッション情報追加
  また、このタイミングでセッション情報追加を行う。Webアプリケーションの仕様にもちろん依るが、セッション間で持ち回るユーザ情報(例えばユーザIDなど)をセッションに保存しておく事が多い。

おわり

簡単にだけど説明は以上。
あまりまとまっている説明を見つけられなかったから思いついたレベルでまとめてみた。