アカウント名:
パスワード:
電話番号は桁数が11桁の数字に固定されているので、DBが漏れた場合はマイナンバーと同様に可能な全パターンをハッシュして持っておくことで簡単に照合可能だとか叩かれてたな。
さすがに塩ぐらい振っているのではないか？
このしくみの場合、塩があったら照合できなくね？（照合できないというか、照合するためのコストが登録数で線形に増加するというか…）
ハッシュだけ知って全数検索できるの？どうやって？
件のサイトによると> 登録されている電話番号は暗号鍵と共に不可逆暗号化（ハッシュ化）して保存されている為、運営者サイドでも電話番号はわかりません。
この書き方だと、ソース直書きの共通塩なんじゃね？
問題は、競合店同士が他店を利するメリットが無いって事ですよね。上得意を登録しとけば、他店を利用出来ないように出来るなら、とりあえず登録しておくと良いかもしれませんね。
予約無断キャンセルをやる人間は他所でもやる可能性があるからメリット有るだろ。何でメリットが無いと思うのか、その思考回路の方が謎なんだけど。
>> 上得意を登録しとけば、他店を利用出来ないように出来るなら、とりあえず登録しておくと良いかもしれませんね。
なぜこんなろくでもことは考えに至るのにもっと普通の上記のことに思い至らないのか、あなたの思考回路が全く謎なんだけど。
基本、利害関係者同士はどちらかが得をするともう片方は損をする、と思いこんでいるせいで、あいつが得をするってことは自分にとって損なことじゃないか、みたいな反応するのには出会うことがあります。ウィンウィンで、どっちにとってもお得な場合だって世の中にはあるはずなんですけどね。
携帯大手キャリアも未納情報共有してる、銀行、信販とかもCICとかで信用情報共有してるそれ以外にも競合他社が集まって業界団体を作ることは珍しくもない
0. 登録時には、自分しか知らないソルトとアルゴリズムと回数でハッシュ化して保存1. 入力を生で受け取って2. 自分しか知らないソルトとアルゴリズムと回数でハッシュ化して、生の値は捨てる3. ハッシュ同士を照合する
UNIXログインにしろなんにしろ、ハッシュパスワードの類はこのフローで照合されます。何か問題がありますか？検索のためのハッシュ(ややこしい)はハッシュ化後の値を使って生成すれば照合コストも問題ないのでは。
教えてエロいひと。# エロいんだろう！？
ログイン処理の場合、データベースにはユニークなログインIDの列と、ハッシュ化されたパスワードの列があります。ログイン処理を行なうには、ユーザーから入力されたログインIDに該当する行を抽出してから、その行とのみパスワードの比較を行なえばいいので、照合コストは、抽出コスト+ハッシュ化計算1回分のコストで済みます。
対して、今回の電話番号の登録の有無を照会するシステムの場合、DBにあるのはハッシュ化された電話番号の列です。入力された電話番号がDBに登録されているかを調べるには、登録データ数分のハッシュ化計算を行なう必要があります。ログイン用DBであれば、パスワードとして「123456」を使用しているユーザーはだれか？を検索するような処理になります。この処理を効率的に実行できるようにすると、DBから登録番号一覧の生成も効率的になります。結局のところ、登録番号一覧を生成するには、可能な電話番号全てについて、順番に問い合わせる処理を行なえばいいので。（国内の電話番号であれば、最大でも 0[1-9][0-9]{8} と 0[1-9]0[0-9]{8} の18億件）
ソルトはユーザーごとに変えます。パスワード照合するときは、そのユーザーのソルトを持ってきてハッシュを適用します。
なんでそうするかというと、「自分しか知らない」をあてにしたくないからです。「自分しか知らない」をあてにしていいのなら、ハッシュデータベースだって自分しか知らないんだから、それがばれることは考えなくていいってことになりますよね。それはばれちゃったけど「自分しか知らないソルト」とか、「自分しか知らないアルゴリズム」はばれてないという条件でセキュリティを考えるのはちょっと変で、「仮に全部ばれたとしてもパスワード
元の空間が限られていて普通に考えてハッシュの方が広いから、どんな塩振ったところで0から10^11までの整数のハッシュと比較できるのさ。大体今時のグラボなら1枚で秒間4千万件くらい処理できるだろ?携帯の番号なら頭は020, 080, 090のどれかだし、キャリア毎の割り当てもあって更に狭いしな。一旦漏れれば数秒程度で全番号の対応表ができるはずだ。
それはストレッチングしてない前提ですね。
ストレッチング回数を増やして実用十分な強度を達成すると鯖の運営費が釣り合わなくなると思うよ
ハッシュだけならサーバーで計算しなくてもJavascriptで計算すればいい。さらにサーバー側で受け取ったハッシュに鍵付きハッシュを付けて保存しておけばリストが漏れたときの強度があがる。
どういう風に使うつもりなんか知らんがそんなにコスト食わんぞ…?
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
長期的な見通しやビジョンはあえて持たないようにしてる -- Linus Torvalds
いくらハッシュしても電話番号空間は狭いという話 (スコア:2, すばらしい洞察)
電話番号は桁数が11桁の数字に固定されているので、DBが漏れた場合はマイナンバーと同様に可能な全パターンをハッシュして持っておくことで簡単に照合可能だとか叩かれてたな。
Re:いくらハッシュしても電話番号空間は狭いという話 (スコア:0)
さすがに塩ぐらい振っているのではないか？
Re:いくらハッシュしても電話番号空間は狭いという話 (スコア:1)
このしくみの場合、塩があったら照合できなくね？
（照合できないというか、照合するためのコストが登録数で線形に増加するというか…）
# mishimaは本田透先生を熱烈に応援しています
Re: (スコア:0)
ハッシュだけ知って全数検索できるの？どうやって？
Re: (スコア:0, フレームのもと)
件のサイトによると
> 登録されている電話番号は暗号鍵と共に不可逆暗号化（ハッシュ化）して保存されている為、運営者サイドでも電話番号はわかりません。
この書き方だと、ソース直書きの共通塩なんじゃね？
問題は、競合店同士が他店を利するメリットが無いって事ですよね。
上得意を登録しとけば、他店を利用出来ないように出来るなら、とりあえず登録しておくと良いかもしれませんね。
Re:いくらハッシュしても電話番号空間は狭いという話 (スコア:1)
予約無断キャンセルをやる人間は他所でもやる可能性があるからメリット有るだろ。
何でメリットが無いと思うのか、その思考回路の方が謎なんだけど。
>> 上得意を登録しとけば、他店を利用出来ないように出来るなら、とりあえず登録しておくと良いかもしれませんね。
なぜこんなろくでもことは考えに至るのに
もっと普通の上記のことに思い至らないのか、あなたの思考回路が全く謎なんだけど。
Re: (スコア:0)
基本、利害関係者同士はどちらかが得をするともう片方は損をする、と思いこんでいるせいで、あいつが得をするってことは自分にとって損なことじゃないか、みたいな反応するのには出会うことがあります。
ウィンウィンで、どっちにとってもお得な場合だって世の中にはあるはずなんですけどね。
Re: (スコア:0)
携帯大手キャリアも未納情報共有してる、銀行、信販とかもCICとかで信用情報共有してる
それ以外にも競合他社が集まって業界団体を作ることは珍しくもない
Re: (スコア:0)
0. 登録時には、自分しか知らないソルトとアルゴリズムと回数でハッシュ化して保存
1. 入力を生で受け取って
2. 自分しか知らないソルトとアルゴリズムと回数でハッシュ化して、生の値は捨てる
3. ハッシュ同士を照合する
UNIXログインにしろなんにしろ、ハッシュパスワードの類はこのフローで照合されます。
何か問題がありますか？
検索のためのハッシュ(ややこしい)はハッシュ化後の値を使って生成すれば照合コストも問題ないのでは。
教えてエロいひと。
# エロいんだろう！？
Re:いくらハッシュしても電話番号空間は狭いという話 (スコア:2)
ログイン処理の場合、データベースにはユニークなログイン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 .
}
Re: (スコア:0)
ソルトはユーザーごとに変えます。パスワード照合するときは、そのユーザーのソルトを持ってきてハッシュを適用します。
なんでそうするかというと、「自分しか知らない」をあてにしたくないからです。「自分しか知らない」をあてにしていいのなら、ハッシュデータベースだって自分しか知らないんだから、それがばれることは考えなくていいってことになりますよね。それはばれちゃったけど「自分しか知らないソルト」とか、「自分しか知らないアルゴリズム」はばれてないという条件でセキュリティを考えるのはちょっと変で、「仮に全部ばれたとしてもパスワード
Re: (スコア:0)
元の空間が限られていて普通に考えてハッシュの方が広いから、どんな塩振ったところで0から10^11までの整数のハッシュと比較できるのさ。大体今時のグラボなら1枚で秒間4千万件くらい処理できるだろ?
携帯の番号なら頭は020, 080, 090のどれかだし、キャリア毎の割り当てもあって更に狭いしな。一旦漏れれば数秒程度で全番号の対応表ができるはずだ。
Re: (スコア:0)
それはストレッチングしてない前提ですね。
Re: (スコア:0)
ストレッチング回数を増やして実用十分な強度を達成すると鯖の運営費が釣り合わなくなると思うよ
Re: (スコア:0)
ハッシュだけならサーバーで計算しなくてもJavascriptで計算すればいい。
さらにサーバー側で受け取ったハッシュに鍵付きハッシュを付けて保存しておけば
リストが漏れたときの強度があがる。
Re: (スコア:0)
どういう風に使うつもりなんか知らんがそんなにコスト食わんぞ…?