暗号化とハッシュ化は別物『ハッシュ化は非可逆』がよくわかる例がこちら「最後に塩をまぶしますよね」

ハッシュ化と暗号化の違い。ハッシュ化とは？という話
説明 たとえ ハッシュ化 暗号化 違い
98
まとめ 「世のエンジニア卒倒レベル」宅ふぁいる便が480万件の情報漏洩、暗号化もされてませんでした→ユーザー宛のメールも無茶苦茶 190649 pv 1855 994 users 1199
Neutral8✗9eR @0x009AD6_810
（第３報）「宅ふぁいる便」サービスにおける不正アクセスによる、お客さま情報の漏洩について（お詫びとお願い）filesend.to
2019-01-28 23:00:49
リンク www.filesend.to 無料大容量ファイル転送サービス「宅ふぁいる便」 1999年から運用の無料大容量ファイル転送サービスのパイオニア。300MB迄でファイル容量無制限、256bitTLS・SSL暗号化送信対応。iPhone・iPadやAndroid等のモバイル端末間でのファイル転送も可能
Neutral8✗9eR @0x009AD6_810
ご質問一覧 filesend.to/faq.html > Q15. パスワードは暗号化されていなかったのか？ > A. 流出したログインパスワードは、暗号化されておりませんでした。 😪 pic.twitter.com/ixfU45f3Tn
2019-01-28 23:00:49
拡大
Kohei Asano @asano_ko
私はめんどくさいオジサンなので、「いいえ、パスワードは暗号化されていません。ハッシュ化されています。」と答えます。というか暗号化とは鍵があれば復号化できるという意味なので、NG認定です。 twitter.com/0x009AD6_810/s…
2019-01-28 23:17:07
伊藤 祐策(パソコンの大先生) @ito_yusaku
「パスワードは暗号化されていませんでした」 【よくある勘違い】 ・パスワードは暗号化するのではなくハッシュ化 ・暗号化とハッシュ化は全くの別物 まさかお前らは勘違いして覚えてないよな？？
2019-01-29 14:21:15
ハッシュ化と暗号化は違う
D＠4日目西り06a @DVD_YUBOKUMIN
暗号化の事を勝手に脳内でハッシュ化と読みかえてた。暗号化ってIT技術者からするとものすごくフワッとした言葉なのよね。
2019-01-30 09:20:01
朝食 @mrbreakfast0
ハッシュ化というもの自体知らなかった twitter.com/ito_yusaku/sta…
2019-01-29 21:18:01
🌧kouki🌧 @kmdkuk
複合化できるかできないかのちがいですかね、、、 雰囲気で違うのはわかるけどちゃんと理解していない。 twitter.com/ito_yusaku/sta…
2019-01-29 14:35:12
ヒルデ(ボヘミアン⚡) @nabenabetwi
暗号化は復号化出来るから、戻せないハッシュにした方がよりかたい。
2019-01-30 07:59:55
yuki476🌧 @yuki476
暗号化→金庫に入れて鍵かける ハッシュ化→シュレッダーにかけたバラバラにしたのを適当に繋いだよく分からない別書類に戻す。ただ、同じ書類なら同じ別の書類ができる。 こんな感じか？ もうちょい上手いこと言えんかな。。。
2019-01-29 20:03:03
ハッシュ化とは

ここテストに出ますよ～

