2019年1月31日

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

ハッシュ化と暗号化の違い。ハッシュ化とは？という話

説明違いたとえハッシュ化暗号化

nekome006
44666
61
118
13
33

101

まとめ

「世のエンジニア卒倒レベル」宅ふぁいる便が480万件の情報漏洩、暗号化もされてませんでした→ユーザー宛のメールも無茶苦茶 193748 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 @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

高井昭平@SHOKUTSU @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 | スポーツ x アプリ開発 @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

モモスケ ( momosuke ) @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)

いま話題のタグ

絵師373 アニメ41399 性嫌悪17 LGBT922 ヨドバシカメラ83 バイトテロ16 ヒグマ56 彼氏160 恋するワンピース15 腐女子620 インターネット10782 リングフィットアドベンチャー59 プログラマー96 松岡修造141 京大175

Daregada @daichi14657 2019年1月31日

salt どころか、pepper も振りかけたりしますからね

緑川⋈だむ @Dam_midorikawa 2019年1月31日

つまるところ古くからあるサービスだとこういうリスクがあるということか

しょーた @shota243 2019年1月31日

ハッシュは復号はできないけど衝突することはあるんだよな。なお、暗号を元に戻すのは復号化ではなくて復号な。平文-(暗号化)->暗号文、暗号文-(復号)->平文。

ヒロセジロウ ✏️ @denjiro13 2019年1月31日

ハッシュ化せずに生パスワードを保管して、リクエストのたびに突き合わせてたってことなんかな…ありえるの？エンジニアリングの偉いヒト？

きゃっつ(Kats)⊿ @grayengineer 2019年1月31日

「暗号化は復号化できる」というのも間違いでしょ。可逆暗号と不可逆暗号があるわけで。

ルプスパ @lGiMFg0Sc20B1y9 2019年1月31日

「漏洩被害者の一般ユーザー」から「対策はしてなかったのか」という文意で聞かれた上での回答に対して、専門用語の揚げ足を取った上にNG認定って、めんどくさいおじさんどころの話じゃないと思います。ユーザーと会話させちゃいけない技術者そのものじゃないですか…

aitsuki @aitsuki2 2019年1月31日

Dam_midorikawa 最新の技術ってわけじゃないから、古い新しいは関係ないのでは…

エリ・エリ・レマ・サンバディトゥナイ @mtoaki 2019年1月31日

grayengineer 圧縮はそうだけど、暗号は復号できないと意味ないのでは。

ゆー @y_raimu0 2019年1月31日

shota243 敢えて化を付けて言いたいなら平文化だよな

Chief Buster @chief_buster 2019年1月31日

grayengineer 暗号化とは元に戻す事ができるアルゴリズムだけを言います。対象鍵暗号（暗号鍵と復号鍵が同じ）と非対称鍵暗号（暗号鍵と復号鍵が異なる）のお間違いでは？

Chief Buster @chief_buster 2019年1月31日

Dam_midorikawa これは私の感覚に過ぎませんが、古い方が安全な傾向にある可能性が高いと思います。昔はこの程度の事を知っていて当然な人しかシステムを作れませんでしたし、長年運用していればこう言った致命的な誤りに気がつく可能性も高まる訳で。

kusano @t_kusano 2019年1月31日

denjiro13 全然えらくない人ですが、例えば「パスワードを忘れた人にメールでパスワードを送るサービス（！！！）」みないなシステムだと平文で保存せざるを得ないですね。そういうシステムって昔はよく見た記憶があります。

柴犬 @egmvd 2019年1月31日

ハッシュドポテト、朝マック食べたときくらいしか食べる機会ないから特別感あって好きなんだよね

ブラキストン線の向こう側 @cupsoup2 2019年1月31日

あらこんな所にパスワードが🎵

しょーた @shota243 2019年1月31日

不可逆の符号化というのはあってハッシュ化というのはその1つ。暗号というのは他人には読めないようにする符号化であって自分では読める、すなわち復号できる、可逆であるが復号のためには他人の知らない情報が必要であるというのがポイント。

TAKAMAGAHARA @SILVER_CAP 2019年1月31日

「ハッシュ化」で重要なのは「そのハッシュドポテトを元のジャガイモに戻す事は不可能」に加えて「同じジャガイモじゃないと同じハッシュドポテトが出来上がらない/同じジャガイモなら常に同じハッシュドポテトが出来上がる」という点だろう。

TAKAMAGAHARA @SILVER_CAP 2019年1月31日

たとえば「togetter」をSHA256でハッシュ化すると「7e495e078cd8be77bb3a9b788b6a8adb38e3d6fba4d01cb6a817b107f05477ea」になる。ユーザーがパスワードに「togetter」を入力→ブラウザ側でハッシュ化して送信→サーバー側のハッシュ化された文字列と照合→一致→ログイン許可、という流れ。サーバー側にはハッシュ化された文字列しか保存されていないので、万が一流出しても「togetter」を復元する事は不可能。

