タグ

securityに関するlove0hateのブックマーク (47)

  • 高木浩光@自宅の日記 - クロスサイトリクエストフォージェリ(CSRF)の正しい対策方法

    ■ クロスサイトリクエストフォージェリ(CSRF)の正しい対策方法 「クロスサイトリクエストフォージェリ」がにわかに注目を集めている。古く から存在したこの問題がなぜ今まであまり注目されてこなかったかについて考 えているところだが、引越しやら転勤やらでいまひとつ日記を書く時間がない。 しかし、 @ITの記事などのように混乱させる解説も散見されるので、一点だけ対策 方法について書いておくとする。 クロスサイトリクエストフォージェリ――Cross-Site Request Forgeries (CSRF)を防止する簡潔で自然な解決策は以下のとおりである。 前提 ログインしていないWeb閲覧者に対するCSRF攻撃(掲示板荒らしや、ユーザ登 録を他人にさせる等、サイト運営者に対する業務妨害行為)はここでは対象と しない。 ログイン機能を持つWebアプリケーションの場合、何らかの方法でセッション 追

  • 高木浩光@自宅の日記 - ASPとかJSPとかPHPとかERBとか、逆だったらよかったのに

    ■ プログラミング解説書籍の脆弱性をどうするか 印刷されて流通する書籍に脆弱性がある、つまり掲載されているサンプルコードにズバリ脆弱性があるとか、脆弱性を産みやすいコーディングスタイルを身につけさせている解説があり、それが脆弱なプログラマを生産し続ける根源になっている問題は、「なんとかしないといけないねえ」と以前から言われてきた。 ソフトウェア製品の脆弱性は、指摘があればパッチが提供されたり修正版に差し替えられたりするが、書籍の脆弱性はどうか。正誤表が差し込まれるとか、回収する措置がとられるかというと、それは望めそうにない。言論には言論で対抗すればよいということになるだろうか。 久しぶりにいくつかの書籍について調べてみた。先月園田さんの日記などで比較的評判良く紹介されていた2冊を読んだ。 山勇, PHP実践のツボ セキュアプログラミング編, 九天社, 2004年6月 GIJOE, PHP

  • 高木浩光@自宅の日記 - 続・「サニタイズ言うなキャンペーン」とは

    ■ 続・「サニタイズ言うなキャンペーン」とは 「サニタイズ」という言葉はもう死んでいる サニタイズ言うなキャンペーンがわかりにくい理由, 水無月ばけらのえび日記, 2006年1月5日 というコメントを頂いた。まず、 これは「サニタイズという言葉を使うな」という主張ではありません。「そもそもサニタイズしなくて済むようにすべきだ」という主張です。言い方を変えると、「サニタイズせよと言うな」という主張になります。 「サニタイズ言うなキャンペーンがわかりにくい理由」, 水無月ばけらのえび日記, 2006年1月5日 とある。「サニタイズせよと言うな」キャンペーンでもよいのだが、 その場合は次の展開が予想される。 「サニタイズせよと言うな」を主張する際の具体例として、XSSやSQLインジェ クションのケースを挙げた場合、正しいコーディングは、「その場の文脈でメ タ文字となる文字をエスケープすること」と

  • パスワードのハッシュに使うべきPBKDF2、Bcrypt、HMACの各言語実装一覧 - このブログはURLが変更になりました

    いつも忘れるのでメモ。 元ネタ:Are you sure SHA-1+salt is enough for passwords? 日語訳:「SHA-1+salt」はパスワードに十分だと思いますか? こうしたスキームをいくつか選ぶことができる: PBKDF2 http://en.wikipedia.org/wiki/PBKDF2 Bcrypt http://www.openwall.com/crypt/ HMAC http://en.wikipedia.org/wiki/HMAC 各選択肢はそれぞれの強みと弱みがあるが、これらは全てSHA1+saltのような汎用ハッシュのインプリメンテーションより、はるかに強力だ。 ということで、各言語での実装を調べてみた。実装が正しいかは調べてない。別実装もあるかもしれない。 言語 PBKDF2 Bcrypt HMAC Java Bouncy Castl

    パスワードのハッシュに使うべきPBKDF2、Bcrypt、HMACの各言語実装一覧 - このブログはURLが変更になりました
  • データベースの暗号化、もしくはパスワードの保存方法のまとめ - めもおきば

    追記: (2021-06-04) いまだにこの記事へのアクセスが多いので、2021年現在におけるパスワードの取り扱いに関するベストプラクティス記事を紹介します。 cloud.google.com (追記ここまで) PSNの障害で盛り上がっていますが、クレジットカード番号は暗号化していたがパスワード含む個人情報は暗号化していなかったという点が注目されているようです。 というわけで、パスワードの保存方法についてまとめてみます。 前提となる暗号の話 いわゆる暗号化と呼ばれている技術には、以下の2種類があります。 1. 復号のための鍵があって、暗号化する前の「平文」に戻すことができる「暗号化」 ざっくり言えば、この2通りの操作ができます。 平文と鍵1 ―(暗号化)→ 暗号文 暗号文と鍵2 ―(復号)→ 平文 平文が暗号化される前のデータ、鍵と書かれているのが2048ビットだったりする暗号化の方法に

  • エフセキュアブログ : 「SHA-1+salt」はパスワードに十分だと思いますか?

    「SHA-1+salt」はパスワードに十分だと思いますか? 2011年02月09日17:39 ツイート fsecure_corporation ヘルシンキ発  by:ジャルノ・ネメラ アナーキーなインターネットグループ「Anonymous」が先頃、HBGary Federalとルートキットテクノロジの分析と開発に専心しているオンラインフォーラム「rootkit.com」をハッキングした。「rootkit.com」の全ユーザパスワードに障害が起きている。 この件に関連して、アプリケーションセキュリティで気に入っているトピック、すなわちパスワードハッシュについて指摘したい。 Web(およびその他の)アプリケーションが、ユーザパスワードのハッシュにMD5、SHA1またはSHA-256を使用しており、先進的なデベロッパさえ、そのパスワードをsaltしている。そして私は長年に渡って、salt値はどの

    エフセキュアブログ : 「SHA-1+salt」はパスワードに十分だと思いますか?
  • パスワードのハッシュ値を保管するときのsaltの作り方

    flat/京山和将@昼夢堂 @flat_ff パスワードハッシュ値のsaltって低品質の乱数由来でもいいんだろうか?ユーザーごとに分けろって話はあるけど、精度はあまり問題にならない?見つけた範囲では、/dev/urandomつかってるものから、平文パスのmd5を使ってるものまでさまざま。 2011-01-13 10:48:12

    パスワードのハッシュ値を保管するときのsaltの作り方