おりょう @neer_chan
ハッシュ化とはこういうことです。非可逆なんです。ハッシュドポテトはポテトに戻せないのです。ほら、覚えましたね？ pic.twitter.com/twNe6S5ces
2019-01-30 08:31:24
拡大
拡大
りさぴ ⚡️(LiMa.json) @lmimsra_dev
誰がうまいこと言えと（
2019-01-30 23:24:46
高井昭平@brossom @takai_innovater
@neer_chan ハッシュ(ポテト)化
2019-01-30 12:11:16
碧扉 @Blue_753315
@neer_chan ぬか漬けのきゅうりが元のきゅうりに戻れないと同じ…
2019-01-30 21:52:07
わかりやすい
伊藤 祐策(パソコンの大先生) @ito_yusaku
あまりにも正しい例えすぎて泣いた
2019-01-30 12:52:24
よしざわ🌸webをやる人 @yoshizawa1119
これは忘れないですね(*´∀｀) twitter.com/neer_chan/stat…
2019-01-30 09:13:13
Hiro | Swift @nagami_hiro
不可逆とはこういうことですね。 twitter.com/neer_chan/stat…
2019-01-30 10:11:31
ぬーーーーー @jj43y
これ2年前に教えてもらいたかった twitter.com/neer_chan/stat…
2019-01-31 01:51:58
📦🐳 @yosemite2307
わかりやすすぎぃぃい 基本情報問題にもハッシュ化について出てたな確か。 twitter.com/neer_chan/stat…
2019-01-31 01:36:28
モモスケ @AnoTensai
ダメだ。最高。これ以上の例えを思いつかない。今度から使わせてもらおう。 twitter.com/neer_chan/stat…
2019-01-30 22:56:39
vertigo! @aki_bel
授業でこれ使わせてもらいます twitter.com/neer_chan/stat…
2019-01-30 18:48:02
残りを読む(26)
説明 たとえ ハッシュ化 暗号化 違い

あわせて読みたい

いま話題のタグ

体育57 社会4385 次亜塩素酸水19 手越祐也45 ミニマリスト31 テレワーク183 腐女子604 現場猫76 朝日新聞1300 子猫135 多様性142 リングフィットアドベンチャー35 恐怖体験15 万乗大智14 ブルーインパルス76

コメント

