OWASPに学ぶパスワードの安全なハッシュ化 | DevelopersIO
Dropbox はソルトとペッパーを利用 次の Dropbox 技術ブログによると、2016年9月時点の Dropbox は、パスワードをソルト化とペッパー化のコンボで保存していました。 How Dropbox securely stores your passwords - Dropbox 具体的には パスワードを SHA512 でハッシュ化 このハッシュ値をソルトとともに bcrypt でハッシュ化 最後にペッパーを鍵に AES256 で暗号化 というようにパスワードを多段で保護してデータベースに保存していました(AES256(BCRYPT(SHA512(PASSWORD) + SALT), PEPPER))。 ※ 図はブログ記事より引用 Dropbox はあくまでもペッパーの実例として紹介しました。 bcrypt の項でお伝えしたように、bcrypt 処理前にパスワードをハッシュ化す
JVN#97370614: マガジンガーＺ におけるクロスサイトスクリプティングの脆弱性
CGI Script Market が提供するマガジンガーＺ <http://cgiscriptmarket.com/magazinegerZ/> は、ウェブサイトにメールマガジン配信機能を提供する CGI スクリプトです。 マガジンガーＺ には、管理画面にログインした管理者のウェブブラウザ上で、意図しないスクリプトが実行される格納型クロスサイトスクリプティング (CWE-79) の脆弱性が存在します。 この案件は、2021年1月22日に開催された公表判定委員会による判定にて、平成29年経済産業省告示第19号および、情報セキュリティ早期警戒パートナーシップガイドラインにおける、次のすべての条件を満たすことを確認したため、JVN で公表することが適当と判定されました。IPA は、その判定を踏まえ、脆弱性情報を公表すると判断しました。 当該案件が調整不能であること 製品開発者への連絡方法として
パスワードを決める画面でのアホなルールを集めたリポジトリ dumb-password-rules | 秋元@サイボウズラボ・プログラマー・ブログ
dumb-password-rules/dumb-password-rules パスワードの登録や更新画面で出てきたおかしな制約やエラーを募集している GitHub リポジトリがあります。 あほなパスワードの文字制限を分類 多数の事例が載っていますが、代表的なものをグループ化してみます。 文字種や記号を謎に制限 「% は使えません」「\ は使えません」 – 内部でエスケープしちゃうんですねわかります。ちゃんと作ってあればこんな特例要らないと思うんですが。 「記号で使えるのは ? ! $ €% & * _ = – +. ,:; / () {} [] ~ @ # だけです」 「記号はアンダースコアとハイフンだけ使えます」 「数字や記号は使えません」 「使える記号がありますが、どの記号が使えるかは秘密です」 「パスワードは5-15文字です(が、スペースは文字数としてカウントしません)」 「パスワ
高度なマルウェア「VPNFilter」、54カ国で感染拡大 一斉攻撃の恐れも
感染したデバイスに対して「kill」コマンドが実行されれば、大量のルータが同時に使用不能に陥る恐れもある。 米Ciscoのセキュリティ部門Talosは5月23日、国家の関与が疑われる高度なモジュール式マルウェア「VPNFilter」が、世界54カ国で50万台以上のルータなどに感染を広げていると報告した。一斉攻撃を仕掛けられれば大量のルータが同時に使用不能に陥る恐れもあるとして、警戒を呼び掛けている。 Ciscoによると、VPNFilterの感染が確認されているのはLinksys、MikroTik、NETGEAR、TP-LinkのSOHO向けネットワーキングデバイスと、QNAPのNASデバイス。同マルウェアにWebサイトの認証情報を盗んだり、産業制御装置（SCADA）用通信プロトコルのModbusを監視したりするコンポーネントが含まれている点は、特に憂慮されるとしている。 さらに、感染したデ
第4回 JavaScript実行制御で情報漏えいを防ぐ
Web 2.0という言葉で総称される新たなインターネット時代。Webサイトやエンドユーザーに仕掛けられる攻撃もまた，2.0と呼ぶべき進化を遂げようとしている。攻撃者はWeb 2.0の中核技術であるJavaScriptを悪用してブラウザを狙う。従来の脅威対策は全く通用しない。今回はユーザーが今すぐ実践可能な対策を解説する。 XSS対策は，Webサイトとクライアント（ブラウザ）の両方からのアプローチが考えられる（図5）。Webサイトに潜むXSSのぜい弱性を根絶することと，ブラウザの設定変更や機能拡張によってエンドユーザーが自衛手段を講じることである。 そもそもWebサーバー側にXSSのぜい弱性がなければ，攻撃されるリスクはぐっと小さくなり，クライアント側の対策は必要最低限で済むはず。にもかかわらず専門家はクライアント側の対策を積極的に勧める。サイト側の対策にはどうしても漏れが生じがちなためであ
ITmedia Biz.ID：作業中にPCから離れる場合の“お作法”
書類などの作成中にPCから一時的に離れる場合、画面を誰かに覗き見られることがないよう、適切なセキュリティ対策を施そう。 PCでの作業中、デスクトップ上に重要なファイルの内容を表示したまま席を離れるのは、セキュリティ上あまりよろしくない。スクリーンセーバーがすぐに起動してくれれば問題ないのだが、Windowsの仕様上、スクリーンセーバーの自動起動には無操作状態が最低でも1分続くことが必要だ。 すぐにスクリーンセーバーを起動させたいのなら、デスクトップ上にスクリーンセーバーのショートカットを作っておくと便利だ。WindowsのSYSTEM32フォルダ内にスクリーンセーバーのプログラム（拡張子が「.scr」のファイル）があるので、そこから好きなものを選び、ショートカットを作成するのだ。必要に応じてそれをダブルクリックすれば、スクリーンセーバーをすぐに起動できる。
T.Teradaの日記 - ログイン直後のレスポンスの返し方
多くの会員制Webサイトでは、ID/PWによるログイン処理がある。ユーザにログイン画面を提示し、ユーザがフォームにID/PWを入力してsubmitする。ID/PWがOKであれば、ユーザのブラウザにはログイン後の画面が表示される。 以下に、これを実現するための2通りのシーケンス図を描く。セキュリティの観点で望ましいのはA、Bのどちらだろう？というのが今回のテーマ。 Aではログイン要求に対してHTTPステータス200応答とともにログイン後画面をブラウザに返している。Bではログイン要求に302応答を返して（HTTP1.1では303応答）、ログイン後画面にリダイレクトしている。 結論を言うと、セキュリティの観点では、私はBの方が望ましいと考えている。 逆に言うと、Aにはどうにも気に入らないところがある。それは、ID/PWを含むリクエストに対して200応答を返していることだ。200応答のページは、ブ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
