ソルト付きハッシュのソルトはどこに保存するのが一般的か - Qiita
pictBLandとpictSQUAREに対する不正アクセスがあり、パスワードがソルトなしのMD5ハッシュで保存されていたことが話題になっています。 2023年8月16日に外部のフォーラムにpictSQUAREより窃取した情報と主張するデータ販売の取引を持ち掛ける投稿が行われた（中略）パスワードはMD5によるハッシュ化は行われているもののソルト付与は行われていなかったため、単純なパスワードが使用されていた29万4512件は元の文字列が判明していると投稿。（それ以外の26万8172件はまだMD5ハッシュ化されたままと説明。） 不正アクセスによるpictBLand、pictSQUAREの情報流出の可能性についてまとめてみた - piyolog より引用 これに関連してMD5ハッシュやソルトに関するツイート(post)を観察したところ、どうもソルトの理解が間違っている方が多いような気がしました。
フリーWi-Fiを使ったら秘密情報を抜かれる経路にはどのようなものがあるか - Qiita
ゴールデンウィークのはじめ（4月29日）に投稿された以下のツイートですが、5月7日20時において、1,938.8万件の表示ということで、非常に注目されていることが分かります。 我が名はアシタカ！スタバのFreeWi-Fiを使いながら会社の機密情報を扱う仕事をしてたら全部抜かれた。どうすればよい！ pic.twitter.com/e26L1Bj32Z — スタバでMacを開くエンジニア (@MacopeninSUTABA) April 29, 2023 これに対して、私は以下のようにツイートしましたが、 これ入社試験の問題にしようかな。『スタバのFreeWi-Fiを使いながら会社の機密情報を扱う仕事をしてたら全部抜かれた』と言う事象に至る現実的にありえる脅威を説明せよ。結構難しいと思いますよ。 https://t.co/LH21zphCTV — 徳丸 浩 (@ockeghem) April
macOSの暗号化zipの話の続き - NFLabs. エンジニアブログ
はじめに こんにちは。事業推進部でOffensive Teamを担当する永井です。 今回はアドベントカレンダーの11日目として、前回投稿した「macOSの暗号化zipファイルはパスワードなしで解凍できる」という記事に寄せられたコメントのうち、特筆すべきものをピックアップして回答していきます。 前回の記事を読んでいない方や、もう覚えてないという方は是非前回の記事を見てから続きを読んでいただければと思います。 Q. 正解するまでbkcrackを回さなくてもzip内のCRC32値と比較すれば良いのでは？ はい、その通りです。 筆者が前回の記事を書いている時には完全に失念していましたが、zip内にはファイル破損を検出するためにCRC32形式のハッシュ値が含まれています。そのため、bkcrackを正解パターンを引くまで都度回さなくても簡単に正解の.DS_Storeを見つけ出すことができます。 実際に
macOSの暗号化zipファイルはパスワード無しで解凍できる - NFLabs. エンジニアブログ
はじめに こんにちは。事業推進部でOffensive Teamを担当する永井です。 先日のApple発表会では新型のiPhoneやApple Watchなど心躍る製品が色々と発表されましたね。筆者は特に新型iPad miniが心に刺さっています。 さて、今回はApple関連の話として「macOSの暗号化zipファイルはパスワード無しで解凍できる」というネタについて書いていきます。 解凍できる条件 何を言っているんだと思われるかもしれませんが、macOSで作られた暗号化zipファイルは以下の2つの条件を満たす場合にパスワード無しで容易に解凍が可能です。 zipの暗号化方式がzipcryptoである (通常の暗号化zipファイルは基本的にzipcryptoが利用されています) zip内のいずれかのディレクトリの中身が.DS_Storeファイルおよび何らかのファイル1つである このうち1.は基本
scryptがGPUに破られる時 | びりあるの研究ノート
一般的によく知られている SHA-256 や MD5 などのハッシュ関数は非常に単純な設計となっており、非力なパソコンや組み込み機器、スマフォなどでも高速に計算できます。 しかしながらその一方で、ハッシュ関数を手当たり次第に計算し、もとの入力値を復元するいわゆる「ブルートフォース攻撃」が容易であるというデメリットがあります。 特にこのような SHA-256 や MD5 といったハッシュ関数は、GPU を用いるか、もしくは専用のハードウェア (FPGA もしくは ASIC) を製作することで非常に高い効率で計算（攻撃）ができてしまうことが知られています。 そのため、GPU ないし専用ハードウェアを用いたとしても、攻撃効率の改善が難しくなるような新たなハッシュ関数がいくつか提案されています。 その中で比較的古く (2012年ごろ) に開発され、他のハッシュ関数にも影響を与えている「scrypt
『証明書を無料で発行、HTTPSの導入を支援する「Let's Encrypt」』は何に使え、何に使えないのか - いろいろやってみるにっき
やっと、ついに、誰もが無料でHTTPSを使えるようになる！…MozillaやEFFが共同プロジェクトを立ち上げ - TechCrunchだが、ブコメ欄で「フィッシングサイトが見分けられなくなる」と勘違いしている向きがあるようなので、ちょっと書いておく。 このLet's Encryptだが、Let’s Encrypt: Delivering SSL/TLS Everywhereに説明が書かれている。そもそも上のTechCrunchの記事ではLet's Encryptがどういうものか分からない。この記事では何ができて何ができないかを書いていないし。 TechCrunchの記事はオレが見た時点(2014/11/20 5:00)ですごいブクマ数(792ユーザ)なんだけど、本体の説明のブクマ数は4ユーザ、オレがブックマークしたので5ユーザである。ちょっと調べてからコメントすればいいのに。 下記のほう
WiresharkでSSL通信の中身を覗いてみる - ろば電子が詰まつてゐる
OpenSSLの脆弱性「Heartbleed」が世間を賑わせていますが、色々と乗り遅れてしまった感があるので、ゆるゆると落ち穂拾いをしようかと思います。 Heartbleedで秘密鍵を手に入れたらSSL通信の中身全部見えちゃうじゃん!! という事態になっていますが、なんとなく理論的にそうだろうなと分かるもののイマイチ具体的な手順が分からない。 というわけで今回のテーマとして、手元にサーバの秘密鍵と、SSL通信をパケットキャプチャしたpcapファイルがあるときに、Wiresharkでどんな感じでSSL通信を「ほどく」のか……という具体的な手順を、ハマり所を含めてまとめておこうかと思います。 というか、私自身がハマったので自分用メモですな。なおこの文書では"SSL"とだけ記述し、TLSは無視しています。 前提条件 とりあえず以下のような感じの検証環境で試しました。 IPアドレス 説明 ホストO
Adobeサイトから漏えいした暗号化パスワードはなぜ解読されたか
Adobe社のサイトの不正アクセス（参照、参照）によって、少なくとも3800万人のIDと暗号化されたパスワードが漏えいしたと言われています。既に報告したように、私のアカウントも漏えいしていました。 その後、『Adobeの情報流出で判明した安易なパスワードの実態、190万人が「123456」使用』というニュースが流れてきました。安易なパスワードが使われている統計は今までもあり、「パスワードの実態」に関しては「そんなものだろうな」と思いましたが、問題は、どうやって「暗号化パスワード」を解読したかです。 別の報道では、Adobeサイトがパスワードの暗号化に用いていたアルゴリズムはトリプルDESだったということです。トリプルDESは電子政府推奨暗号リストの今年の改訂でもしぶとく生き残り広く使われている暗号化アルゴリズムです。そんなに簡単に解読されたのでは問題ですが、実際には、「トリプルDESが解読
パスワード保存とソルトの話
先日、twitterへのハッキング行為が発見された、という発表がなされました。一部のユーザのデータが漏洩したということです。 この件について個人的に懸念を感じたため、それをこちらに書いておきました。原文では encrypted/salted password と呼ばれていたものが、日本語の公式ブログでは「暗号化されたパスワード」となり、これが朝日新聞では「パスワード」と表記されているという問題です。 専門知識があれば、ここにどういう違いがあるかはわかるのですが、そうでなければわからないのも無理はありません。しかし、わからないからといって省略して良いわけでもありません。パスワードと encrypted/salted password は大きく異なります。 ではどう違うのか？ この話について、ひと通りの解説をしてみるのも良いのではないかな、と思ったのでしてみます。 「パスワード」は保存されない
uu59のメモ | Linkedinに学ぶウェブサービスのパスワード管理手法(saltとストレッチング)
Linkedinがパスワード漏洩事件を起こしたわけですが、saltもストレッチングもせずベタにsha1したものを使っていたようです。様々な立場から様々な意見が考えられますが、ここではサービス運営者としてsaltやストレッチングをしていれば何がどうなっていたのかという点を考えていきます。 ちなみに、なんでもかんでも脆弱なパスワードを設定するユーザーが悪いと言うのはサービス提供者による責任転嫁だと考えていますので、提供者はたとえユーザーに脆弱なパスワードを設定されたとしても、可能な限りユーザーのパスワードが奪取される危険性を小さくする努力をすべきでしょう。 SHA1の計算 hashgpuによると、どこのご家庭にもあるような数千円のGPUを使えば秒間23億回の試行が可能らしいです。 ASCIIコードのうち制御文字以外の印字可能文字は95種あるので、任意の桁数のパスワードを解析するのに総当たりでど
Webアプリでパスワード保護はどこまでやればいいか
Mercari JPのモノリスサービスをKubernetesに移行した話 PHP Conference 2022 9/24Shin Ohno
本当は怖いパスワードの話 ハッシュとソルト、ストレッチングを正しく理解する － ＠IT
PSN侵入の件から始めよう 今年のセキュリティの話題の中でも特に注目されたものとして、4月20日に起こったPSN侵入事件があります。5月1日にソニーが記者会見をネット中継したことから、ゴールデンウィーク中にもかかわらず多くの方がネット中継を視聴し、感想をTwitterに流しました。もちろん、筆者もその1人です。 このときの様子は、「セキュリティクラスタまとめのまとめ」を連載している山本洋介山さんが、Togetterでまとめています。 Togetterのまとめを読むと、漏えいしたパスワードがどのように保護されていたかが非常に注目されていることが分かります。Togetterのタイムラインで、14:48ごろにいったん「パスワードは平文保存されていた」と発表されると、「そんな馬鹿な」という、呆れたり、驚いたりのつぶやきが非常に多数流れます。 しかし、15:03ごろに「パスワードは暗号化されてなかっ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://www.machu.jp/posts/20060507/p01/