Daregada @daichi14657 2019年1月31日
salt どころか、pepper も振りかけたりしますからね
返信 12
緑川⋈だむ @Dam_midorikawa 2019年1月31日
つまるところ古くからあるサービスだとこういうリスクがあるということか
返信 1
しょーた @shota243 2019年1月31日
ハッシュは復号はできないけど衝突することはあるんだよな。なお、暗号を元に戻すのは復号化ではなくて復号な。平文-(暗号化)->暗号文、暗号文-(復号)->平文。
返信 3
ヒロセジロウ ✏️ @denjiro13 2019年1月31日
ハッシュ化せずに生パスワードを保管して、リクエストのたびに突き合わせてたってことなんかな…ありえるの？エンジニアリングの偉いヒト？
返信 2
きゃっつ(Kats)⊿6/10日向坂ツアー広島？ @grayengineer 2019年1月31日
「暗号化は復号化できる」というのも間違いでしょ。可逆暗号と不可逆暗号があるわけで。
返信 1
ルプスパ @lGiMFg0Sc20B1y9 2019年1月31日
「漏洩被害者の一般ユーザー」から「対策はしてなかったのか」という文意で聞かれた上での回答に対して、専門用語の揚げ足を取った上にNG認定って、めんどくさいおじさんどころの話じゃないと思います。 ユーザーと会話させちゃいけない技術者そのものじゃないですか…
返信 14
aitsuki @aitsuki2 2019年1月31日
Dam_midorikawa 最新の技術ってわけじゃないから、古い新しいは関係ないのでは…
返信 0
エリ・エリ・レマ・サンバディトゥナイ @mtoaki 2019年1月31日
grayengineer 圧縮はそうだけど、暗号は復号できないと意味ないのでは。
返信 3
ゆー @yuhya000 2019年1月31日
shota243 敢えて化を付けて言いたいなら平文化だよな
返信 1
Chief Buster @chief_buster 2019年1月31日
grayengineer 暗号化とは元に戻す事ができるアルゴリズムだけを言います。対象鍵暗号（暗号鍵と復号鍵が同じ）と非対称鍵暗号（暗号鍵と復号鍵が異なる）のお間違いでは？
返信 3
Chief Buster @chief_buster 2019年1月31日
Dam_midorikawa これは私の感覚に過ぎませんが、古い方が安全な傾向にある可能性が高いと思います。昔はこの程度の事を知っていて当然な人しかシステムを作れませんでしたし、長年運用していればこう言った致命的な誤りに気がつく可能性も高まる訳で。
返信 0
kusano @t_kusano 2019年1月31日
denjiro13 全然えらくない人ですが、例えば「パスワードを忘れた人にメールでパスワードを送るサービス（！！！）」みないなシステムだと平文で保存せざるを得ないですね。そういうシステムって昔はよく見た記憶があります。
返信 6
柴犬 @egmvd 2019年1月31日
ハッシュドポテト、朝マック食べたときくらいしか食べる機会ないから特別感あって好きなんだよね
返信 0
ブラキストン線の向こう側 @cupsoup2 2019年1月31日
あらこんな所にパスワードが🎵
返信 1
しょーた @shota243 2019年1月31日
不可逆の符号化というのはあってハッシュ化というのはその1つ。暗号というのは他人には読めないようにする符号化であって自分では読める、すなわち復号できる、可逆であるが復号のためには他人の知らない情報が必要であるというのがポイント。
返信 0
TAKAMAGAHARA @SILVER_CAP 2019年1月31日
「ハッシュ化」で重要なのは「そのハッシュドポテトを元のジャガイモに戻す事は不可能」に加えて「同じジャガイモじゃないと同じハッシュドポテトが出来上がらない/同じジャガイモなら常に同じハッシュドポテトが出来上がる」という点だろう。
返信 1
TAKAMAGAHARA @SILVER_CAP 2019年1月31日
たとえば「togetter」をSHA256でハッシュ化すると「7e495e078cd8be77bb3a9b788b6a8adb38e3d6fba4d01cb6a817b107f05477ea」になる。ユーザーがパスワードに「togetter」を入力→ブラウザ側でハッシュ化して送信→サーバー側のハッシュ化された文字列と照合→一致→ログイン許可、という流れ。サーバー側にはハッシュ化された文字列しか保存されていないので、万が一流出しても「togetter」を復元する事は不可能。
返信 2
點面悪鬼百之助 @x743 2019年1月31日
SILVER_CAP 「ブラウザ側でハッシュ化して送信」その仕組みで大丈夫なんですか？
返信 1
黒いぐら @kuroigura 2019年1月31日
鍵を持たずにオートロックの部屋からでちゃった感じ？
返信 1
すいか @pear00234 2019年1月31日
まとめの最初の方の人達、「お知らせ」の文とかQ1を読んでないのかな。面倒くさいおじさん自称するなら、突っ込むべき相手はオージス総研だと思うのだが。
返信 1
すいか @pear00234 2019年1月31日
SILVER_CAP それ、やってることは「パスワードを平文保存してる」以外のなんでもないすよ。ただ文字列がややこしくて長いってだけです。
返信 5
すいか @pear00234 2019年1月31日
denjiro13 「ありえるかありえないか」でいえば、ありえますよ。そもそもハッシュ文字列使おうがなにしようが、「サーバ側に保存されたレコード」を「ユーザーから渡された、またはその文字列をサーバ内部で加工したレコード」を比較する手続きがあるのは変わりません。
返信 1
いくら @YamadaIkra 2019年1月31日
一方向暗号化（one way encryption）とか非可逆暗号化（non reversible encryption）って言葉があるくらいには、復号できなくても暗号と呼ばれる。最近はあまり使われない言葉かもしれんが、Ciscoのマニュアルではnon-reversible encryptionを使ってるな。
返信 1
よく見かけるがどこにでもいそうでいない人 @namaehaaru 2019年1月31日
わかったようでわからないような。ただ言えるのはお腹が空くことくらい。
返信 0
TAKAMAGAHARA @SILVER_CAP 2019年1月31日
x743 すみませんどの時点でハッシュ化されるかはちょっと自分の知識でも曖昧でした。少なくともサーバー側には生のパスワードは保管されないはずです。
返信 0
TAKAMAGAHARA @SILVER_CAP 2019年1月31日
pear00234 ハッシュ化された文字列から元のパスワードを復元する事は(事実上)不可能と自分は認識していますが、違いますか？
返信 1
金目の煮付 @kinmenitsuke 2019年1月31日
「復号化」という言い方に違和感。「暗号化」の対義語は「復号」じゃなかったっけ。
返信 1
金目の煮付 @kinmenitsuke 2019年1月31日
pear00234 これが何言ってんのかわからんです。
返信 1
alan smithy @alansmithy2010 2019年1月31日
t_kusano 現在は登録したメールアドレス宛にパスワード再登録リンク送るのが主だけど、どうしてもというならブラウザから不可視な箇所に暗号鍵を置いてaes-256-cbc等で可逆暗号化したものをDBに置いておくとかかなぁ
返信 1
alan smithy @alansmithy2010 2019年1月31日
SILVER_CAP 「ブラウザ側で」が間違い(通信時の漏洩の可能性)。リクエストを受け取ったサーバのロジック層でやること
返信 6
alan smithy @alansmithy2010 2019年1月31日
"企業様向け有料版「オフィス宅ふぁいる便」は、不正アクセスの影響を受けておりません。"とあるが果たして。 | https://www.ogis-ri.co.jp/pickup/takufile/
返信 0
frisky @friskymonpetit 2019年1月31日
kinmenitsuke この方式だと、「7e49（略）77ea」がサーバ側に保管されてるわけでしょ。それが流出したら、サーバにこの文字列を直接送り付ければ認証を突破できる。　ネットワークの向こう側にいるクライアント（＝ブラウザ）の処理はいくらでも好きに改造できるから、「7e49（略）77ea」からパスワード「togetter」を復元する必要なんかなくて、そのまま「7e49（略）77ea」をサーバに送りつけるようにしてやればいいのです。
返信 2
いくら @YamadaIkra 2019年1月31日
クライアントサイドでもハッシュ化するCHAP認証のこと、忘れないであげてください。まあ単純にパスワード文字列をハッシュ関数に通しただけじゃ使われないね。普通。
返信 0
TAKAMAGAHARA @SILVER_CAP 2019年1月31日
alansmithy2010 なるほど、確かにそうでした。
返信 1
Daregada @daichi14657 2019年1月31日
今回のようなサービス系だと、暗号化されたセキュアな通信路が確立した状況なので、「通信路に平文のパスワードが...」は考えなくていいよな。サーバー側に何を保存するかの話で
返信 0
Hiro0138🤔 @Hiro0138 2019年1月31日
ハッシュ関数のコリジョンは牛肉からハッシュドポテトを作るようなもんか
返信 0
ぱんどら @kopandacco 2019年1月31日
私はゲームプログラマであってＳＥ系じゃないのでふわっとした理解だが、ハッシュ化と言うのは元データから数字なり文字列なりを作り出す処理だと認識してる。その処理は一方向で、作った物から元のデータは作りだせないし、そもそも元データに戻す必要が無い時だけ使う。
返信 0
ぱんどら @kopandacco 2019年1月31日
そんな処理がどんな時に必要かと言うと、例えば今回みたいに「送られてきたデータが前のデータと同一かどうかを判定したいがデータ自体は原形のまま保存したくない」時にはぴったり。
返信 0
ぱんどら @kopandacco 2019年1月31日
後は「２つのデータが同じかどうかの判定を、いちいち全データチェックしたくない」時にも使う。この場合はハッシュ化したデータが元データよりも短くなる変換を使う。たとえば元データが画像や動画だったりとか。ハッシュ化したデータが短い場合、2つの異なる元データからたまたま同じハッシュが作られる可能性が幾分出てくるが、たまたま複数が一致した時はそれこそ別のチェックで検算すればいい。
返信 0
ぱんどら @kopandacco 2019年1月31日
あとは「文字列を比較的小さい数値にハッシュ化する」と、文字列をいちいち比較しなくても、1つの数値の大小で比較できるのでソートとか検索とかやりやすくなる。たまたま別のデータが一致する可能性は検算で消せる。
返信 0
ぱんどら @kopandacco 2019年1月31日
だから今回、せめてハッシュ化してればという話になる。以上。なお間違ってたら専門家が突っ込むだろう。
返信 0
れいじストランド @layzy_glp 2019年2月1日
ポテトをハッシュ化したらハッシュドポテトになるけどリンゴをハッシュ化してもハッシュドポテトにならないでしょ？てこと
返信 0
かつま大佐（永遠の10歳📛） @kamiomutsu 2019年2月1日
この例だと可逆は「細かく刻む」かな？…一応元の形にくっつけることはできるし…。
返信 0
すいか @pear00234 2019年2月1日
alansmithy2010 SILVER_CAP 他の人も言ってますが、「通信経路での漏えい」は関係ありません。それを回避するのはHTTPS通信技術とかであり、「平文保存をしない」のは通信経路云々の問題とは関係ないです。平文保存をしてはいけないというのは、「そのデータが漏れた時に、被害を最小限に抑える」のが目的です。
返信 3
かつのり @k5n6 2019年2月1日
ハッシュ化すれば安全かというとデータベースだけが漏洩したときはまだ安全。でもハッシュ化するロジック部分、特にソルトなどが漏洩したら辞書攻撃などで復号しやすいので要注意です。データベースが漏洩する時点でサーバ乗っ取りの可能性を考慮する必要があり、乗っ取られていれば当然PHPなどのソースコードも丸見えです。仮にJavaでもclassファイルなんかはいくらでも逆コンパイルできます。
返信 0
Maia Killini @maiakillini 2019年2月1日
同じじゃがいもから作ったハッシュドポテトは全く同じものになるのかどうか
返信 1
frisky @friskymonpetit 2019年2月1日
maiakillini 同じじゃがいもとは（哲学）
返信 0
Hoehoe @baisetusai 2019年2月1日
ラプラスの悪魔ってやつに頼めばハッシュドポテトを芋に復元できると聞いたからお前らは全員嘘つき
返信 1
Zinc in Osaka @zincinosaka 2019年2月1日
そりゃ1GBの値から生成されたCRC16によって元の値が再現出来たら超圧縮技術の完成だからな。そもそも衝突…。
返信 0
AtsukoOrikasa @Rutice_jp 2019年2月1日
塩（salt）はユーザー毎個別の味付けをしようね。（ストレッチングとかHMACとかはいいネタ思い浮かばなかった）
返信 0
Daregada @daichi14657 2019年2月2日
zincinosaka 古のjunk.testネタで「THcomp」ってのがありまして...って、Wikipediaにも載ってるので興味のある方は是非ご覧ください(いい時代だ)
返信 0
エリ・エリ・レマ・サンバディトゥナイ @mtoaki 2019年2月2日
daichi14657 「カラーコードTM」はだいたいその原理で動いてるね。いまいち普及してないけど。
返信 0
金目の煮付 @kinmenitsuke 2019年2月2日
friskymonpetit ＞それが流出したら、サーバにこの文字列を直接送り付ければ認証を突破できる。→ん？入力されたパスワードをハッシュ化して平文保管された値と比較するんでしょ？なので衝突の問題はあるのでその意味でのセキュリティリスクはあるけど、認証プロセスを自前のAPIからしか受け付けないようにしておけば「平文で保管」自体は別に良いのでは？
返信 0
金目の煮付 @kinmenitsuke 2019年2月2日
kinmenitsuke friskymonpetit あ、すみません。元のツイートの意味を履き違えてました。ブラウザから送信させるなんて作りは考えもしなかった。
返信 0
@kankichi57301 @kankichi57301 2019年2月2日
ところでファミマのハッシュドポテトって以前はハッシュポテトやったのにいつのまにか過去分詞になってるのはなんでやねん？
返信 0
ブラキストン線の向こう側 @cupsoup2 2019年2月2日
kankichi57301 「マッシュポテト」との混同を避けたかったのでは
返信 0
KPCG10 @KPCG10 2019年2月4日
friskymonpetit ハッシュ値そのままを送信しても、サーバ側では元の「togetter」が届く想定で文字列をハッシュ関数に突っ込むので、計算値が合わずログインできません。今回の問題で一番の問題は生パスワードが漏れたことであり「メールアドレス＋パスワード」を同じ値で使いまわしている場合、流出した組み合わせで他のサイトにログインされてしまうことです。
返信 0
點面悪鬼百之助 @x743 2019年2月4日
KPCG10 発言の元となっている仕様 SILVER_CAP を読みましょう
返信 0
KPCG10 @KPCG10 2019年2月4日
x743 なるほど、元コメの「ブラウザでハッシュ化」は意味の無い行為ですね。サーバ内でソルト値と共にハッシュ関数を通すべきです。
返信 0
F414-GE-400 @F414_GE_400 2019年2月5日
ハッシュ値という言葉、随分前から言葉だけは知っていたけど意味も何の為にあるのかも知らなかった。このまとめでようやくわかった気がする。
返信 0

いまツイッターで話題の記事

ログインして広告を非表示にする
今月は84120はてブされました!あなたはもうチェックした?
nekome006
猫目@nekome006
常に猫さんが好きです。今のアイコンは猫様の肉球を触らせて頂いた時の画像です。拡大して見ていいですよ。
ログインして広告を非表示にする