ドコモ「パスワードはサーバーに平文で厳重に管理してるから安心しろ」 [597297612]
■ このスレッドは過去ログ倉庫に格納されています
LINEMOがパスワードを平文保持している――そんな報告がTwitterで上げられている。ITmedia NEWS編集部で確認したところ、LINEMOの他にドコモとahamo、ソフトバンク、Y!mobileの会員サービスでも、ユーザーに対してパスワードを平文で提示する機能を持っていることが分かった。事業者側によるパスワードの平文保持は、不正アクセスなどで情報漏えいが起きた際のリスクになる可能性がある。
ドコモ：
基本的には（パスワードをお忘れの方には）パスワードの再設定をお願いしている。ユーザーの利便性のために用意しているパスワードの確認機能を使った場合は、自分で設定したパスワードをdアカウント内のみで（平文として）確認できるが、パスワードはサーバの中で厳重に保管しており、SNSやメールで外部に提示することはない。
ソフトバンク：
パスワードを平文で送信しているのは事実。ユーザーへの利便性の観点から実装していた。ただ、昨今の情報セキュリティ動向を踏まえると平文による通知は見直す必要があると認識しており、見直しの検討に入っている。
https://www.itmedia.co.jp/news/spv/2203/15/news172.html これ記事にあるようにハッシュ値にしたら事業者自身もわからなくなって本人が忘れたら確認するすべがなくなるから現実的じゃないと思う 事故も発生してない相手にありもしないことで文句をつけるなんて何様なんだ
誹謗中傷で開示されちゃうかもしれないぞ >>11
ハッシュ値での保持の意味分かってる？
パスワード通知がシステム上出来なくなるよ >>16
まぁそうだけどジジババなんかは何回も再設定しまくることになる >>18
パスワード通知するサービス自体が前提からしておかしいってんだよ >>7
実際これはあると思う
アカウントの概念が分からない奴が適当に作って詰む場合があるからやばい ジャップにハッシュとか言ってもわかんねえだろ
紙と鉛筆にして、厳重に保管すりゃ良いんだよ 普通はパスワードは忘れたら再設定のみってことよ
あなたのパスワードはこれですよ〜 って平成かよ ハッシュ値は5chのIDだよ
IPアドレスからIDは計算できるけど
IDからIPアドレスは計算できない > 見直しの検討に入っている。
訳「何もしてない」 >>17
いや記事読む感じドコモもソフバンも送信時も暗号化(ssl)してると思うよ
LINEMOのSMS送信が怪しい(SMSって送信経路暗号化されてるの？)
記事が言いたいのはパスワードをそのまま持つなハッシュ値にしろってことだろうけど >>25
？
ハッシュ値で管理してたらパスワード通知は出来ないよ？ ●流出覚えてる奴いる？
あれ衝撃だったよな
でももうあれ10年前だぜ 昭和の老害
・パスワードの仕組みがわからない
・公開鍵暗号がわからない
・オープンソースがわからない マジでパスワードは使い回すな
これは最低限
相手がどう管理してるか分からないから >>34
俺のフォルダにも
みんなのフォルダにも眠ってる パスワード平文って普通ハッシュ化して保存しないのか？ よく分からんけど普通は公開鍵と秘密鍵のペアで暗号化して秘密鍵をローカルの社外秘なマシン上に置いておくんじゃないの？ とかいいつつこの記者もブラウザに保存してるんだろ？ 俺の勤務先もそうだよ
データベースに平文でぶち込んでる パスワードがデータベースに平文で保存されてるなら、
悪意ある社員やハッカーの手で漏洩する可能性があるってことだろ
クレカのセキュリティコードとかも保存禁止なのに保存してたとこあったな 知ってた
わーくにのセキュリティ意識は世界的にも底辺 俺が20年以上前に見よう見まねでCGI掲示板作った時すら
平文はダメ忘れたら再発行っていう仕様にしてたのに そもそもなんでそんな余計な機能追加してんだよ
頭沸いてんのか いや普通にパスワードは本人に再設定させろよ
どうせショップで自分のパスワードわからないようなカモを客にしているから
再設定なんてさせたらカモが何故かキレ出して逃げるような民度だろうし
その客に合わせたレベルのセキュリティなんだろうけど パスワードは忘れてもいいもの
パスワードの再設定は何度行ってもいいもの
まずこの認識を持ってない奴が多すぎる
パスワードを忘れる事をリスクだと思ってる奴は根本的にばか パスワード忘れたらリセットしろ
こっちも分からんから教えられん
と割りきれればハッシュ値で保存が一番いい
でも結構『あんたのパスワードは●●ですよ』って教えてくれるサービスまだまだ多いけどね 頭ゆとり平成かよ
こういう無能連中がいるから、自衛のために偽情報で垢作らなきゃならんのだが まともなところは本人確認出来たら再設定を可能にするんだが これだからパスワードレスを進めろと言ってるんだよ
管理も面倒なんじゃ >>53
「復号化」という言葉は無い
「暗号化」の対は「復号」 >>47
ハッシュ化するためのハッシュ関数の仕組みがよく分からんのよね
関数のアルゴリズムが何種類かあるのは知ってるけどさ
例えば任意のアルゴリズム持ったハッシュ関数で生成されたハッシュに対して、暗号化に使ったアルゴリズムもう一度適用すれば復号できちゃったりしないの？ >>51
マイナンバーカードのパスワードを忘れて3回間違えると平日就業時間内に役所に出向いてロック解除とパスワード変更手続きしないとだめなんだぜ・・・ >>60
できない
ハッシュはそういうもん
Aをハッシュ化したA'からAを復元することはできない 楽天証券も「あなたのパスワードは脆弱です」ってメールきたから多分平文で持ってる 平文で管理とか要件定義段階でセキリュティ部門から指摘くるだろ >>60
ただの割り算の余りだよ
余りから元の式はわからない 銀行のキャッシュカードなんて未だに数字4桁だし、2年ほど前にドコモ口座事件があったけど報道規制食らってたのかあっさり風化してる みんなどうせChromeとかiCloudにパスワード覚えさせてるくせに
あれだってこの記事の書き方なら平文だわ >>60
よくあるハッシュ関数の例だと割り算の余り
元の数字が100、ハッシュ化のアルゴリズムを「9で割った余り」とする
すると1がハッシュ化後の値になる
でも1という値からピンポイントで元の100は導き出せない ジャップの頭の悪さはヤベェな
バカなんだから余計なこと考えないで外国で作ってくれたフレームワークそのまま使えよ ジャップ企業は平文で通信が好きだよな
だからソシャゲはそれでよく解析されてチートされてる >>62,64,68,72
なるほどレスありがとう
余りを活用するアルゴリズムってのはどっかで一度覚えた気がするけど忘れてるから勉強し直すわ
あと暗号技術入門って数学ガールの著者の本だっけ
確かちょっと右寄りな人だった記憶がある >>78
電子メールでパスワードや二段階認証番号を送ってきたりするのはITとして2流以下の証 通信事業者なんてセキスペ持ち何人もいるだろうに誰も指摘しないのか？ >>7
バカバカしい話のように思えるが、パスワード再設定事務処理コスト>パスワード漏洩時の損害って考えてるんだろうな
でなければどのキャリアも平文保持してるわけないし
老人の介護費用のために、パスワード再設定などどうということのない世代が漏洩リスクに晒されている
シルバー民主主義社会だ ハッシュ化してさ
外部システムにハッシュ値をkeyにして平分パスワード持たせたらセキュリティ担保できん？
これならパスワード通知もできる ｄ払いと関連付けてる銀行口座は危ないか
クレジットならまだしも 平文平文というがドコモもソフバンも暗号化はやってるだろう
ハッシュ化しろ馬鹿というご意見はごもっとも
ただ、
>>1の記事にあるLINEMOはSMS(暗号化されてない)でパスワード送っちゃってるからどうなのというのはある
(けどSMSって傍受できんの？) >>83
指摘なんてしたら喧嘩売ってることになるのが日本企業
そして指摘した人間に押し付けるのも日本企業 こういう部分でGoogleやマイクロソフトやAppleを丸パクリしないジャップって何なんだろうなｗ >>85
DBが分散されているだけであんまり意味無いように感じるが >>63
IDをハッシュ化してみたらお前のパスワードから生成されたハッシュと同一だったとか、
脆弱なパスワードから生成されるハッシュのリストの中に、お前のハッシュと同一のものがあった可能性もある だって要求仕様はなにもないくせに、こちらからハッシュでやりますって提案しても
工数かかるなら却下っていうでしょ？ >>88
SMSは暗号化されてない、SMSにアクセスできるアプリなんかに盗み見られる可能性はある >>98
どうでもいいけど
ID再通知/パスワード再設定って書いてあるから平文で持ってるのはIDだけだと思うよ >>99
端末側のアプリから盗聴されるはあると思うけど、通信経路はどうなんだろと思って うぇ？暗号化してないのか
ハッカー本気出したら盗みたい放題になるじゃないか SMSはインターネットではなく電話側の仕組みなので
傍受するとしたら国家の情報機関とかだよ 平文で表示する機能がある＝平文で保存も送信もしてる
なの？ Google、アップルも平文で持っているから
問題だと思うなら辞めさせる運動をすりゃいい
ジャップ企業に預けたく無いという気持ちは分かる >>88
SMS通信傍受という意味だとまず困難
ただ受け取った後はSMS閲覧の権限もらってるスマホアプリは見れてしまうので
よくわからん危険なアプリ入れてしまうとパスワード通知とかだだ漏れになる >>106
保存や送信はたぶん暗号化してると思うよ
暗号化してない！って意味の平文じゃなくてハッシュ化してないというご指摘
ハッシュ化してたら流出してもパスワードはバレないけど、暗号化てるだけの場合復号されてしまったら平文に戻せてしまう >>110
jpg転載繰り返して劣化したら見えづらい これはあるあるなのか
うちも業界最大手だけど個人情報暗号化されてない 平文保持罪早くしろよ
これだけ多くの事件が起こってるのに未だにやってるとか罪だよ罪 >>18
あのな、それは出来ないのが普通なの
出来ることが許されたのは20年前までなの
今では許されないの。おわかり？ >>106
サーバー側でハッシュ値しか持ってないなら元の平文に復元することはできないからね >>99
>>108
ああなるほど…。例えばrakuten linkはこっちが何も許可しなくてもSMS読み取るしこの仕組み怖いな。SMS読み込みも許可制にすべきだ 実は平文保持じゃなくても
あるワードがある暗号に変換されることが確定してる仕組みだと
あまり意味がないです ハッシュが漏洩しても巨大な全ハッシュテーブルと突き合わせれば元のパスワードを復元できるな >>75
あいつは野党を腐して悦にいってるネトウヨだけど技術とは関係が無い
技術も本も社会が生み出した者だからな
全ては合成物なので独占しようとしてる奴がいたら窃盗犯とみなしてよい >>60
それが出来ないのがハッシュ関数。
何故出来ないかを簡単に言うと、ハッシュ値は元の値が持っていた情報を
部分的にしか保存せずに残りを捨てるから。 この国のIレベルで厳重に管理してるとか言われてもなあ >>7
事業者自身が分からなくなるするためにハッシュ化してるのに分かったらハッシュ化する意味無いだろ
真性のバカかこいつ >>7
アホか ハッシュ値をDBに保存してりゃ良いんだよ
忘れたら事業者が再設定用のパスワードを通知するだけ >>124
その通り
だから単純にハッシュ化するだけでは駄目で、salt を付ける必要がある >>7
現実的じゃないって今のサービスのほとんどハッシュ値のみの保持だろ
非常識だからこういうニュースにもなるんだから… >>7
頭大丈夫か
何も知らないなら無理してレスしない方がいいぞ 平文保持は禁止する法律つくるべき
得られるメリットに比べてデメリットが大きすぎる ソルト漏洩したらパスワード復元できるじゃんｗｗｗｗｗ
ダメダメｗｗｗｗ >>88
SMSなんてSIMカードぱくればいいし
標的型だったら身近にいる人からの攻撃なことが多いから一番突破されやすい 平文パスワードA→ハッシュ化→Å
Åをサーバーに保存
ÅからAへの変換は出来ません
なのでÅが漏れてもAが知られることはありません
ログイン時
平文パスワードA→ハッシュ化→Å
保存したÅと同じならAが入力されたことになりログインできる ハッシュ化すると忘れた時に再設定しか方法がなくなる
まあそれでも良いんだろうけど ハッシュ関数なんて数種類しかないんだから総当たりで元のパスワードが復元できるよｗｗｗｗｗｗ
意味なしｗｗｗｗｗｗ これ多分わかってやってるよ
ハッシュ化したらパスワードの再通知ってサービスができなくなる
じゃあ代わりにセキュリティが強固になるかといえば余所が平文で保存してるからそこから漏れたら意味がない
サービス毎にパスワード変えてるヤツの方が少数だから
そしてハッシュ化したらサービス低下して一人負けになるからどこもハッシュ化できない >>141
お前総当りでハッシュ解析できるんだ
すごいね
暗号化資産で大金持ちになれるよ >>143
SHA-1あたりで止まってる人なんじゃね >>137
君は salt の意味を理解していないな
salt は公開情報だ
機密とする文字列を Secret, ハッシュ関数を H, 文字列結合を || で表すとする。
このとき適当な文字列 Salt を生成し、次の値 Hash を計算する:
Hash := H(Salt || Secret)
これを保存する際には Salt と Hash のペアを保存する事になる。
salt の存在意義とは、同一の Secret が与えられても salt の取り方さえ毎回違っていれば
得られる Hash の値も毎回違ったものになる点にある。これはすなわち「同一の Secret が与えられた」
という情報を残さない事を意味する。これを保証するためには Salt は暗号論的に安全に生成され、
また Hash と同程度の長さを持つことが求められる。 >>125
そうなんだ
じゃあ例えば SHA-256 だと 2^256 通りの出力が有り得るわけだけど
そのテーブル作るの頑張ってね
ほれやってみろ ちなみに 2^256 は
115792089237316195423570985008687907853269984665640564039457584007913129639936 ハッシュ化したら戻せないとか戻し方がわからないとか思ってそう >>143
飛躍しすぎ
頭悪いねえ君は
>>145
はぁ？ソルトが公開情報?
アホもいい加減にしろ
>>146
アホか
パスワードの組み合わせにきまってんじゃん
まぁ俺様は支援士もネスペも持ってるけど基礎って大事だよね、痛感した >>144
SHA-1 ですら brute force は無理があるよ
MD5 くらいじゃね？それが現実的だったのは
実際ある程度の長さになったらもう brute force なんて考えるだけ無駄で
ダイジェスト関数のアルゴリズム自体への攻撃が主眼になるからなあ
SHA-512 が SHA-256 よりも有意に強いわけではないとされているのは
それが理由だし、SHA-3 が作られた理由も同じ >>150
技術についての議論をしているつもりがあるのならば、
君も技術の言葉で議論をしなければならない。
そこには人格攻撃とマウンティングの出る幕はない。恥を知りなさい。 >>130-131
>>134-135
ここまで強い意味での常識になってると思わなかった(望ましいぐらいの考えだった)から、勉強になりました >>85
ハッシュは衝突する
まぁパスワードならいって20文字とかだろうし
となるとSHA-256なら大丈夫だろうが >>134
ハッシュとソルトを格納するのがいまの標準じゃね >>160
うん、もちろんソルトは使うものとは知ってました
略しちゃってすまん 日本のITは20世紀で止まってる
まだ21世紀始まってない😂 平文なら安心だな
いざというとき印刷してすぐ使える ファイル名：pasward_for_customer.txt ただし、>>150 のこれ↓
> アホか
> パスワードの組み合わせにきまってんじゃん
これは実際に重要な点である。ハッシュ関数の構成とその使い方がどれだけセキュアであっても
その入力となるパスワードの持つエントロピーが不充分であれば、高い安全性は得られない。
ジャップランドには未だに「パスワードは10文字まで」みたいな信じられないシステムが蔓延っているが、
そんな制限を掛けることは即ち入力の取れる空間を無意味に狭め、結果として brute force の余地を産む。
十分に長いパスワード、最低でも 30 バイト程度のパスワードは受け付けなければならない。 ぷららのワード３つ組み合わせパスとかまだあるんかな 会社の業務サイトのセッションがクッキーじゃなくてlocal strageに保存されてる脆弱性を俺はずっと無視している パスワードがわからないと自民党が国民を監視できないしな😑 >>168
それは脆弱性ではないよ
どのみち local storage は同一 origin でなければ読み出せないのだから問題ない
むしろ cross site cookie の事と、対象ドメインへの通信ならば無条件に毎回送信されるクッキーの性質を考えれば
そちらの方が遥かに危なっかしい。実際 CSRF はクッキーの持つその性質が原因で起こる >>170
いやxssの脆弱性がゼロとは言いきれん 厳重に保管してあるのでヨシッ
他社も平文で保管してるようなのでヨシッ 高校の時の副担任が平文紀とかいう名前だったの思い出したわ >>33
パスワード通知はセキュリティリスクが高いからやらないのが現代の常識
まともなところなら再設定しかやってない ID:BFfrPTCF0
このおじかわいい
しっかりアプデできる良いおじ >>171
XSS の成立する状況下においては local storage の内容も cookie の内容も
どちらも同様に読み出す事ができるのだから、それでも cookie の方が安全とはならないよ 忘れたらパスワード再設定させるだけだろ
サーバー側に復元可能なパスワード置くリスク考えられないとか何十年も遅れてるわ 危なっかしすぎて平文パスワードなんて普通おきたくないだろ >>188
password1234って文字列そのままのこと
ちなみに多分平文じゃなくて暗号化されてるけど、暗号を解いて元のpassword1234を取り出せる状態
本当は一方通行の暗号化しなきゃいけない タックスヘイブンならぬパスワードヘイブンってやつか >>71
お前控えめに言ってキチガイじゃね？
iCloudキーチェーンがまるでE2Eじゃないかのように言ってるが明確にE2Eと記載されてるよ
アメリカでもそう >>88
これもそう
そもそもfsが暗号化されてないサーバーとか今時ほぼない
クラウドインスタンスとかOS含めてデータ全部暗号化されてる >>150
うへーきっつい
レインボーテーブルって単語も出せない奴がネスペ取れて支援士登録できんのかよ
支援士登録しなくてよかったわ本当
こんなんと同類になってたなんて最悪 上層部がジジイだとそういう設計求めてくることはある なんか適当なサービス作って生パスワード保存してれば、データベース見にいって悪用し放題だよな 総てのパスワードを0721で統一してる俺に隙はなかった 再設定になるのは忘れるリスクがあるから
表示のほうがいいんだけどな ショップで店員がパスワードわからないと仕事にならないもんな
ジジババにパスワード入れさせてたら閉店時間になっちゃう パスワードに記号が使えないサイトは高確率でそういうことよ >>197
忘れるたびに再発行でいいじゃん
常識的なところや教本解説本は全部そうでしょ >>107
グーグルも平文でパスワード持ってるの？
グーグルのパスワード復元機能で、パスワード正確に入力しなくても近い内容なら復元できるけど、平文で持ってるからかな？ ドコモは特に老人多いからパスワードわからん問い合わせ多いんだろ。近所のauは空いてるがdocomoはいつも満車だわ。 パスワード文字数制限あったりとわーくには何気にセキュリティ甘々だよな docomoは昔電話での本人確認でネットワーク暗証番号を口頭で言わせてた
頭沸いてるだろ そのくせ何度も認証済させるだろｗ
頭痛おかしいぐらいに まったく使ってないPlayStationからパスワード変更のお知らせとかきたんだが ハッシュ化するのではなく、公開鍵や共通鍵で暗号化して復号できるようにするのはダメなの？ >>210
ユーザー側が復号鍵を見失わない前提ならパスワードも忘れないで欲しいところ
サーバー側に復号鍵があるなら平文保存と一緒じゃね パスワードって
ハンコに例えると平文が印章でハッシュが印影でしょ
https://www.hankoya.com/untiku/images/index/img_natsuin.jpg
パスワードの平文保管って
銀行口座を作るたびに、銀行が預金者の印章を複製するくらいバカげている話
古式ゆかしいハンコ文化にも遠く及ばないリテラシーの無さなんだよな ドコモはパスワードが3種類くらいあってわけわからん >>27
ちょっとのリスクより
老人対応人件費のほうが高くつく ゆうちょもなんか忘れたときに郵送されると思ったが
勝手に再発行したパスワードかな 携帯電話事業者なんかSMS認証でええんちゃうの？
パスワードなんか必要か？ 再発行するパスワードは前回のパスワードは使えません。一度変えたら、前回のパスワードにも変更できます←面倒だけどヨシ！
ログインできなくなったら、以前のIDは二度と使えません！←めちゃウザい！ >>34
一般小説に昇華を成し遂げた作家に対する誹謗中傷ネット工作が、
それでバレた作者の作品が
再アニメ化するなー 契約回線とそれに紐づく4桁の暗証番号でとかで見られた気がする
一応物理的なsim カードとの2段階だけどDB直接狙われたら意味ないわな
せめて本当に平文じゃなくて猛烈に長いパスワードで暗号化ぐらいはしてるかと思ってた >>217
あいつらは契約者以外にも手を出しているからな
iDとかdポイントなんかはドコモの携帯持ってなくても使える 平文で保持ではなくて
ハッシュで持ってないってことでしょ
暗号化はしてるけと復号化できるとかそういうやつ >>217
だいぶ前に携帯電話複数持つのが当たり前な上に契約してない人も取り込みたいからメールアドレスベースのシステムに変えた すげえなこのスレ
ジャップがいかにIT無理だかがわかる
頭悪すぎだろ >>98
楽天証券ってなんでIDは楽天指定のだけなんや
面倒くさいわ >>7
おまえ銀行の暗証番号を行員がノートに書き連ねてたら不安にならんのか？ 運用の現場を無視して議論してないか
老人に自分一人でパスワード管理させるのは無理だぞ まさかとは思うが、
いまだに LINE 使っているヤツなんて、いないよなっ
これからは、Signal、+メッセージで携帯番号開示、
安全コミュニケーションが主流だよなっ
なっ! もうパスワードなんて無くせよ、生体認証だけやってろ >>127
じゃあハッシュ値になんの意味があるの？
ユーザーのパスワードが合ってるかどうかだけはハッシュ値で証明できるということ？ >>233
一方向暗号だから、
【同じパスワード】からは必ず【同じハッシュ値】を導出できるが、
【ハッシュ値】から【一意のパスワード】は絶対に導出できないようになってる ブラウザのパスワード管理機能は問題ないの？
あれって暗号化してクラウドに保存してるんでしょ？ 平文保存ってのも曖昧な表現だよな
可逆暗号化でも平文扱いだし >>7
最近のシステムはパスワード忘失時はメアド認証して上書きじゃね
元のパスワードを教える必要はない 某声優のファンサイトからデータ抜かれて声優板にばらまかれていたけど
IDとパスワードが分かりやすいように平文で書いてあったわｗ 平文保管ならパスワード漏れた時に過失認定されても仕方がないな >>226
そのほうがセキュリティ高いからじゃない？
idとパス使い回すバカ対策 >>92
数兆円規模で投資がいるからなw
日本人経営者は客のリスク回避のためにそんなお金出さない
この世で一番モラルがないのが
経営者にのしあがった日本人
二番目は世襲日本人政治家
若いときからそう考えてきたがこの三十年で立証された >>244
ハッシュ関数+ソルトで導出されたものとソルトを保管するだけだろ >>61
クレジットカード、キャッシュカード、マイナンバーカードの短いPINはそれだけじゃとても総当たり攻撃に耐えられないのでn回間違えたら自爆して使えなくなることで安全性を確保してる
だから仕方ない
それとこれとは似ていても全くの別問題 クレカのセキュリティってどうなんだろ
購入履歴から個人特定される可能性とかあるん？(´・ω・`) これ変更したら老人客のパスワードはドコモショップの店員が紙に書いてショップで保管することになるぞ うちは暗号化してるわ
パスワードが横に置いてあるけど >>75
勉強するならLinuxのCLI上でガンガン実習した方が早い
ソルトとストレッチングも含めて実習 >>233
正しいパスワード以外の文字列からも同一のハッシュが生成されることはあるが、狙ってそのような文字列を生成することは非現実的 なのでハッシュの一致＝パスワードの一致とみなすことができる ハッシュの安全性に全単射じゃないことが上げることがあるけど
実際の使われ方ではその性質はむしろリスクだよな
固定長にしてくれるのは便利というか場合によっては必須だけど
もし桁数を維持する一方向全単射関数があれば
パスワードハッシュとかはそれが使われるんじゃないか？(適切にパティングするとして) >>259
桁数維持って何に使うんだ？
桁数は暗号強度に直結するから短くするのは無理だぞ パス忘れるユーザーがあまりに多いからこう言う仕様になったんやろ
通常は不可逆で暗号化して保存じゃね >>259
極めて限定的な状況にのみに使える perfect hashing という手法はある
詳しくは自分でぐぐって欲しいが、それをパスワード認証に用いることは
まったく現実的でない あとハッシュ関数の安全性はそれが全単射でない事に依っているわけではなくて、
単に逆写像を具体的に構成できないばかりでなく、それを部分的にすら達成できない事に依っている。
それはどういう事かというと、ある秘密の文字列からハッシュ値を求めた時、
そのハッシュ値から以下のような情報を部分的に得る事すらできない事が、ハッシュ関数の安全性の根拠となる:
・元の文字列の長さ
・元の文字列の先頭や末尾の n 文字
・元の文字列に含まれている文字の種類の分布
・その他、元の文字列についての一切の情報 >>260
(それより短い入力を)512bitにパディングすれば
理論上は512bitハッシュとほとんど同じだと思うけど何か間違えてるか？
>>263
それは単にマッピングによる実装だからじゃないか？
英語のページしか出てこないから俺が勘違いしてるのかもしれんが
まあレスに何か例え話を添えたくて言っただけで
マッピングとは限らない全単射のハッシュライクなんて
「数学的でかつ数学的危険性の無い」みたいな注文で
今考えればナンセンスだなとは思う 平文で保持しているってのが解ってる時点でもう流出してるんとちゃうん？ >>271
流出してるわけじゃない
パスワードを平文で持ってないと提供できない機能が提供されてるってこと ハッシュ、ハッシュうるせえスレだな
ツイッター用語ののパクリか?? >>270
全単射なハッシュ関数というものは、確かに作れるし、それを使って
安全なパスワード認証スキームを構成する事は問題なく可能。
しかしながら、そのような関数を構成するには、可能な入力全体の
空間と同じだけの保存領域が最低限必要になる。
たとえば入力され得るパスワードが全部で 2^256 通りだとするなら
ハッシュ関数自体の取るスペースが 2^256 ビット以上になってしまう。
そんな宇宙的規模のハッシュ関数はもちろん何処にも保存できないし、じゃあ入力の種類を
減らそうとなったら、今度はパスワードの全探索が可能になってしまう。
だから perfect hash function はここでは使えないのだ。 ソルトとハッシュとストレッチング
一番重要なのは、ストレッチングかねえ
ストレッチング…漏洩しないに越したことは無いが、100万回とかなってたらやる気を失せさせる効果がある
ソルト…漏洩しないに越したことは無いが、漏洩してもストレッチングが100万回とかなってたら問題ない
ハッシュ…漏洩しないに越したことは無いが、漏洩してもストレッチングが100万回とかなってたら問題ない >>276
そうは思わん
ストレッチングは確かに弱いパスワードを brute force から守るという意味では効果的だが
その為に正規のユーザーの認証を通す時にまでコストを払わなきゃならないので筋が悪い
仮にハッシュ一回の計算に 1 ms 掛かるとして、ストレッチングによりそれを 1000 ms に伸ばしたとすると
brute force に要するコストは 1000 倍だ。その一方で、ストレッチングをせずにパスワードのエントロピー
を 28 ビットから 44 ビットに増やしたとすると、コストの増加は 2^(44-28) = 65536 倍でありながら
一回の計算量は同等だ。このようにエントロピーの増加は指数的に効いて来るわけだから、
できるならばストレッチングなどせずに強いパスワードを使用する方が圧倒的にコスパが良い。
ちなみにこの 28 ビットと 44 ビットという数字は、かの有名な xkcd の Correct Horse Battery Staple
が元ネタで、実情に沿った数字と言える。 >>276
ストレッチングなんて小手先でどうにかするよりも先にソルトを使うとかMD5みたいな脆弱なものは使わないとか基本的な事項が大切
むしろそれができていれば大事故はまず起きない
AdobeとかLinkedInとかの大規模流出したところってハッシュ関数使ってなかったとかソルと使ってなかったとかそもそも論だったからね >>7
こんな池沼丸出しのこと書いたあと18レスもできる神経の太さが凄い
まともなやつならID変えるだろ
まあまともな知能じゃないからこんな馬鹿なこと書くんだろうが ■ このスレッドは過去ログ倉庫に格納されています