點面悪鬼百之助 @x743 2019年1月31日

SILVER_CAP 「ブラウザ側でハッシュ化して送信」その仕組みで大丈夫なんですか？

黒いぐら @kuroigura 2019年1月31日

鍵を持たずにオートロックの部屋からでちゃった感じ？

すいか @pear00234 2019年1月31日

まとめの最初の方の人達、「お知らせ」の文とかQ1を読んでないのかな。面倒くさいおじさん自称するなら、突っ込むべき相手はオージス総研だと思うのだが。

すいか @pear00234 2019年1月31日

SILVER_CAP それ、やってることは「パスワードを平文保存してる」以外のなんでもないすよ。ただ文字列がややこしくて長いってだけです。

すいか @pear00234 2019年1月31日

denjiro13 「ありえるかありえないか」でいえば、ありえますよ。そもそもハッシュ文字列使おうがなにしようが、「サーバ側に保存されたレコード」を「ユーザーから渡された、またはその文字列をサーバ内部で加工したレコード」を比較する手続きがあるのは変わりません。

いくら @YamadaIkra 2019年1月31日

一方向暗号化（one way encryption）とか非可逆暗号化（non reversible encryption）って言葉があるくらいには、復号できなくても暗号と呼ばれる。最近はあまり使われない言葉かもしれんが、Ciscoのマニュアルではnon-reversible encryptionを使ってるな。

よく見かけるがどこにでもいそうでいない人 @namaehaaru 2019年1月31日

わかったようでわからないような。ただ言えるのはお腹が空くことくらい。

TAKAMAGAHARA @SILVER_CAP 2019年1月31日

x743 すみませんどの時点でハッシュ化されるかはちょっと自分の知識でも曖昧でした。少なくともサーバー側には生のパスワードは保管されないはずです。

TAKAMAGAHARA @SILVER_CAP 2019年1月31日

pear00234 ハッシュ化された文字列から元のパスワードを復元する事は(事実上)不可能と自分は認識していますが、違いますか？

金目の煮付 @kinmenitsuke 2019年1月31日

「復号化」という言い方に違和感。「暗号化」の対義語は「復号」じゃなかったっけ。

金目の煮付 @kinmenitsuke 2019年1月31日

pear00234 これが何言ってんのかわからんです。

alan smithy @alansmithy2010 2019年1月31日

t_kusano 現在は登録したメールアドレス宛にパスワード再登録リンク送るのが主だけど、どうしてもというならブラウザから不可視な箇所に暗号鍵を置いてaes-256-cbc等で可逆暗号化したものをDBに置いておくとかかなぁ

alan smithy @alansmithy2010 2019年1月31日

SILVER_CAP 「ブラウザ側で」が間違い(通信時の漏洩の可能性)。リクエストを受け取ったサーバのロジック層でやること

alan smithy @alansmithy2010 2019年1月31日

"企業様向け有料版「オフィス宅ふぁいる便」は、不正アクセスの影響を受けておりません。"とあるが果たして。 | https://www.ogis-ri.co.jp/pickup/takufile/

frisky @friskymonpetit 2019年1月31日

kinmenitsuke この方式だと、「7e49（略）77ea」がサーバ側に保管されてるわけでしょ。それが流出したら、サーバにこの文字列を直接送り付ければ認証を突破できる。　ネットワークの向こう側にいるクライアント（＝ブラウザ）の処理はいくらでも好きに改造できるから、「7e49（略）77ea」からパスワード「togetter」を復元する必要なんかなくて、そのまま「7e49（略）77ea」をサーバに送りつけるようにしてやればいいのです。

いくら @YamadaIkra 2019年1月31日

クライアントサイドでもハッシュ化するCHAP認証のこと、忘れないであげてください。まあ単純にパスワード文字列をハッシュ関数に通しただけじゃ使われないね。普通。

TAKAMAGAHARA @SILVER_CAP 2019年1月31日

alansmithy2010 なるほど、確かにそうでした。

Daregada @daichi14657 2019年1月31日

今回のようなサービス系だと、暗号化されたセキュアな通信路が確立した状況なので、「通信路に平文のパスワードが...」は考えなくていいよな。サーバー側に何を保存するかの話で

Hiro0138🤔 @Hiro0138 2019年1月31日

ハッシュ関数のコリジョンは牛肉からハッシュドポテトを作るようなもんか

ぱんどら @kopandacco 2019年1月31日

私はゲームプログラマであってＳＥ系じゃないのでふわっとした理解だが、ハッシュ化と言うのは元データから数字なり文字列なりを作り出す処理だと認識してる。その処理は一方向で、作った物から元のデータは作りだせないし、そもそも元データに戻す必要が無い時だけ使う。

ぱんどら @kopandacco 2019年1月31日

そんな処理がどんな時に必要かと言うと、例えば今回みたいに「送られてきたデータが前のデータと同一かどうかを判定したいがデータ自体は原形のまま保存したくない」時にはぴったり。

