ソルト付きハッシュのソルトはどこに保存するのが一般的か - Qiita
pictBLandとpictSQUAREに対する不正アクセスがあり、パスワードがソルトなしのMD5ハッシュで保存されていたことが話題になっています。 2023年8月16日に外部のフォーラムにpictSQUAREより窃取した情報と主張するデータ販売の取引を持ち掛ける投稿が行われた（中略）パスワードはMD5によるハッシュ化は行われているもののソルト付与は行われていなかったため、単純なパスワードが使用されていた29万4512件は元の文字列が判明していると投稿。（それ以外の26万8172件はまだMD5ハッシュ化されたままと説明。） 不正アクセスによるpictBLand、pictSQUAREの情報流出の可能性についてまとめてみた - piyolog より引用 これに関連してMD5ハッシュやソルトに関するツイート(post)を観察したところ、どうもソルトの理解が間違っている方が多いような気がしました。
メタップスペイメント不正アクセス事件の第三者報告書から攻撃の模様を読み解く
株式会社メタップスペイメントの運営する決済代行システムから約288万件のクレジットカード情報が漏洩した不正アクセス事件について、第三者委員会の報告書および経済産業省の行政処分（改善命令）があいついで公開されました。 第三者委員会調査報告書（公表版） クレジットカード番号等取扱業者に対する行政処分を行いました （METI/経済産業省） 本稿では、主に第三者委員会の調査報告書（以下「報告書」と表記）をベースとして、この事件の攻撃の様子を説明します。 システムの概要報告書にはシステム構成図やネットワーク構成図は記載されていないため、報告書の内容から推測によりシステムの構成を以下のように仮定しました。 図中のサーバー名は報告書の記載に従っています。以下、概要を説明します。 サーバ名概要 A社アプリ一般社団法人A 会員向け申込みフォーム 経産省改善命令では、「同社とコンビニ決済に係る契約を締結してい
パスワードが漏洩しないウェブアプリの作り方 〜 ソルトつきハッシュで満足する前に考えるべきこと
■■序論 徳丸さんのスライド「いまさら聞けないパスワードの取り扱い方」に見られるように、昨今、ウェブアプリケーションの設計要件として、サーバ内に侵入された場合でもユーザーのパスワードをできるだけ保護すべきという論調が見受けられるようになってきました。 上掲のスライドでは、その手法としてソルトつきハッシュ化を勧めています。しかしながらスライドに書かれているとおり、ソルトつきハッシュには、複雑なパスワードの解読は困難になるものの、単純なパスワードを設定してしまっているユーザーのパスワードについては十分な保護を提供できないという問題があります。そして、多くのユーザーは適切なパスワード運用ができない、というのが悲しい現実です。 ソルトつきハッシュを使った手法でこのような問題が残るのは、ウェブアプリケーションサーバに侵入した攻撃者がユーザーの認証情報をダウンロードして、認証情報をオフライン攻撃するこ
FuelPHP でのデータベース接続設定 〜 root のパスワードを root にしないでください - A Day in Serenity @ kenjis
FuelPHP の設定ファイルの仕組みを理解していないブログ記事がいくつか見られ、それが拡散しているようなので解説を書いておきます。 データベース接続設定を正しくしていないために、うまく接続できず、 とりあえずmySQLのrootパスワードをrootに変えることで動いた。 さくらVPSでFuelPHPからmySQLへDB接続 | ネットビジネスで月収100万は難しくない！ とか、 configの下にある下記dir ・development ・production ・staging ・test を削除したら動いたらしい。 FuelPHP DB接続（さくらスタンダード） | 亀のよーにのろのろと [FuelPHP] DB接続でちょっとハマる | suka4's memo 上記のように FuelPHP の設定ファイルを配置する app/config フォルダ内の、環境別の設定ファイルを配置するフ
徳丸本のあれこれを実践してみて気付いたこと | 水無月ばけらのえび日記
更新: 2011年7月9日23時0分頃 とあるシステムで徳丸本のストレッチングを採用することにしたという話がありましたが、その実装が佳境に入ってきました。私は指示だけ出して、実装はお任せ……と思っていたのですが、基本的な部分を作ってもらったところでバトンタッチされ、私が引き継ぐ形で実際にコードを書くことになりました。 基本的には徳丸本 (www.amazon.co.jp)のオススメどおりの実装にするという方針なのですが、実際にコードを書いてみると、いろいろと気になったり迷ったりした事も出てきました。そのあたりを簡単にメモしておきます。 ※ちなみに、このシステムはRuby1.9.2 + Ruby on Rails3での実装なので、PHPのコードサンプルをそのまま使っているわけではありません。 ストレッチ回数をどう決めるのか徳丸本327ページにあるコード例を参考にして実装。アプリケーションごと
SHA1でハッシュ化したパスワード - teracc’s blog
SHA1でハッシュ化したパスワードは危険になった - yohgaki's blog を読みました。その記事に関連したことを書きます。 ハッシュアルゴリズムの切替え 記事を読んで思い出したのは、既にパスワードをハッシュ化して保存していて、そのアルゴリズムが脆弱になった場合に、いかにアルゴリズムを切替えるかという問題です。 ハッシュデータは元に戻せないため、アルゴリズムを切替えるのも難しいのです。 パスワードはどうやって持つ？ - がるの健忘録 パスワード暗号処理変更用 大雑把草案 - がるの健忘録 上記の日記で、この問題を扱っています。その日記の中では、 ユーザがログイン成功した際に、システム側でパスワードが判る。 その際に、DB保存データを新アルゴリズムの形式にする。 という方式が提案されています。この方式では、システム更新後に、ログインしたユーザから順次新しいアルゴリズムになります。ログ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Webアプリケーションにおけるパスワードの管理について
