なんでハッシュ関数はユーザーに直接活用されない？

質問

何故でしょう？

一番根本のハッシュというか種パスワードみたいのはそりゃ秘匿に充分気を使うから大変かもですが

しかしひとつだけに絞れるわけだし

電卓みたいなデバイスを考えてもいいし

せっかくインターネットという真の意味でグローバルな（アメリカ一極化という意味でなく）ネットワークがあるのに

URLのところにハッシュ値を入れれば即対応する内容が表示されればそれでいいのでは？

認証させたけりゃIDパスワードの2要素で充分だし

そのIDパス自体もハッシュで決めればいいし

上流でハッシュ変更したら自動的にIDでもパスでも順番に変更が反映されていくような
プロトコルでも開発して全Webサービスが実装すればいいし

ハッシュ関数なんてすごいものがありながら何で活用されていないのでしょうか？？

単純に不思議です

一昔前なら誰かがチラとこういうアイデア出せば飛びついて無理やりにでも実装したのに

少し時期がすぎると誰も見向きもしないし、で今熱いのはアンドロイドとかみたいですが
相変わらず情報セキュリティみたいのはダメダメだし

もうあきらめてハッシュ電卓にしたらどうですか？？？

回答No.4

beefisdead · ベストアンサー

「良さそうなアイディアのものもあれば意図不明のものもある」という感想です。

(1) 種パスワードを一つにし、手元のパスワードが単一でも複数のパスワードを利用できる
アリですね。
っていうか公開鍵暗号ってそんな感じのことやってますよね。

主要な処理はハッシュでないとは言え、公開鍵暗号は事実上一方向の関数を使って互いを認証します。
その秘密鍵を利用できる人を判別するため、秘密鍵にはパスフレーズをかけます。
全体としての仕組みはともかくとして、ユーザに見える「単一のパスワードを入れれば全部解決」という部分は、ご提案とあんまり変わらないですよね。実運用もされて現在のところ安全ですし、ビット数や関数を変えればすぐにより安全な運用に移行できます。

あとは、シングルサインオンとかOpenIDとかの認証系も、ハッシュではないとは言え目的は似ています。

(2) URLのところにハッシュ値を入れれば即対応する内容が表示される
hash値でリソースにアクセスするというと、Winnyとかtorrentみたいなのを想定してるんでしょうか。
これはかなり、いけてない、感じがしますね。理由は三つ。

　＊hash関数は一方向的＊
一方向的ということは、探索方法が必要だということになります。テーブルで管理するのでは爆発しますからDHTか何かを使うことになりますが、それってDNSと比較して何が嬉しくなるのでしょうか。DNSであれば一回で済んだアクセスが、DHTであれば複数回になるかも知れません。またコンテンツすべてがhash値を持つと言うことは、解決する側にかかる負担が大きくなると言うことです。解決にはより多くの時間がかかるようになる気がしませんか。やってみないと分からないですけどね。

　＊同一サーバ上のコンテンツが分かりにくくなる＊
同じサーバの別コンテンツは同時にアクセスされます。yahooのトップページにアクセスすると画像含め100くらいのHTTPネゴが起きるそうです。それ全部が違うハッシュを持つのでしょうか。ハッシュ解決に100msかかるとしたら、yahooのトップページを出すためだけに10秒かかってしまう計算になります。北海道から東京へのアクセスでは、実際にこういうことが起きてるんですよ。
あるいはここの質問サイト、隣同士の質問は別の内容ですが、連続してアクセスされやすいでしょう。アクセスのたびにハッシュ解決問い合わせをすることになりますよね。これも効率的じゃないです。

　＊コンテンツ流通責任範囲＊
現在のwebの形態には、「誰がコンテンツを持つか」っていう責任範囲があります。コンテンツにhash値を与えて多くの場所に分散させた場合、責任を（中略）コンテンツの削除（以下略）。

ただ、世界を変えてやるくらいの意気込みなら、アリだと思います。

> 一昔前なら誰かがチラとこういうアイデア出せば飛びついて無理やりにでも実装したのに
アイディア単体だったらそれこそ70年代にはもう征服されているでしょうね。
まともに利用する土台があってそこに実装したとなれば、今でも大いに評価されます。
OAuthなんか、仕組みはボロボロなのに今とってもアツいですからね。

こういったことを考える場合は、
・従来と比較して、何が嬉しくなるか
をきちんと明示すると、より理解を得やすいですよ。
またセキュリティや認証系を扱う上では、
・ユーザに何が見えるか
・どこを、何が流れるか
がはっきりしないと、話として成立しません。

