パスキーに入門してみた話 - Qiita
久しぶりの投稿です。 はじめに 昨今、様々なサイトがどんどんパスキーに対応しはじめてきました。 まだまだパスキーがデフォルトになっていくには時間が掛かりそうですが、どのような仕組みでパスキーを実装するのか、早めにキャッチアップしておくのも悪くないと思い、パスキーについて色々と調べてみました。 パスキーとは？ パスワードの代わりに、自分の持つデバイスによる生体認証やパターンを用いて認証を行う方法のことです。 次世代認証技術であるFIDO（Fast IDentity Onlineの略で、「ファイド」と呼びます）を使った認証方式（詳細は後述）で、Apple、Google、MicrosoftがFIDOを普及させるために命名したブランド名になります。 FIDOとは？ 脆弱なパスワードは安全ではありません。 2段階・2要素認証を採用してもそれを有効にするユーザーは少なく、昨今では2段階認証を突破する攻
やはりお前らの「公開鍵暗号」はまちがっている。
※タイトルの元ネタは以下の作品です。 はじめに この記事は、公開鍵暗号の全体感を正しく理解するためのものです。数学的な部分や具体的なアルゴリズムは説明しません。気になる方は最後に紹介するオススメ書籍をご覧ください。 少し長いですが、図が多いだけで文字数はそこまで多くありません。また、専門的な言葉はなるべく使わないようにしています。 ただしSSHやTLSといった通信プロトコルの名称が登場します。知らない方は、通信内容の暗号化や通信相手の認証（本人確認）をするためのプロトコルだと理解して読み進めてください。 公開鍵暗号の前に：暗号技術とは 公開鍵暗号は暗号技術の一部です。暗号と聞くと、以下のようなものを想像するかもしれません。 これは情報の機密性を守るための「暗号化」という技術ですが、実は「暗号技術」と言った場合にはもっと広い意味を持ちます。まずはこれを受けて入れてください。 念のため補足して
RSA署名を正しく理解する
初めに 「署名とはメッセージのハッシュ値を秘密鍵で暗号化したものであり、検証は署名を公開鍵で復号してハッシュ値と等しいかを確認することである」という説明(×)をよく見かけます。 正しい署名の定義と実際のRSA署名がどのようなものであり、上記説明(×)がなぜよくないのかを理解しましょう。 署名の定義 署名の解説は署名の概要でも解説しましたが、再掲します。 署名（方式）は鍵生成（KeyGen）、署名（Sign）、検証（Verify）の3個のアルゴリズムからなります。 KeyGenではアリスが署名鍵sと検証鍵Sを生成します。署名鍵sは自分だけの秘密の値なので秘密鍵、検証鍵Sは他人に渡して使ってもらう鍵なので公開鍵ともいいます。 Signは署名したいデータmに対して署名鍵sを使って署名と呼ばれるデータσを作ります。 データmと署名σのペアを他人（ボブ）に渡します。 Verifyはボブが検証鍵Sを使
本番環境で実践したいAWSセキュリティのベストプラクティス26選
本文の内容は、2022年8月29日にAlejandro Villanuevaが投稿したブログ(https://sysdig.com/blog/26-aws-security-best-practices/)を元に日本語に翻訳・再構成した内容となっております。 Well-architected フレームワークの最も重要な柱の1つは、セキュリティです。したがって、AWSセキュリティベストプラクティスに従って、不測なセキュリティの事態を防止することが重要です。 さて、あなたは問題を解決するために、ソリューションを構築してホストする目的でAWSに着目しました。アカウントを作成し、コーヒーを淹れてワークステーションに座り、設計、コーディング、ビルド、デプロイをする準備はすべて整いました。しかし、そうではありません。 ソリューションの運用性、安全性、信頼性、パフォーマンス、費用対効果を高めるには、多く
SPA認証トークンはlocalStorageでもCookieでもない、Auth0方式はいいねというお話 - @mizumotokのブログ
SPA認証トークンをどこに保存するかは論争が絶えません。localStorageやCookieがよく使われますが、Auth0は違う方法を採用しています。この記事では、Auth0のトークン管理の方式を理解でき、トークン管理上のセキュリティへの理解を深めることができます。 SPAの認証トークンをどこに保存するか ブラウザでトークンを保存できる場所 保存場所の比較 メリット・デメリット Auth0のアプローチ トークンはインメモリに保存 OpenID Connect準拠とトークン取得のUI/UXの悪化回避を両立 Auth0のjsライブラリ ログイン アクセストークンの（再）取得 図解 ログイン アクセストークンの（再）取得 自サービス内の認証だけのもっと簡易な構成 ログイン IDトークン取得 まとめ SPAの認証トークンをどこに保存するか React やVueで認証付きSPA（Single Pa
攻撃して学ぶJWT【ハンズオンあり】 - Money Forward Developers Blog
こんにちは。 マネーフォワードの新卒Railsエンジニア、きなこ と申します。 マネーフォワードX という組織で、日々プロダクトの開発に勤しんでおります😊 突然ですが皆さんは JWT という技術をご存知でしょうか？ 私は趣味でCTFというセキュリティコンテストに出場するのですが、最近ホットだと感じるのがJWTに関連する攻撃です。 今年の1月に初めてJWTを題材にした問題に遭遇し、その後JWTの出題頻度が強まっていると感じ、社内に向けてJWTにまつわる攻撃を通して学ぶための記事を書いたところ、たくさんの反応をいただきました。 今回の記事はその内容を社外向けにアレンジし、ハンズオンを通して実際にJWTを改竄し、受け取るAPIを攻撃することでJWT自体を学べるようにしたものです。 本記事はJWTに興味があるWeb開発者を想定していますが、そうでない方も楽しんでいただけるようにハンズオンを用意し
セキュリティエンジニアが本気でオススメする開発者向けコンテンツ 20選 - Flatt Security Blog
画像出典: 書籍...記事中に掲載した販売ページ / Webサイト...スクリーンショット はじめに こんにちは。株式会社Flatt Securityの @toyojuni です。 突然ですが、弊社Flatt Securityは「開発者に寄り添ったセキュリティ」を標榜しています。Webアプリケーションなどに脆弱性がないか調査する 「セキュリティ診断」 においても、セキュアコーディング学習プラットフォーム 「KENRO」 においても、いかに開発者フレンドリーなサービスを提供できるかという点を大事にしています。 そんな弊社はお客様からさまざまな開発におけるセキュリティのアドバイスを求められることも多いのですが、その中で「開発に役に立つセキュリティ」という切り口では、なかなかまとまっているリファレンス集がないという課題に気付かされました。 そこで、社内でアンケートを実施して「開発者にオススメのセ
WebアプリケーションでJWTをセッションに使う際の保存先は（自分なりに説明できれば）どちらでもよいと思います - 日々量産
以下のツイートを読んで気持ちが昂ったので。 みんな、もうSNSでいがみ合うのはやめよう。 平和に好きなJWTの話でもしようよ。 JWTの格納場所はlocalStorageとCookieのどっちが好き？— 徳丸 浩 (@ockeghem) 2022年2月11日 というのも、JWTをセッションに使うときに保存先含めて一時期悩んでいたので、その時の自分の解。 ただ、考えるたびに変化しているので、変わるのかもしれない。 要約 タイトル。 あとは優秀な方々が既に色々考えておられるのでそちらを読むとよいでしょう。 SPAセキュリティ入門～PHP Conference Japan 2021 JWT カテゴリーの記事一覧 - r-weblife どうしてリスクアセスメントせずに JWT をセッションに使っちゃうわけ？ - co3k.org JWT形式を採用したChatWorkのアクセストークンについて -
ハッシュ関数「SHA-256」の計算プロセスをわかりやすく視覚化してくれる「Sha256 Algorithm Explained」
アメリカの国家安全保障局(NSA)によって開発された「SHA-2」は電子署名やブロックチェーンに応用される暗号学的ハッシュ関数の1つです。そのSHA-2の中でも特に使われているSHA-256でハッシュを生成するための計算プロセスがよくわかるサイト「Sha256 Algorithm Explained」を、Domingo Martin氏が公開しています。 Sha256 Algorithm Explained https://sha256algorithm.com/ Sha256 Algorithm Explainedにアクセスするとこんな感じ。 上部にある入力欄に、好きな文字列を入力します。今回はGIGAZINEのURLである「https://gigazine.net/」を入力してみました。すると、入力したURLをバイナリに変換したメッセージブロックが表示されます。メッセージブロックは32b
君のセキュリティはデプロイするまでもなく間違っている #CICD2021 / CICD Conference 2021
CI/CD Conference 2021 で使用したスライドです。 S3 オブジェクトを不必要に公開してしまったり、あるいは遮断されるべきネットワークが繋がってしまったりといったセキュリティ上の設定ミスは、可能な限り避けたいものです。 このようなインフラ層に対するテストを従来の CI/CD の一部として組み込む場合、「個別の設定項目が条件を満たすことを確認する」または「実際にデプロイした環境に対してアクセスしてみる」といった形でテストを行うことが一般的でしょう。 しかしセキュリティ設定には、「複数の設定項目が絡み合った結果、最終的なアクセス可否が定まる」かつ「実際にデプロイする前に影響範囲を知りたい」といった要求があり、上にあげたテストの形式とはあまり相性が良くないのが事実です。 この問題に対して有効な手法の一つが Automated Reasoning です。Automated Rea
え、HTTPSの転送なのにファイルも暗号化するんですか？？？
TL;DR 基本的には二重での暗号は不要 ただし、転送後も暗号化したまま使うなら、転送前から暗号化するのは良い ルールXを無邪気に追加して不整合のあるセキュリティルールを作ってはいけない はじめに 社内のセキュリティルールやスタンダードを決めるときに、HTTPSなのにVPN必須になってたりファイル暗号も必須になってたりするケースたまに見ます。今回は、それは実際に必要なことなのか？ セキュリティ的に有効なのか？ という点で考察をしていきたいと思います。 背景 二重三重に暗号化しても性能ペナルティが無いなら「なんとなく安全そうだから」でOKにしてしまいがちなのですが、これはよく考える必要があります。 というのも 「ルールXを追加することで既存のルールAと不整合が出る」 ってことは割とよくあるからです。具体的には「SCPのファイル転送は（SCPのセキュリティに不備があった時の）安全性のためにファ
冴えないAWS環境の育てかた α | DevelopersIO
中山です ソリューションアーキテクトとして、AWS環境の利活用をお手伝いするお仕事をしています。 まれによく見るAWS環境 とりあえずこれを見てほしい。 これが絶対にだめと言いたいわけではないです。 一時的な検証環境だったり、とにかくスピード重視でサービスをデリバリーさせる必要があったり、サービスの提供者側が何ら責任を負わない・障害時のビジネスインパクトが無い（そんな状況あるのか？）という前提があったり、状況次第ではこれで十分な時もあると思います。 しかし、一般的な業務システムやサービスの場合にはいろんな意味で不十分でしょう。 では、このような環境をどのように育てていくとよいでしょうか。 この記事では、そんな育てかたの一例を紹介していきたいと思います。 なお、本記事はくっそ長いです。 ちなみに、最終的にはこうなります。 文字が小さすぎて読めない！ ちょっとそこのハ○キルーペ貸してくれーｗ
ちょっとでもセキュリティに自信がないなら、 Firebase Authentication を検討しよう
note のやらかしのあのへんについて。 認証自作、 Rails 、 Devise - Diary パーフェクト Rails 著者が解説する devise の現代的なユーザー認証のモデル構成について - joker1007’s diary 認証サーバーの実装は本質的に難しいです。セキュリティが絡むものは「簡単な実装」などなく、プロアマ個人法人問わず、個人情報を守るという点で、同じ水準を要求されます。悪意あるハッカーは常にカモを探していて、もし認証が破られた場合、自分だけではなく大多数に迷惑が掛かります。初心者だから免責されるといったこともありません。全員が同じ土俵に立たされています。 とはいえ、認証基盤を作らないといろんなサービスが成立しません。そういうときにどうするか。 Firebase Authentication で、タイトルの件なんですが、 Firebase Authenticat
ウェブサイトに仕込まれたマルウェアを何者かが無害なGIFアニメに置き換えていることが判明
非常に感染力・拡散力が高く、PCにダウンロードされることでさまざまなマルウェア感染を引き起こす「Emotet」は近年、その被害の大きさから問題視されています。このEmotetのマルウェアファイルが、何者かに無害なGIFアニメーションへと置き換えられているという報告があがっています。 Emotet being hijacked by another actor | by Kevin Beaumont | Jul, 2020 | DoublePulsar https://doublepulsar.com/emotet-being-hijacked-by-another-actor-b22414352a7b A vigilante is sabotaging the Emotet botnet by replacing malware payloads with GIFs | ZDNet htt
IPv6アドレススキャン攻撃:Geekなぺーじ
IPv4では、アドレススキャン攻撃やポートスキャン攻撃は日常的に行われています。 ファイアウォールなしの状態でグローバルIPv4アドレスに接続していれば、すぐに攻撃を観測できます。 IPv6でもアドレススキャン攻撃は発生しています。私の家のネットワークでも、IPv6でのアドレススキャン狙いと推測されるトラフィックを簡単に観測できました。 ただ、いまのところ、私の家では、実際に利用しているIPv6アドレスを外部から発見できているようなスキャンの形跡を発見できておらず、主にステートフルDHCPv6や手動設定でのIPv6アドレスを探しているように見えました。 やはり、IPv4と比べると、IPv6の方がIPv6アドレススキャン攻撃の難易度は高いのだろうと思います。 ということで、IPv6でのアドレススキャン攻撃や、その他方法によって、稼働しているIPv6アドレスをどのように探すのかに関して解説して
正しいウェブページの代わりにエラーページを強制表示させる新型サイバー攻撃「CPDoS」が発見される
ケルン工科大学の研究チームが、コンテンツ・デリバリ・ネットワーク(CDN)で配信されているウェブページの代わりにエラーページを強制的に表示させる新型のサイバー攻撃「Cache Poisoned Denial of Service(キャッシュ汚染型DoS攻撃、CPDoS)」の存在を明らかにしました。 CPDoS: Cache Poisoned Denial of Service https://cpdos.org/ CDNは、ウェブ上で表示されるコンテンツのデータ(キャッシュ)を世界中のサーバー上に分散させ、ユーザーが地理的に近い場所に存在するサーバーからデータにアクセスすることが可能にすることで、データ転送を高速化・安定化させるというシステムです。CDNはデータがサーバー上に分散して保存されるため、元のサーバーがダウンしていても別のサーバーからデータにアクセスできようになります。 そんなC
CSRF is (really) dead
Scott Helme Security researcher, entrepreneur and international speaker who specialises in web technologies. More posts by Scott Helme. A little while back I wrote a blog post about how "CSRF is dead". It focused on SameSite cookies, a powerful yet simple feature to protect your website against CSRF attacks. As powerful as it was, and as much as it will kill CSRF, you had to enable it on your site
楕円曲線暗号アルゴリズムを理解する｜TechRacho by BPS株式会社
お久しぶりです。yoshiです。みなさん、夏を満喫していますか？ 私は溶けそうです。日本の夏はとってもあつい。 覚えている方がいるかどうかは分かりませんが、以前私はRSA公開鍵暗号アルゴリズムを理解するという記事を書きました。今回はその続編（？）です。 楕円曲線について 楕円曲線、という言葉を事前知識無しで見ると、 多分こんな画像が脳裏に浮かぶと思います。違います。 楕円曲線の楕円は楕円積分から現れた言葉で、楕円積分は文字通り楕円の弧長などを求める方法なので全くの無関係とは言えませんが、少なくとも楕円曲線と楕円は別の図形です。楕円のことは忘れましょう。 実際の楕円曲線は、例を示すと以下のような曲線です。 一般化すると (ただし または ) という式で表されるこのような曲線をワイエルシュトラス型楕円曲線と呼びます。ワイエルシュトラス型、と付いているのは他のパターンもあるからで、 こんな形の楕
SSRF攻撃によるCapital Oneの個人情報流出についてまとめてみた - piyolog
2019年7月29日、米金融大手 Capital Oneは不正アクセスにより1億人を超える個人情報が流出したと発表しました。WAFの設定ミスに起因して、Server Side Request Forgery（SSRF）攻撃を許したことにより情報を盗まれたと見られています。ここでは関連する情報をまとめます。 Capital Oneによる公式発表 Information on the Capital One Cyber Incident（米国向け） Information on the Capital One Cyber Incident（カナダ向け） Frequently Asked Questions （１）影響範囲 影響が及んだ人数の内訳は以下の通り。 米国 約1億人 カナダ 約600万人 発表時点でCapital Oneは流出した情報が外部へ出回ることや、詐欺への使用は確認していない。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
本当にあった怖い脆弱性の話
