サクサク読めて、
アプリ限定の機能も多数！
アプリで開く
badssl.com 🎛Dashboard Dashboard 🎫Certificate expired wrong.host self-signed untrusted-root revoked pinning-test no-common-name no-subject incomplete-chain sha256 sha384 sha512 1000-sans 10000-sans ecc256 ecc384 rsa2048 rsa4096 rsa8192 extended-validation 🎟ClientCertificateCertificate Downloads client client-cert-missing 🖼Mixed Content mixed-script very mixed mixed-favicon mixed-form ✏️HTTP h
なにやら「公開鍵を公開しない病」なんてのが流行っているらしいですね。 パスポートのセキュリティ – AAABlog https://www.osstech.co.jp/~hamano/posts/epassport-security/ 筆者はNFCを使用してIC旅券の真正性を確認できるAndroidアプリを開発したそうです。 その紹介の中でIC旅券のセキュリティについて、特に公開鍵について段落を分けるほどに熱心に語っています。 公開鍵を公開しない病い (中略) 不開示とした理由 旅券冊子の情報暗号化に関する情報であり，公にすることにより，旅券偽造のリスクが上がる等，犯罪の予防及び公共の安全と秩序の維持に支障を及ぼすおそれ並びに日本国旅券の安全性が損なわれ，法人の円滑な海外渡航に支障を来すことにつながる可能性がある等，旅券事務の適正な遂行に支障を及ぼすおそれがある。 また、当該情報は，国際
Key Reinstallation AttacksBreaking WPA2 by forcing nonce reuse Discovered by Mathy Vanhoef of imec-DistriNet, KU Leuven, 2017 Introduction We discovered serious weaknesses in WPA2, a protocol that secures all modern protectedWi-Finetworks. An attacker within range of a victim can exploit these weaknesses using key reinstallation attacks (KRACKs). Concretely, attackers can use this novel attack
PHPカンファレンス2020での講演資料です。 アジェンダ 誤解1:Cookieは誤解がいっぱい 誤解2: 脆弱性があるページにのみ影響がある 誤解3: 脆弱なECサイトはセキュリティコードを保存している 誤解4:クレジットカードをサイトに保存すると漏洩リスクが高まる 誤解5: ハッシュ値で保存されたパスワードは復元されない 誤解6: 高価なSSL証明書ほど暗号強度が高い 誤解7: TRACEメソッドの有効化は危険な脆弱性である 誤解8: 怪しいサイトを閲覧すると情報が盗まれたりウイルスに感染する 誤解9: イントラのウェブサイトは外部からは攻撃できない 誤解10:セキュリティ情報はウェブで収集する
なんですかこれは！ New attack bypasses HTTPS protection onMacs,Windows, andLinuxDHCP につなぐと PAC ファイルがダウンロードされて HTTPS であろうとアクセス先の Full URL は漏れるですって？ Web Proxy Autodiscovery ですって？ チョットニホンゴデオネガイシマス ってことで、まぁこれが実際どれくらい簡単に実現できる攻撃パターンなのかは他のセキュリティ業界の方々に後で聞くとして、この記事でも触れられてる OpenID Connect とか OAuth2 への影響について、ちょっとまとめておきましょうか。 Authorization Request & Response が漏れる response_mode=form_post なんていうのも一部ありますが、基本 OAuth2 /
みなさんマイナンバーカードはもう手元に届きましたか? 私の住む大田区はとても混雑していて申請から5ヶ月かかって今月やっと交付してもらうことができました。 このカードに含まれる公的個人認証機能は以前から住基カードに入っていたものですが、今年から民間利用もできるようになりました。 しかし、この公的個人認証ですが詳細な仕様が公開されていないため、商用利用しようという動きはまだ聞きませんし、既に動いている行政サービスのe-govやe-taxはIE限定で、いまだにJavaAppletが使われているなど大変残念な状況です。 カードに入っている電子証明書と2048bitのRSA秘密鍵は様々な用途に活用できる可能性があるのに、せっかく税金を費やして作ったシステムが使われないのはもったいないですね。 民間利用の第一歩として、カードに入っているRSA鍵を利用して自宅サーバーにSSHログインしてみましょう!
非公開にしていてもfacebookの検索で自分の携帯番号が他人に知られてしまう可能性がある？ ということがわかったので、注意喚起の意味を込めて記事にまとめました。 ことの発端は知らない番号からショートメッセージが来たこと。 僕がTVに出たということを書いているので迷惑メールでは無いっぽいし、たぶん知人の誰かだろうけど相手がわからない。 そのまま相手に 「あなたは誰ですか？」と聞くのも失礼なので まずは番号をグーグル検索しました。 当然、出ませんよね。 今どきネットに携帯番号を公開している人なんていないので、すべての電話番号を機械的に網羅したページだけが並びます。 そして本題はここから。 何気なしにその時開いていたfacebookの検索ボックスに携帯番号を入れたら、 表示されたのです。 番号の持ち主が。 確かに、少し遠い知り合いでした。 誰なのかわかってよかった。 けれど友達も、共通の友達も
Why “Use bcrypt.” is not the best recommendation (anymore). Preamble: if you’re hashing your passwords with bcrypt / scrypt / PBKDF2 today, there’s nothing to worry about in the immediate future. This article is for you if you’re choosing a password hash today and want a future-proof solution. Not a call for action. The PastFive years ago, the world was asimpler place. You could shame other peopl
0. 簡単なSLOTH攻撃のまとめ 最初に簡単なまとめを書いておきます。長文になりそうなので、読むのが大変な方はここだけ見ておいてください。 MD5ハッシュは既に安全ではなく、証明書の署名方式での利用は停止されていたが、後方互換のためハンドシェイクデータの署名方式にRSA-MD5が今でも利用できるTLS実装が幾つか存在していた(Firefox NSS,Java等)。 先週、INRIAグループからハッシュ衝突を利用して実際にTLSを破る攻撃(SLOTH)が公開された。それを受け、いくつかの実装でRSA-MD5を完全に利用不能にする修正が行われた(CVE-2015-7575)。 SLOTHでは、SHA1やTLS、IKE、SSHに対する攻撃についても評価を行い、幾つかは全く現実的に不可能なレベルではないことが示された。MD5とSHA-1でTLSハンドシェイクの完全性を担保しているTLS1.0/
出会い系サイト運営者と繋がりのある方より直接話を聞くことができました。 文才がないながらも出来るだけ当事者側からの目線で解説したいと思います。 先に言いますが、本件は出会い系サイト自身が被害者でもありますので、「出会い系サイトなんて全部サクラサイトだろ?」みたいな先入観をお持ちの方は一旦捨てて頂くと理解しやすいかと思います。真っ当に運営されている出会い系サイトが被害者です。 まず流出したであろう情報とは何なのか?「残高照会ダイヤル」は、契約者が持つ口座の残高や、通帳に「印字されうる」取引明細も音声で知ることができます。例えば 「27-11-27 振込 フグタマスオ *30,000」 「27-11-30 振込 イソノカツオ *10,000」 このような入出金の取引を、音声で知ることができます。 もちろん契約者(契約団体)自身しかアクセスできないはずの情報なわけですが、この残高照会ダイヤルの操
(訳注：2016/1/5、いただいた翻訳フィードバックを元に記事を修正いたしました。)セキュリティ – 誰もが見て見ぬふりをする問題 。セキュリティが重要だということは、誰もが認識していると思いますが、真剣にとらえている人は少数だと思います。我々、RisingStackは、皆さんに正しいセキュリティチェックを行っていただきたいと考え、チェックリストを用意しました。皆さんのアプリケーションが何千人というユーザやお客様に使用される前にセキュリティチェックを行ってください。 ここに挙げたリストのほとんどは概略的なもので、Node.jsに限らず、全ての言語やフレームワークに適用することができます。ただし、いくつのツールは、Node.js固有のものとなりますので、ご了承ください。 Node.jsセキュリティ に関するブログ記事も投稿してありますので、こちらも是非読んでみてください。 構成管理 HT
先日、OS X Yosemite（10.10）の後継バージョンとして、OS X El Capitan（10.11）がリリースされていますが、ソフトウェアのサポート待ち、あるいは様子見ということでアップグレードをためらっている方も多いのではないでしょうか。 執筆時点でのMac OS Xの最新バージョンは「10.11.1」になっています。ご利用のバージョンがOS X Yosemiteの最新バージョン「10.10.5」であったとしても、セキュリティ上の問題がかなりの件数が未解決ですので、「10.11.1」へのアップデートをご検討ください！ このアップデート「OS X El Capitan v10.11.1 およびセキュリティアップデート 2015-007」の説明を見ると、「スクリプトエディタの脆弱性（CVE-2015-7007）」というセキュリティ上の問題が修正されたことを示す一文が記載されてい
昨年2014年は、SSL（Secure Sockets Layer）とTLS（Transport LayerSecurity）というプロトコルがリリースされてから20年が経過し、HeartBleedやPOODLEなどの脆弱性でも話題となった年でもありました。今回の10分講座では、SSL/TLS暗号通信プロトコルの動向を紹介します。 SSL/TLSとは SSL/TLSは最も普及している暗号通信プロトコルの一つで、TCP/IPの4レイヤーモデルのトランスポート層とアプリケーション層との間に位置するため、広く使われているHTTPばかりでなく、SMTPなど任意のプロトコルを安全に送受信する目的で使用することができます。特にWebにおいて暗号通信機能を提供できるようになったことにより、オンラインショッピング、オンラインバンキングやユーザー認証を必要とする各種オンラインサービスの普及に重要な役割を担
前回は、暗号化の方法について紹介しました。 しかし、元に戻せる方法で保存する以上、何かしらの共通鍵を保持しておく必要があります。 単純にアプリ内の定数として保持しておくと、リバースエンジニアリングに非常に弱いので、多少の工夫が欲しいところです。 ところで、タイトルには反しますが、アプリ内で元に戻せる形でパスワードを保存する以上、本当に安全な方法は存在しません。 簡易的な対策を組み合わせることで、ちょっとした用途なら必要十分なセキュリティを確保するのが目的です。 先に、APKのリバースエンジニアリング方法を簡単にご紹介しておきましょう。 リソース、マニフェスト apktoolが便利です。 インストールしたら、適当なAPKファイルのあるところで apktool d myapp.apk すれば、フォルダに展開されます。リソースやマニフェストは完全に見放題。 ソースコード まず、apkの拡張子を.
Mozilla SSL Configuration Generator Redirecting to the updated SSL Configuration Generator…
1) TLS 1.3 is the latest and most secure version of the TLS protocol for encrypting HTTP communications.It improves performance, efficiency,security, and supports newer encryption algorithms and key derivation functions. 2) TLS 1.3 reduces the number of exchanges needed before encrypted communication begins from three exchanges to one.It also reduces the number of rounds needed for the handshak
「TLS暗号設定ガイドライン」は、TLSサーバの構築者や運営者が適切なセキュリティを考慮した暗号設定ができるようにするためのガイドラインです。「様々な利用上の判断材料も加味した合理的な根拠」を重視して、TLS通信での実現すべき安全性と必要となる相互接続性とのトレードオフを考慮した3つの設定基準（「高セキュリティ型」「推奨セキュリティ型」「セキュリティ例外型」）を設けており、各々の設定基準に対応して、TLSサーバで設定すべき具体的な要求設定（「遵守項目」と「推奨項目」）を決めております。本ガイドラインは安全なウェブサイトの作り方とともに適切な暗号設定をする資料の一つとしてお使いいただけます。 なお、本ガイドラインは、暗号技術評価プロジェクトCRYPTRECで作成されました。 「TLS暗号設定ガイドライン」の内容 1章と2章は、本ガイドラインの目的やSSL/TLSについての技術的な基礎知識を
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
