GDPRについてソフトウェアエンジニアは何を知るべきか?
もう1つの重要なテーマは、プライバシバイデザインとプライバシバイデフォルトです。これは、今後、すべてのアーキテクチャへ実際に統合されるべきです。この規則以前は、プライバシバイデザインとプライバシバイデフォルトは、設計の自動的要素でしたが、人々は何かが起きるまで、セキュリティやプライバシにお金を払いたくありませんでした。GDPRは、今、これに対処する強力な動機付けになります。2,000万ユーロまでの価値を動機付けます。プライバシバイデフォルトはいろいろなことを意味しますが、本来、個人識別データとそのプライバシを適切に管理して、保護することを目的とします。これが一般的に要求するのは、例えば、特に個人識別情報の読み取りアクセスを含む、誰がいつ何をしたかという明白な監査証跡です。さらに、そのデータがいつ保存され、様々なレイヤを移動したかに注意を払い、システムからデータが漏洩するのを避けるために、適
Let's EncryptのルートCA期限切れで OpenSSL 1.0.2が思わぬ事故を起こす件
これは、Let's Encryptを支えるこの二人のルートCAと OpenSSLの物語である。 DST Root CA X3 (2000-2021) ISRG Root X1 (2015-2035) 〜2021年1月〜 ISRG Root X1「いままで一緒にやってきたDST Root CA X3さんの寿命が間近・・・このままだと僕を信頼してくれていないベテランの（具体的にいうと2016年くらいまでの）古いクライアントたちは Let's Encryptさんを信用してくれなくなっちゃう・・・どうしよう」 DST Root CA X3「どれ、わしが死ぬ前に(有効期限が切れる前に)お前が信頼に値する旨を一筆書いて残せばいいじゃろう。サラサラ」 Issuer: O = Digital Signature Trust Co., CN = DST Root CA X3 Validity Not Bef
China's Great Cannon
By Bill Marczak1, 2, 3, Nicholas Weaver2, 3, Jakub Dalek1, Roya Ensafi4, David Fifield3, Sarah McKune1, Arn Rey, John Scott-Railton1, Ron Deibert1, and Vern Paxson2, 3 [1] Citizen Lab, Munk School of Global Affairs, University of Toronto [2] International Computer Science Institute [3] University of California, Berkeley [4] Princeton University April 10, 2015 This post describes our analysis of Ch
世界最小のRSA鍵ペアは何bitか - hnwの日記
「理論上最短のRSA鍵の鍵長は何ビットなのか？」という疑問が湧いてきたので、RSA鍵の長さに関する制約について調べてみました。とにかく小さいRSA鍵ペアを作ろうと思ったらp=3,q=5の4bit RSA鍵というのが作れそうですが、本当にそんな鍵が作れるのでしょうか？ 本稿ではRSA暗号およびRSA署名のパディングに関する仕組みを紹介し、最短の鍵長となるRSA鍵について検討します。 RSAES-PKCS1-v1_5 におけるパディング 鍵長最短となるRSA鍵ペアを作る上で障害になるのが、RSA暗号のパディングと呼ばれる仕組みです。 RSA暗号における暗号化および復号処理は整数の累乗演算ですから、仮に平文mが1だった場合、暗号文も1ということになってしまい暗号として機能しなくなってしまいます。このような問題への対策として、受け取った平文をそのまま使うのではなく、パディング文字列を付加して暗号化
TLS1.3とは何か？
Dataplexとdbt-osmosisを活用した「がんばらない」データカタログとメタデータ管理の運用(Data Engineering Study #22)
「指紋データを盗まれても指紋は変更できない」問題に悩むセキュリティ業界
関連キーワード CIO | 暗号化 | エンドポイントセキュリティ | 指紋認証 | 情報流出 | セキュリティ | セキュリティリスク | 生体認証 米政府人事管理局（OPM）が発表したニュースリリース《クリックで拡大》 私たちの指紋は完全に自分だけのものである。だが、それが違っていたらどうだろうか。 米政府人事管理局（OPM）で発生した大規模な情報漏えいにより560万個の指紋が盗まれた事件が最近のニュースで取り上げられていた。この事件は、私たちの指先にある一意の識別子である指紋を他人が保持している可能性を示唆している。これは企業にとってどのような意味を持つのだろうか。 セキュリティの専門家が指摘するように、生体認証の不変性は、最高の資産であると同時に最大の課題でもある。指紋、網膜、声紋は、パスワードのように交換することができない。つまり、一度悪用されると正常な状態に戻すのは困難だ。 併
Browserleaks - Check your browser for privacy leaks
BrowserLeaks is a suite of tools that offers a range of tests to evaluate the security and privacy of your web browser. These tests focus on identifying ways in which websites may leak your real IP address, collect information about your device, and perform a browser fingerprinting. By understanding these risks, you can take appropriate steps to protect your online privacy and minimize your exposu
前方秘匿性 (forward secrecy) をもつウェブサイトの正しい設定方法
前方秘匿性（forward secrecy）とは、以下のような性質を指します。 公開鍵暗号の秘密鍵のように、比較的長期に渡って使われる鍵が漏えいしたときでも、それまで通信していた暗号文が解読されないという性質 鍵が漏れることも想定せよ――クラウド時代における「楕円曲線暗号」の必然性 - @IT 鍵が攻撃者や諜報機関など第三者の知るところとなった場合でも、それまで通信していた暗号文が解読されないようにしないといけない、という考え方とともに、最近 HTTPS を利用するウェブサイトにおいても導入が求められるようになってきた概念です。 前方秘匿性を満たすウェブサイトの設定方法については、TLSの暗号化方式をECDH_RSAあるいはECDHE_RSAに設定すれば良い、と述べている文献が多いです。 ですが、ほとんどのウェブサーバにおいて、それは誤りです。 なぜか。 通信を暗号化する鍵（セッション鍵）
TLS暗号設定ガイドライン 安全なウェブサイトのために（暗号設定対策編） | 情報セキュリティ | IPA 独立行政法人 情報処理推進機構
「TLS暗号設定ガイドライン」は、TLSサーバの構築者や運営者が適切なセキュリティを考慮した暗号設定ができるようにするためのガイドラインです。「様々な利用上の判断材料も加味した合理的な根拠」を重視して、TLS通信での実現すべき安全性と必要となる相互接続性とのトレードオフを考慮した3つの設定基準（「高セキュリティ型」「推奨セキュリティ型」「セキュリティ例外型」）を設けており、各々の設定基準に対応して、TLSサーバで設定すべき具体的な要求設定（「遵守項目」と「推奨項目」）を決めております。 本ガイドラインは安全なウェブサイトの作り方とともに適切な暗号設定をする資料の一つとしてお使いいただけます。 なお、本ガイドラインは、暗号技術評価プロジェクトCRYPTRECで作成されました。 「TLS暗号設定ガイドライン」の内容 1章と2章は、本ガイドラインの目的やSSL/TLSについての技術的な基礎知識を
「君は新人だから知らないと思うけどセッション変数が改竄されることもある。その対策は安全ではない」
noon @n00nw0rks 日本人はリスク管理ができない、リスクはゼロにできないということを受容れられない、とよく言われるけど、日本人だからどうこうというより、リスクを管理できるだけの知識と論理的思考能力がない人は「怯える＝意識高い」と考えているんだと思っていて、その話のたびに前の会社のことを思い出す 2014-11-13 11:12:30 noon @n00nw0rks 前の会社でCSRF発見して「hiddenなinputとセッション変数にランダムトークンを保存して照合し正当なページからのリクエストか判別する」のを提案したら「君は新人だから知らないと思うけどセッション変数が改竄されることもある。その対策は安全ではない」と呆れた顔で言われて、 2014-11-13 11:12:50 noon @n00nw0rks 確かにOSやミドルウェアに脆弱性があればそういうこともあるかもだけど、セ
NICTが脆弱なSSLサーバの検出システム「XPIA」を開発、分布を特定
NICTが脆弱なSSLサーバの検出システム「XPIA」を開発、分布を特定：「共通の秘密鍵」を生み出さない、適切な乱数生成モジュールの利用を 情報通信研究機構（NICT）は2013年10月22日、Secure Socket Layer（SSL）の脆弱性を検証するシステム「XPIA」を開発したことを明らかにした。 情報通信研究機構（NICT）は2013年10月22日、Secure Socket Layer（SSL）の脆弱性を検証するシステム「X.509 certificate Public-key Investigation and Analysis system（XPIA）」を開発したことを明らかにした。 XPIAは、SSLサーバが暗号化通信に利用しているX.509電子証明書からRSA公開鍵の情報を抽出し、脆弱性が存在しないかどうかを検証するシステムだ。XPIAでは、共通の秘密鍵を有しており
New community features for Google Chat and an update on Currents
Join the official community for Google Workspace administrators In the Google Cloud Community, connect with Googlers and other Google Workspace admins like yourself. Participate in product discussions, check out the Community Articles, and learn tips and tricks that will make your work and life easier. Be the first to know what's happening with Google Workspace. ______________ Learn about more Goo
技術解説：「DNS Reflector Attacks（DNSリフレクター攻撃）」について
--------------------------------------------------------------------- ■技術解説：「DNS Reflector Attacks（DNSリフレクター攻撃）」について 株式会社日本レジストリサービス（JPRS） 初版作成 2013/04/18（Thu） --------------------------------------------------------------------- ▼はじめに 2013年3月16日（協定世界時）[CISCO2013]から3月下旬にかけ、迷惑メール 対策の活動を進めている国際組織The Spamhaus Projectに対する攻撃に端を 発する、大規模かつ長期間にわたる分散サービス不能（DDoS）攻撃が発生し ました。 今回の攻撃ではこれまでで最大規模となる300Gbps以上のトラフィ
NIST Selects Winner of Secure Hash Algorithm (SHA-3) Competition
The National Institute of Standards and Technology (NIST) today announced the winner of its five-year competition to select a new cryptographic hash algorithm, one of the fundamental tools of modern information security. The winning algorithm, Keccak (pronounced "catch-ack"), was created by Guido Bertoni, Joan Daemen and Gilles Van Assche of STMicroelectronics and Michaël Peeters of NXP Semiconduc
Facebookのメッセージは送信者を自由に偽装して送れることが判明
これちょっとマズいんじゃないかなあ。 Kampa! の人である佐田さんが見つけて教えてくれたんだけど、 Facebook のメッセージは割と簡単に他人になりすまして送れるみたい。 以下、すべて送信者と受信者の自発的な協力を得て試してみた結果です。 起きること Facebook ではユーザーに @facebook.com のメールアドレスが与えられています。 個人ページが www.facebook.com/namaewo の人なら namaewo@facebook.com という具合に。 そのアドレス宛にメールを送ると、 アドレスの所有者に Facebook 上のメッセージとして届きますね。 この時、そのメールの送信元メールアドレスが 別の Facebook ユーザーによって登録されているアドレスであった場合 Facebook では、そのユーザーから送られたメッセージとして扱われます。 電子
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
セキュリティ診断・検査のGMOサイバーセキュリティ byイエラエ
iptables で確立済みのinboundの通信を許可する - うまいぼうぶろぐ
https://groups.google.com/forum/#!topic/play-framework/9KIUwWBjudQ
Engadget | Technology News & Reviews
JVNTA12-240A: Oracle Java 7 に脆弱性