ぱんどら @kopandacco 2019年1月31日

後は「２つのデータが同じかどうかの判定を、いちいち全データチェックしたくない」時にも使う。この場合はハッシュ化したデータが元データよりも短くなる変換を使う。たとえば元データが画像や動画だったりとか。ハッシュ化したデータが短い場合、2つの異なる元データからたまたま同じハッシュが作られる可能性が幾分出てくるが、たまたま複数が一致した時はそれこそ別のチェックで検算すればいい。

ぱんどら @kopandacco 2019年1月31日

あとは「文字列を比較的小さい数値にハッシュ化する」と、文字列をいちいち比較しなくても、1つの数値の大小で比較できるのでソートとか検索とかやりやすくなる。たまたま別のデータが一致する可能性は検算で消せる。

ぱんどら @kopandacco 2019年1月31日

だから今回、せめてハッシュ化してればという話になる。以上。なお間違ってたら専門家が突っ込むだろう。

レイジー先生 @layzy_glp 2019年2月1日

ポテトをハッシュ化したらハッシュドポテトになるけどリンゴをハッシュ化してもハッシュドポテトにならないでしょ？てこと

かつまたいさ（永世日直📛） @kamiomutsu 2019年2月1日

この例だと可逆は「細かく刻む」かな？…一応元の形にくっつけることはできるし…。

すいか @pear00234 2019年2月1日

alansmithy2010 SILVER_CAP 他の人も言ってますが、「通信経路での漏えい」は関係ありません。それを回避するのはHTTPS通信技術とかであり、「平文保存をしない」のは通信経路云々の問題とは関係ないです。平文保存をしてはいけないというのは、「そのデータが漏れた時に、被害を最小限に抑える」のが目的です。

かつのり @k5n6 2019年2月1日

ハッシュ化すれば安全かというとデータベースだけが漏洩したときはまだ安全。でもハッシュ化するロジック部分、特にソルトなどが漏洩したら辞書攻撃などで復号しやすいので要注意です。データベースが漏洩する時点でサーバ乗っ取りの可能性を考慮する必要があり、乗っ取られていれば当然PHPなどのソースコードも丸見えです。仮にJavaでもclassファイルなんかはいくらでも逆コンパイルできます。

Maia Killini @maiakillini 2019年2月1日

同じじゃがいもから作ったハッシュドポテトは全く同じものになるのかどうか

frisky @friskymonpetit 2019年2月1日

maiakillini 同じじゃがいもとは（哲学）

Hoehoe @baisetusai 2019年2月1日

ラプラスの悪魔ってやつに頼めばハッシュドポテトを芋に復元できると聞いたからお前らは全員嘘つき

Zinc in Sanuki @zincinosaka 2019年2月1日

そりゃ1GBの値から生成されたCRC16によって元の値が再現出来たら超圧縮技術の完成だからな。そもそも衝突…。

AtsukoOrikasa @Rutice_jp 2019年2月1日

塩（salt）はユーザー毎個別の味付けをしようね。（ストレッチングとかHMACとかはいいネタ思い浮かばなかった）

Daregada @daichi14657 2019年2月2日

zincinosaka 古のjunk.testネタで「THcomp」ってのがありまして...って、Wikipediaにも載ってるので興味のある方は是非ご覧ください(いい時代だ)

エリ・エリ・レマ・サンバディトゥナイ @mtoaki 2019年2月2日

daichi14657 「カラーコードTM」はだいたいその原理で動いてるね。いまいち普及してないけど。

金目の煮付 @kinmenitsuke 2019年2月2日

friskymonpetit ＞それが流出したら、サーバにこの文字列を直接送り付ければ認証を突破できる。→ん？入力されたパスワードをハッシュ化して平文保管された値と比較するんでしょ？なので衝突の問題はあるのでその意味でのセキュリティリスクはあるけど、認証プロセスを自前のAPIからしか受け付けないようにしておけば「平文で保管」自体は別に良いのでは？

金目の煮付 @kinmenitsuke 2019年2月2日

kinmenitsuke friskymonpetit あ、すみません。元のツイートの意味を履き違えてました。ブラウザから送信させるなんて作りは考えもしなかった。

@kankichi57301 @kankichi57301 2019年2月2日

ところでファミマのハッシュドポテトって以前はハッシュポテトやったのにいつのまにか過去分詞になってるのはなんでやねん？

ブラキストン線の向こう側 @cupsoup2 2019年2月2日

kankichi57301 「マッシュポテト」との混同を避けたかったのでは

KPCG10 @KPCG10 2019年2月4日

friskymonpetit ハッシュ値そのままを送信しても、サーバ側では元の「togetter」が届く想定で文字列をハッシュ関数に突っ込むので、計算値が合わずログインできません。今回の問題で一番の問題は生パスワードが漏れたことであり「メールアドレス＋パスワード」を同じ値で使いまわしている場合、流出した組み合わせで他のサイトにログインされてしまうことです。