「予約無断キャンセル者の電話番号を集める「予約キャンセルデータベース」が登場」記事へのコメント

いくらハッシュしても電話番号空間は狭いという話

[Anonymous Coward]

電話番号は桁数が11桁の数字に固定されているので、DBが漏れた場合はマイナンバーと同様に可能な全パターンをハッシュして持っておくことで簡単に照合可能だとか叩かれてたな。

Re:

[Anonymous Coward]

さすがに塩ぐらい振っているのではないか？

Re:

[mishima (737)]

このしくみの場合、塩があったら照合できなくね？
（照合できないというか、照合するためのコストが登録数で線形に増加するというか…）

--
# mishimaは本田透先生を熱烈に応援しています

Re:

[Anonymous Coward]

0. 登録時には、自分しか知らないソルトとアルゴリズムと回数でハッシュ化して保存
1. 入力を生で受け取って
2. 自分しか知らないソルトとアルゴリズムと回数でハッシュ化して、生の値は捨てる
3. ハッシュ同士を照合する

UNIXログインにしろなんにしろ、ハッシュパスワードの類はこのフローで照合されます。
何か問題がありますか？
検索のためのハッシュ(ややこしい)はハッシュ化後の値を使って生成すれば照合コストも問題ないのでは。

教えてエロいひと。
# エロいんだろう！？

Re:いくらハッシュしても電話番号空間は狭いという話

[ktmizugaki (46208)]

ログイン処理の場合、データベースにはユニークなログインIDの列と、ハッシュ化されたパスワードの列があります。
ログイン処理を行なうには、ユーザーから入力されたログインIDに該当する行を抽出してから、その行とのみパスワードの比較を行なえばいいので、照合コストは、抽出コスト+ハッシュ化計算1回分のコストで済みます。

対して、今回の電話番号の登録の有無を照会するシステムの場合、DBにあるのはハッシュ化された電話番号の列です。
入力された電話番号がDBに登録されているかを調べるには、登録データ数分のハッシュ化計算を行なう必要があります。
ログイン用DBであれば、パスワードとして「123456」を使用しているユーザーはだれか？を検索するような処理になります。
この処理を効率的に実行できるようにすると、DBから登録番号一覧の生成も効率的になります。
結局のところ、登録番号一覧を生成するには、可能な電話番号全てについて、順番に問い合わせる処理を行なえばいいので。（国内の電話番号であれば、最大でも 0[1-9][0-9]{8} と 0[1-9]0[0-9]{8} の18億件）

--
svn-init() {
  svnadmin create .svnrepo
  svn checkout file://$PWD/.svnrepo .
}