運営者は本当に登録情報を確認できないのか＠予約キャンセルDBの事例

既に指摘が幾つかなされていますが、自分でも謎に思ったのでメモ程度に。

予約を無断キャンセルした客の番号を共有するサイト、注目浴びる　背景には飲食店の“泣き寝入り”事情
が話題になっているので読みました。
はじめに断っておきますが、議論となっている予約無断キャンセルの是非については述べません。技術的な観点から、この話題となっているサイトを見た感想を述べます。
予約キャンセルデータベース




まず開いて見てすぐ思うのは、トップページからIDとパスワードを入力するのにhttpsではないこと。
今は無料で手軽に証明書が手に入るので、最低限のセキュリティ対策としては行って欲しいものです。
あと運用的に登録申請をメールアドレスだけって…フォームでも用意すればいいのに。。

不思議に思う箇所として

尚、登録されている電話番号は暗号鍵と共に不可逆暗号化（ハッシュ化）して保存されている為、運営者サイドでも電話番号はわかりません。電話番号を直接お問い合わせされてもわかりませんので、ご了承ください。

と記載があるところですね。

この点について技術的に書いてみようと思います。最終的にそもそも論に落ちるので大した内容ではないですが。。
私は最初「暗号鍵と共に」の箇所を読み飛ばしていたので、以下のように考えていました。

登録手順：電話番号をハッシュ化し、ハッシュ値と登録履歴情報をDBへ
検索手順：入力された電話番号をハッシュ値に変換し、DBから登録されているか検索

このような仕様であれば、

1. 電話番号の値の取りうる範囲は決まっている
2. 電話番号全てに対しハッシュ計算を行うことで、全ての電話番号に対応するハッシュ値が手に入る
3. 運営者はDBから登録されたハッシュ値を入手できる
4. 運営者は②と③を比較することで登録された電話番号を入手できる

ということで、運営者は電話番号を入手できると考えられる。

また③においてDBの流出などで、運営者に限らず外部の人間もハッシュ値を入手できる可能性があるため、一般的にこのようなサービスでは"塩をまぶす"(salt)ことが多いです。
これには2パターンあり、登録手順において以下の方法であると考えられます。

・電話番号に固定の値を足し、ハッシュ化する
　　　→プログラム上に固定値がある
・電話番号ごとにランダムな値を足し、ハッシュ化する
　　　→検索時にランダム値が必要なので電話番号ごとに紐付けて保存しなければならない
いずれにせよ運営者は②に一手間加えるだけで、最終的には電話番号を入手できます。
塩をまぶす意味は、外部の人間がこの加えた値(salt)を把握できないというところです。

私が改めて読んだとき、「暗号鍵と共に」という記載があり少し混乱しました。
この記述はsaltのことを指していると思われますが、真面目に「暗号鍵」を解釈すると共通鍵や公開鍵暗号などの方式を使っているようにも受け取れます。しかしながらこのような暗号化方式でどのようにしてDBへの登録・検索を実現し、かつ運営者ですら内容が把握できないシステムとなるのか……

結果、そもそも論です。
・システム側で同一の電話番号を登録・検索できている。
・電話番号の取りうる値全てを検索窓に投げるだけで、DBを直接参照せずとも把握できる。

前者だけであれば、会員サイトのパスワードは読み取れないのかという話になりますが、ハッシュ化とは入力値から出力値は計算できても、出力値から入力値は計算できないという一方通行であるため、英数字や記号そして多様な桁数となると値の取りうる範囲は膨大になります。
他方で、パスワードにありふれた単語を入力すると、予め単語をハッシュ化したリストを利用した辞書攻撃という手法が用いられます。そのため、パスワードは推測されにくい値を用いることが重要なのです。
ここで述べた②の手法はまさしく辞書攻撃です。（正確には他者へ攻撃をしているわけではないので定義とズレますが）
後者のように今回電話番号という値の取りうる範囲が決まっており、かつ狭い場合はこのようにハッシュ化が一方通行で不可逆性があると言えども、力技で元に戻せてしまうのです。


このような記載の真意は、このサイトの趣旨が（今回のような）議論を生むために電話番号を問い合わせられる可能性が高いため、予め技術的にできないという理由を付けてお断りをしていると考えられます。

今回は私が適当に感想を述べただけですので、該当サイトに対して「技術的にできないというのは嘘だ」と電話番号を問い合わせたりすることはオススメしません。
また、技術的な内容に正確でない点があったりするかもしれませんが、ご了承ください。