2018/10/22 全体的に問題があったので書き直した. 内容はほぼ変わっていない. 本記事では, 世界で最初に提案された公開鍵暗号であるRSA暗号の基礎事項について解説する. RSA暗号の動作原理について示した後, 簡単な攻撃手法の一覧を載せる. 公開鍵暗号 暗号理論, 特に現代暗号における暗号は「秘密鍵暗号(Secret-key Cipher)」, 「公開鍵暗号(Public-key Cipher)」の2種類に大分される. 秘密鍵暗号はよく知られている通り「秘密の鍵$k$を事前に共有しておき, その鍵を用いて暗号化・復号を行う暗号方式」である. これに対して公開鍵暗号は「暗号化に用いる鍵$k _ {enc}$, 復号に用いる鍵$k _ {dec}$が存在し, 暗号化・復号のそれぞれで異なる鍵を用いる暗号方式」と定義され, このうち$k _ {enc}$は一般に公開されることが多いこと
Update 2015/5/8: 指摘頂いたタイポや誤訳などを更新しました。 2015/5/8: 構成を一部修正しました。 Intro 4/30 mozaiila のセキュリティブログに下記のようなエントリが投稿されました。 Deprecating Non-Secure HTTP | Mozilla Security Blog エントリはそこまで長くないので、ここに翻訳の全文を記載します。 そして、元エントリのライセンスである CC BY-SA 3.0 に則り、 本エントリも同じく CC BY-SA 3.0 とします。 Deprecating Non-Secure HTTP 原文: Deprecating Non-Secure HTTP 今日は、 non-secure な HTTP から、徐々に廃止していくという方針についてアナウンスします。 HTTPS が Web を前進させる手段である
Githubが同社サービスに対してDoS攻撃が行われていることを発表しました。一連のDoS攻撃はGreatfire.orgに対して行われているものと考えられ、ここではGreatFire.orgに関係するDoS攻撃の情報をまとめます。 公式発表 GreatFire.org 2015年3月19日 We are under attack 2015年3月25日 (PDF) Using Baidu 百度 to steer millions of computers to launch denial of service attacks Github 公式Blog 2015年3月28日 Large Scale DDoS Attack on github.com · GitHub Github 公式Twitter The attack has ramped up again, and we're evo
いろいろと原則論はあるんですが。昨今のアプリケーションは複雑化し、扱う情報はよりセンシティブになり、そしてより幅広く使われるようになっています。よって「安全な」アプリケーションを作るために必要な知識はますます増える傾向にあります。 よく分かってない人は以下のことにとりあえず気をつけましょう 1. なるべく自分で作らない これは最も重要なことです。検索する、他人に聞く、自分で考えない。これは重要です。大抵の問題は他人が作ってくれた解決策を適用できます。 例えばセキュアな問合せフォームを作ることにしましょう。気をつけるべきことは以下のことぐらいでしょうか。 送信内容の確認画面を表示する場合、ユーザーの入力した値は適切にエスケープするように 送信内容をアプリケーションの DB に格納する場合には SQL インジェクションを防がなければならないので、プリペアドステートメントを用いる CSRF 対策
glibcのgethostbyname系関数に脆弱性の原因となるバグが発見されCVE-2015-0235(GHOST)と命名されたようです。放置した場合は相当多くのアプリケーションがこの脆弱性の影響を受けることが予想されます。 glibcは libcのGNUバージョンです。libcはアプリケーションではなく、事実上全てのアプリケーションが利用しているライブラリです。OSの中ではカーネルに次いで重要な部分と言えます。Linuxシステムでは(ことサーバー用途においては)例外なく glibcが使われています。 この glibcに含まれる gethostbyname系関数の実装に 2000年頃から存在したバグが今になって発見され、CVE-2015-0235 通称 GHOSTと命名されました。ネットワークで何らかの通信を行うアプリケーションは必ず※この関数を使用します。 ※追記: 名前解決をサポート
ポイントは下記の通りです。 X社（原告）はセキュリティ対策について特に指示はしていなかった 損害賠償について個別契約に定める契約金額の範囲内とする損害賠償責任制限があった 当初システムはカード決済を外部委託し直接カード情報を扱っていなかった X社が「カード会社毎の決済金額を知りたい」とY社に依頼をして、その結果カード情報をいったんDBに保存する仕様となった（2010年1月29日） X社からの問い合わせに対してY社は、カード情報を保持しない方式に変更することが可能で、そのほうが安全となり、費用は20万円程度である旨を伝えた（2010年9月27日）が、その後X社は改良の指示をしなかった 以下の脆弱性その他が認められた システム管理機能のIDとパスワードが admin/password であった 個人情報が記載されたお問い合わせログファイルの閲覧が可能（ディレクトリリスティングと意図しないファイ
はてなへのリスト型アカウントハッキングと思われる不正ログインについてのご報告と、パスワード変更のお願い 昨日6月19日（木）、はてなアカウントにおいて、ご登録ユーザーご本人以外の第三者による不正なログインが発生したことを確認しました。同日、疑わしいIPアドレスからのアクセスを遮断しました。このお知らせは本告知と並行して、全ユーザー様にも現在、メール送信しております。 前回告知した不正ログインと同様に、他社サービスから流出または不正取得されたアカウント情報（IDとパスワードの組み合わせ）を流用された「リスト型アカウントハッキング（リスト型攻撃）」である可能性が高いと考えています。 参考資料：「リスト型アカウントハッキングによる不正ログインへの対応方策について」（総務省） http://www.soumu.go.jp/menu_news/s-news/01ryutsu03_02000063.h
国立国会図書館は2014年5月15日、国会図書館のネットワークシステムの運用管理業務を委託した日立製作所の社員が同図書館の業務サーバーに侵入して、同図書館の内部情報を不正に取得していたことが分かったと発表した。日立社員による不正取得は2011年から始まっており、同図書館が実施するシステム開発の入札に関わる他社提案書や参考見積もりなども取得していたという。 日立社員による不正は2014年3月27日に発覚した。国会図書館のネットワークシステムの運用管理を担当していた日立社員（システムエンジニアで肩書きは技師）は、国会図書館から貸与されたPCを使って運用管理業務に当たっていた。その日、国会図書館の職員が、日立社員が使用していた貸与PCの画面を見たところ、そのPCで使用したファイル履歴に「入札に関わる資料など、日立社員が見てはならないファイル名が含まれていた」（国会図書館広報）ことから、日立社員に
これらの「配信先URL」にアクセスしてみると。 ああこれはダメなやつだ。 firestorageユーザーがアップロードしたファイルの「ダウンロードリンク」が、YDNの「広告配信先レポート」でモロバレです。 ダウンロードURLは40桁の英数字にて暗号化されていますので、アップロードされた方が他の方にお知らせしない限り、URLが知られることはありません。 いや漏れてるから。 ダウンロードページにリスティング広告を掲載するfirestorage側の注意不足でもあり、情報漏洩に直結しそうなURL情報をレポートで公開するヤフー側の不手際でもあり、さらにはオンラインストレージをパスワード設定無しで利用するユーザー側のセキュリティ意識の欠如でもあり。 ダウンロードファイル名から判断する限りではありますが、明らかに社外秘だろ的なものがいくつも含まれており、関係各位の今後の身の処し方が他人事ながら大変心配で
JVNやJPCERT/CCの記事があまりにもさらっと書かれていて、具体的なリスクが想像しづらいと思うので説明します。 今北産業 (今ニュース見て来たから三行で教えて欲しいという人向けのまとめ) インターネット上の「暗号化」に使われているOpenSSLというソフトウェアが2年間壊れていました。 このソフトウェアは便利なので、FacebookだとかYouTubeだとか、あちこちのウェブサイトで使っていました。 他の人の入力したIDとかパスワードとかクレカ番号とかを、悪い人が見ることができてしまいます。(実際に漏れてる例) 他にも色々漏れてますが、とりあえずエンジニア以外の人が覚えておくべきはここまででOKです。もう少し分かりやすい情報が以下にあります。 OpenSSL の脆弱性に対する、ウェブサイト利用者（一般ユーザ）の対応について まだ直っていないウェブサイトもあれば、元々壊れていないウェブ
It's time to update your passwords to various sites affected by the Heartbleed bug. Credit: Mashable composite. iStockphoto, SoberP An encryption flaw called the Heartbleed bug is already being dubbed one of the biggest security threats the Internet has ever seen. The bug has affected many popular websites and services -- ones you might use every day, like Gmail and Facebook -- and could have quie
必要な情報は http://heartbleed.com/ にまとまっているのですが、英語だし長いしって人のために手短にまとめておきます。 どうすればいいのか OpenSSL 1.0.1〜1.0.1fを使っていなければセーフ あてはまる場合には、一刻も早くバージョンアップして、サーバごと再起動(わかるひとはサービス単位でもOK、ただしreloadではだめなことも) SSL証明書でサーバを公開しているなら、秘密鍵から作り直して証明書を再発行し、過去の証明書を失効させる(末尾に関連リンクあり)。 サーバを公開していない場合も、外部へのSSL通信があれば影響を受けるので、詳しく精査する。 PFS(perfect forward secrecy)を利用していない場合、過去の通信内容も復号される可能性があるため、詳しく精査する。 漏洩する情報の具体例は、OpenSSLの脆弱性で想定されるリスクとして
クラウド環境を悪用した仮想通貨の採掘が密かに行われているようです。今回発覚したのはLuke Chadwick氏のAWSのキーがGitHub上にアップされているのを発見した何者かが、20台ものcc2.8xlargeインスタンスを起動させてBitCoinプロトコルを使った仮想通貨であるlitecoinの採掘を行ったとの事です。 AWSからの警告で気がつき、インスタンスを停止するまでの数日間で利用料金は3000ドルを越えたとの事です。 Litecoinは、世界中の誰に対してもすぐに支払えるP2Pの仮想通貨です。Bitcoinプロトコルに基づいていますが、一般のハードウェアを用いて効率的にデータマイニングできるという点でBitcoinと異なります。Litecoinは素早い取引認証（平均2分半）を実現し、多くの人が所有している一般コンピュータとGPUをターゲットにするメモリーハード、scryptベー
2013年10月、米Adobe Systemsが不正アクセスを受け、少なくとも3800万人分のユーザーIDと、暗号化されたパスワードが流出した事件がありました。この暗号化されたパスワード、現在ではすでに一部が推測可能状態になっており、使われていたパスワードのトップテンも発表されています。 使われていたパスワードのトップテンをみて、読者のみなさんはどう思いますか。「自分も使っているなあ」なんてものがありませんでしたか？ 「123456」を暗号化しても、ヒントが「654321」じゃあ…… 通常パスワードは、システムに保存するときにそのままではなく暗号化を施すことが通例です。アドビは今回暗号化していたと発表していますが、上記記事では「ユーザーが平文で保存していた『パスワード推測のヒント』があったおかげ」で一部が解読できたとされています。 ここでいう「パスワード推測のヒント」とは、Windowsの
技術者としての良心に従ってこの記事を書きます。俺はセキュリティとプライバシーの人ではなく、JavaScriptとUIの人である。法律の勉強だって自分の生活と業務に関わりのある範囲でしかしないだろう。しかし少なくともJavaScriptやブラウザが絡むような部分については、確実に自分のほうが理解していると思っている。高木浩光さんが、あからさまに間違ったことを書いたり、おかしなことを書いていたりしても、徐々に誰も指摘しなくなってきたと思う。おかしなこと書いていたとしても、非技術者から見たときに「多少過激な物言いだけど、あの人は専門家だから言っていることは正論なのだろう」とか、あるいは技術者から見た時でも、専門分野が違えば間違ったことが書かれていても気付けないということもあるだろう。 もう自分には分からなくなっている。誰にでも検証できるような事実関係の間違い、あるいは、技術的な間違いが含まれてい
先週、忍者ツールズ全サービスが一時的に利用できなくなりました。 株式会社サムライファクトリー：忍者ツールズ全サービスが表示不可となる障害につきまして お名前.com：忍者ツールズ全サービスが表示不可となる障害につきまして 本の虫: DNSの終焉が垣間見える、ぶっ飛んでて危険すぎるお名前.comの検閲事件 その理由として、株式会社サムライファクトリー(忍者ツールズ)のプレスリリースには以下のようにあります。 忍者ツールズのサービスを利用したユーザーサイトの一部に、お名前.comの約款に抵触するサイトがあり、お名前.comへのお問い合わせが複数あったため、約款に基づきお名前.comでは一時的にドメインの停止措置をとる対応を行いました 個人的な感想としては、忍者ツールズのドメイン停止措置事件は今までにない新しいタイプのものであると思いました。 まず、お名前.comとninja.co.jpに関して
以前、CSRFについてのエントリを書きました。 CSRFについて - おもしろWEBサービス開発日記 上記エントリではCSRFの概念について書きましたが、もう少しつっこんで調べる必要が出てきました。調べたことを書いてゆきます。 基礎 application.rb(ないし適当なController)にprotect_from_forgeryメソッドを定義すれば、railsが自動的にCSRF対策をしてくれます。というか、デフォルトでapplication.rbに下記のように書いてあるので、特に何もせずともCSRF対策はバッチリなのです。 protect_from_forgery # :secret => '8ff3ed33f86a431662d8dfe255acdb4a' railsは、get以外の動詞のリンクに、authenticity_tokenというパラメータを自動的に付け加えます。ge
ブログ パスワード認証 閲覧するには管理人が設定した パスワードの入力が必要です。 管理人からのメッセージ https://mac-tegaki.comへ移転中 閲覧パスワード Copyright © since 1999 FC2 inc. All Rights Reserved.
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