考えていらっしゃること自体は面白いので、次はぜひ、もう少しわかりやすくお願いします。

お礼

ご回答ありがとうございました。

回答No.3

matoro6173

確かに、何かパスワードの保存とか暗号化以外にもハッシュは使えそうな気がしますね。

ただ、一か所での認証以外でハッシュを利用する際はやはり種？の扱い方が問題になります。
どちらにせよ種がばれたら危ないわけなので、一意であるipやドメインのままでも意味は変わらないと思いますが。

プロトコルの例がありますが、実装した場合のハッシュの切り替え方も問題はあるでしょう。
パケットの方に切り替え前、後の情報を持たせるのでしょうか。
持たせないとしたら、切り替え時に遭難するパケットが出てくるでしょう。
可用性がガタ落ちです。

お礼

ご回答ありがとうございました（＾＾）
プロトコルは何とかなるだろ程度で言ってみただけだったので
具体的に考えるよい機会になりました（＾＾）

補足

種バレ対策は直接には無くて、変更をしやすくして被害拡大防止が速やかに行えることと、あとは電卓set時の覗きやらは社会的マナーっぽく啓蒙？するしかないかもです。

ipやドメインも名前とその実体という構造は同じなので将来的にはあらゆる階層構造がフラットになってURLボックスに直接ハッシュ値を打ち込むとか？

プロトコルまで行きませんが自分でやってみたことから考えてみると、
ネットの窓口をブラウザのURL入力ボックスとして、
まず独自ドメインを使って自分で決めたURLを入力→そこで開くページにオンラインブックマークサイトへのリンクを書いておいたのでクリック→自分のアカウントのオンラインブックマークサイトが開くのでそこから予めブクマしておいたメールなどの各種サービスへ飛ぶ

ここで、オンラインブクマに複数のサービスサイト登録済みだが、事情あって
全てのパスワード(以下pw)を変更したいとする

サイト側で対応が必要だが、IDの他にそのサイト専用の種pwをアカウント登録時に設定必須とする

この種pwは最初の設定時に入力する以外、二度と画面に表示されることはない

オンラインブクマの機能又は、それ専用の機能を持つWebサービスでも良いが（あるとして）、

pwの変更回数を１加算する信号を各サイトに送出

受信したサイトはそのサイト専用種pwを使ってpwを更新
サイト専用種pw＋ID＋変更回数（0始まり）←これを1加算
でハッシュを取ってそれを新pwとする

加算後の変更回数をオンラインブクマ（又はpw自動変更webサービスサイト）へ通知

オンラインブクマのQRコードへ変更反映

こんな風に考えましたが、各パケットの疎通については、現状ではまずいでしょうか？

回答No.2

Werner

> SHA256は衝突未発見です。
ハッシュは原理上必ず衝突が発生します。
たとえば256ビットのハッシュ値を出力するハッシュ関数に
2の256乗パターンを超える入力を与えると
少なくとも１組のハッシュ値は同値になります。

おそらく衝突耐性を持つという話をどこかで見たのでしょうが、
衝突耐性を持つことは衝突しないという意味ではありません。

補足

wikipediaの巨大数の項目に天文学的な巨大数というのがありますがそこの説明によるとハッシュ関数MD5の２の１２８乗でも実質的に０に等しいとありましたので
少なくとも衝突が発見されるまではSHA256でいいかなと思いました。

回答No.1

Werner

> URLのところにハッシュ値を入れれば即対応する内容が表示されればそれでいいのでは？
ハッシュ値にする意味が分からない。
URLは人間に分かりやすいようにと作られたものなのに、逆行以外の何者でもない。
（コンピュータに分かりさえすれば良かったなら、今でもIPアドレスをそのまま打ち込んでいるでしょう。）
今だって、URLのところにURLを入れたら即対応する内容が表示されてるんだからそれでいいでしょう。

> そのIDパス自体もハッシュで決めればいいし
ユーザーがハッシュを通す意味がない。
（その必要があるならユーザーのあずかり知らぬバックグラウンドで自動的にやればよい。）

ハッシュ関数みたいなプリミティブな技術はエンドユーザーが直接使うようなものじゃないです。
活用なら電子署名とかの応用がたくさんある。

なんか一連の質問を見ているとハッシュについて盛大に勘違いしてるように思えます。
（ひとつだけに絞れる、あたりから少なくとも衝突するということは知らないみたいですし。）

補足

SHA256は衝突未発見です。