とほほのOpenID Connect入門 - とほほのWWW入門
OpenID Connectとは 用語 OpenID Connectを試してみる OP側の準備 - AWS Cognito ユーザープールと最初のクライアントを作成する 作成されたパラメータを確認する ディスカバリ ユーザープールにユーザを追加する RP側の準備 - Pythonアプリ 実施 認証の流れ ログインする トークンをリフレッシュする トークンを失効させる ログアウトする IDトークンの形式 リンク OpenID Connectとは SSO(シングルサインオン)を実現するプロトコルのひとつです。 例えば、食べログ に Google アカウントでログインすることができますが、ここでも OpenID Connect が使用されています。 OIDC と略されることもあります。 類似の仕様に OpenID 2.0 がありましたが、OpenID 2.0 の進化系が OpenID Conne
オープンなAmazon Cognitoエミュレーター "Magnito" のご紹介
はじめに こんにちは。かる(@caru)です！ 大学生として勉強する傍ら、日々フロントエンドエンジニアを目指して活動しています。今回は、私がコミッターとして参加しているMagnitoというOSSプロジェクトについて紹介します。 皆さんは、AWSのCognitoというサービスを知っていますか？ スマホアプリからWebアプリまで、多くのアプリケーションで認証・認可の機能は不可欠です。その中でも、Amazon Cognitoは多くの開発者に利用されている認証・認可サービスの一つです。この記事では、Cognitoを使う際の課題と、Magnitoがそれにどう対応するかを紹介します。 Amazon Cognitoとは Amazon Cognitoは、Amazon Web Serviceが提供するユーザー認証、認可、およびユーザー管理を簡単にするためのサービスです。これにより、アプリケーションにユーザー
OpenSSHの脆弱性 CVE-2024-6387についてまとめてみた - piyolog
2024年7月1日、OpenSSHの開発チームは深刻な脆弱性 CVE-2024-6387 が確認されたとしてセキュリティ情報を発出し、脆弱性を修正したバージョンを公開しました。この脆弱性を発見したQualysによれば、既定設定で構成されたsshdが影響を受けるとされ、影響を受けるとみられるインターネット接続可能なホストが多数稼動している状況にあると報告しています。ここでは関連する情報をまとめます。 概要 深刻な脆弱性が確認されたのはOpenSSHサーバー（sshd）コンポーネント。脆弱性を悪用された場合、特権でリモートから認証なしの任意コード実行をされる恐れがある。 悪用にかかる報告などは公表時点でされていないが、glibcベースのLinuxにおいて攻撃が成功することが既に実証がされている。発見者のQualysはこの脆弱性の実証コードを公開しない方針としているが、インターネット上ではPoC
「AWSセキュリティを「日本語で」学習していくための良いコンテンツをまとめてみた」というタイトルでAWS Summit Japan 2024のCommunity Stageで登壇しました #AWSSummit | DevelopersIO
「AWSセキュリティを「日本語で」学習していくための良いコンテンツをまとめてみた」というタイトルでAWS Summit Japan 2024のCommunity Stageで登壇しました #AWSSummit AWS Summit JapanのCommunity Stageで登壇した「AWSセキュリティを「日本語で」学習していくための良いコンテンツをまとめてみた」の解説です。 こんにちは、臼田です。 みなさん、AWSセキュリティの勉強してますか？(挨拶 今回はAWS Summit JapanのCommunity Stageで登壇した内容の解説です。 資料 解説 AWSとセキュリティの勉強をしていく時、嬉しいことにAWS関連の情報はたくさんあります。しかし、どの情報から勉強していくか迷いますよね？そこで、AWS Security Heroである私がオススメする「日本語で」学習するための良いA
[令和5年最新][備忘録]YubikeyでSSH
YubikeyでSSHする方法は4種類 メリデメとかは公式参照 Securing SSH with the YubiKey PIV PGP FIDO2 OTP FIDO2が比較的新しい OpenSSH 8.2 (was released on 2020-02-14) で追加されたらしく、それ以前のブログ等を読むとPIVでSSHする方法しか書かれていない。 FIDO2はクライアントとサーバー両方の対応が必要で対応しているサービスが少ないっぽい。GitHubがFIDO2のSSHに対応したのは2021年5月 GitHubの推しはFIDO2っぽい GitHubのドキュメントには、FIDO2を使った方法が書かれているので、盲目的にこれを使ってみることにした。 $ ssh-keygen -t ed25519-sk -C "YOUR_EMAIL" -sk がセキュリティキーを使用した鍵生成 ecdsa-
![[令和5年最新][備忘録]YubikeyでSSH](https://cdn-ak-scissors.b.st-hatena.com/image/square/7a5ea440d5ef1a0ffbcf94e78d7ca3852f973032/height=288;version=1;width=512/https%3A%2F%2Fres.cloudinary.com%2Fzenn%2Fimage%2Fupload%2Fs--wDVoJ88h--%2Fc_fit%252Cg_north_west%252Cl_text%3Anotosansjp-medium.otf_55%3A%25255B%2525E4%2525BB%2525A4%2525E5%252592%25258C5%2525E5%2525B9%2525B4%2525E6%25259C%252580%2525E6%252596%2525B0%25255D%25255B%2525E5%252582%252599%2525E5%2525BF%252598%2525E9%25258C%2525B2%25255DYubikey%2525E3%252581%2525A7SSH%252Cw_1010%252Cx_90%252Cy_100%2Fg_south_west%252Cl_text%3Anotosansjp-medium.otf_37%3Adyoshimitsu%252Cx_203%252Cy_121%2Fg_south_west%252Ch_90%252Cl_fetch%3AaHR0cHM6Ly9saDMuZ29vZ2xldXNlcmNvbnRlbnQuY29tL2EtL0FPaDE0R2hqNjRPbGFJb05Kd2loRHVsUENLT3VpSzZXdjhwLWgtZlpQd3dNS1E9czI1MC1j%252Cr_max%252Cw_90%252Cx_87%252Cy_95%2Fv1627283836%2Fdefault%2Fog-base-w1200-v2.png)
GitHub - chaifeng/ufw-docker: To fix the Docker and UFW security flaw without disabling iptables
UFW is a popular iptables front end on Ubuntu that makes it easy to manage firewall rules. But when Docker is installed, Docker bypass the UFW rules and the published ports can be accessed from outside. The issue is: UFW is enabled on a server that provides external services, and all incoming connections that are not allowed are blocked by default. Run a Docker container on the server and use the
Docker と iptables — Docker-docs-ja 24.0 ドキュメント
Linux 上では、 Docker は ネットワークの分離(network isolation) のために iptables ルールを操作します。これは実装の詳細であり、 Docker が追加する iptables ポリシーを変更すべきではありません。しかしながら、 Docker によって管理されている追加されたポリシーを、自分自身で変更したい場合には、いくつかの影響が発生する可能性があります。 Docker を実行しているホストをインターネット上に公開している場合、コンテナやホスト上で実行しているサービスに対する許可のない接続を防ぐように、おそらく何らかの iptables ポリシーを追加しようとするでしょう。これをどのようにして行うか、そして、気を付けるべき警告について、このページで扱います。 iptables ポリシーは Docker 用ルールの前に追加¶ Docker は2つのカス
第798回 Ubuntuのセキュリティを支えるAppArmor入門 | gihyo.jp
Ubuntuではセキュリティ対策の一環としてAppArmorを採用しています。AppArmorを使えば、任意のプログラムに対して、意図しないファイルやデバイスのアクセスを阻害したり、サブプロセスに対するセキュリティ制約をかけたりできます。今回はあまり意識することのないものの、知っておくといつか役に立つかもしれない、実際に役に立つ時はあまり来てほしくないAppArmorについて紹介しましょう。 AppArmorとMACとLSMと 「AppArmor」は「名前ベースの強制アクセス制御で、LSMを用いて実装されている仕組み」と紹介されることがあります。これはどういう意味でしょうか。 まずはAppArmorの特徴となる「名前ベース（もしくはパス名ベース）」についてですが、これは「セキュリティ設定を対象となるファイルパスを元に設定する」ことを意味します。つまりファイルパスごとに、何を許可し何を許可し
GitHub - uBlockOrigin/uBOL-home: uBO Lite home (MV3)
uBO Lite (uBOL), a permission-less MV3 API-based content blocker. uBOL is entirely declarative, meaning there is no need for a permanent uBOL process for the filtering to occur, and CSS/JS injection-based content filtering is performed reliably by the browser itself rather than by the extension. This means that uBOL itself does not consume CPU/memory resources while content blocking is ongoing --
パスワードはおしまい！ 認証はパスキーでやろう
はじめに パスワードは古来より認証に良く使われる方法ですが、その運用の難しさからセキュリティの懸念とその対策としての運用の複雑さ（複雑で長い文字列、90日でパスワード変更など）が要求される大きく問題をもった仕組みです。 その根本的な解決策としてFIDO Allianceを中心に推進されている 「パスワードレス」 が注目されています。これはPINや生体認証とデバイス認証を使ったMFAからなっており、フィッシングやパスワード流出に強い上に、ユーザも複雑なパスワードを覚えなくて良い、という大きなメリットがあります。最近はこの流れでPassKeyというものが登場し、Apple/MS/Googleのプラットフォーマが対応したことで、本格運用に乗せれるフェーズになってきました。というわけで以下に解説動画を作ったのですが、動画中で時間の都合で触れきれなかったところや、JavaScriptによる実装のサン
パスキーとID連携の認証フローの共通点から見る認証技術の基本
ritou です。 少し前にパスキーとID連携の関係を考えるときにこういう観点があるよという話をしずかな方に書きました。 今回は、ログインに利用しようとした時のフローの中でここ似ているよね、こんな意図があるんだよっていう部分を取り上げます。 認証フローの似ている点 登場人物をUserAgent、RP、Authenticatorとして、あらゆるところを簡略化したシーケンスを用意しました。 ID連携、いわゆるソーシャルログインでは次のようになります。 登場人物をUserAgent、RP、IdPとするとこんな感じでしょう。 もちろん細かいところは違うわけですが、全体の流れは似ています。 WebAuthnのchallenge, OIDCのnonce, state 先ほどのシーケンス、たまたま似ていると言うよりも、これは認証フローにおける基本の流れであると意識しておきましょう。 パスキーやID連携の
Firefox Monitor
Find out if your personal information has been compromisedStay safe with privacy tools from the makers of Firefox that protect you from hackers and companies that publish and sell your personal information. We’ll alert you of any known data breaches, find and remove your exposed info and continually watch for new exposures. Email addressCheck for breaches Why use Firefox Monitor?Identifying an
【雑記】セキュリティガイドライン類 約300時間 読み漁ってみた - 2LoD.sec
23年3月末から勉強時間をガイドライン類の読み込み＆ブログ執筆にあてて7カ月が経ちました。 特に良い区切りでもないのですが、ここらで一度振り返りたいと思います。 なんで読み始めたの？ どれだけ何を読んだの？ 色々読んでどうだった？ 1. 自分の発言に根拠と自信を持てる 2. 未経験の技術テーマでも取り扱いやすくなる 3.トレンドやビッグテーマが分かる おすすめのガイドライン類は？ なんで読み始めたの？ 今更の自己紹介ですが、私は所属組織の中で3 Line of Defenseにおける2nd Lineにおり、セキュリティの戦略立案、強化施策の推進、あるいは新しい技術を利用する際のルール作りを主に担っています。 プログラム開発、サーバ、ネットワーク、クラウド、API、コンテナ、AI、様々な技術テーマがある中で、そのすべてにセキュリティは強く関わります。そして、セキュリティ担当は、現場から上記の
Auth0にPassKeyが搭載されたぞ！！！
はじめに 先日ふと Auth0 のダッシュボードを眺めていると、興味深い項目が表示されていました。 Passkey がある!!! なので、今回は Auth0 に搭載されたパスワードレス認証方式である Passkey の説明をしていきます。 なお、Auth0 の設定方法についてはAuth0 からリリースされた記事を参考にして、記載しています。 パスワード認証の課題 Passkey の説明をするまえに、パスワード認証の課題について見ていきます。 認証方法として当然とされているパスワード認証ですが、以下の 3 つの課題を持っています。 ① パスワードの使い回し ② 推測されやすいパスワードの使用 ③ フィッシングアプリへのパスワード入力 それぞれ見ていきましょう。 ① パスワードの使い回し ログインが必要なアプリにはそれぞれ異なるパスワードを使用するというのは皆さんご存知だとは思います。 とはい
第751回 イマドキのVPSでUbuntuをセキュアに保つ | gihyo.jp
今回はイマドキのVPSであるKAGOYA CLOUD VPSにUbuntuをセットアップし、セキュアに運用する方法を紹介します。とはいえ他のVPSサービスにもそのまま利用できます。 VPS放浪記 筆者は諸般の事情でKAGOYA CLOUD VPSを借りることにしました。 主に動作させるのはNextcloudサーバーです。一般的なVPSサービスのストレージ容量は（プランにもよりますが）100GB程度で、少なく感じていました。しかしKAGOYA CLOUD VPSは大容量プランと称して200GBや400GBのストレージが割安で使用できます。これはいいなと思って契約しました。 筆者が使用したことのあるVPSサービスはこれで3社目ですが、いずれもOSテンプレートとして最新のUbuntu LTS（今だと22.04 LTS）が用意されています。Ubuntu使いとしてはこれを選択するわけですが、3社とも
第778回 Nextcloud Passwordsでログイン情報の記憶をアウトソーシング | gihyo.jp
今回はWebサイトのログイン情報をNextcloudに記憶させる方法を紹介します。 ログイン情報は覚えない 先日、とあるSNSが個人情報を流出させるという事件がありました。それ自体は大変残念なことにしばしば起こっていることですが、個人情報に含まれるパスワードのうち約半数が平文で保存されていたとのことです。 通常パスワードは何らかの方法でハッシュ化されて保存するのがセオリーのはずですが、ユーザーとしてはパスワードの保存方法なんて知る余地がありません。流出した個人情報が販売されたという事実もあるようで、購入した人は当然倫理観なんてあるわけがないのでログインユーザー名とパスワードで他のサービスへのログインを試みるわけです。ログインに成功してクレジットカードの情報が登録されていたりすると、それはもう酷いことになることが容易に予想できます。 このことからわかることは、パスワードは使い回されることが多
NISCと気象庁が使用していたメール関連機器へのサイバー攻撃についてまとめてみた - piyolog
2023年8月4日、内閣サイバーセキュリティセンター(NISC)と気象庁はそれぞれ電子メール関連のシステム・機器から不正通信の痕跡が確認され、メールデータの一部が外部に流出した可能性があると公表しました。ここでは関連する情報をまとめます。 政府組織に対しゼロデイ攻撃 NISCと気象庁及び気象研究所、国立科学博物館、教職員支援機構が各々運用を行っていた電子メール関連システム・機器に脆弱性が存在しており、その脆弱性に関連した不正通信が確認された。 今回確認された不正通信により、メールデータの一部が外部に流出した可能性がある。両組織ではメールアドレス等の個人情報が漏えいした可能性を排除できないとして個人情報保護委員会に報告した他、対象者にも個別に連絡を行う。公表時点では流出可能性のある情報の悪用は確認されていないが、NISCでは約5,000件の個人情報が対象に含まれており、流出可能性のある事案が
Dockerはなぜサイバー攻撃者に狙われやすいのか？
Check Point Software Technologiesはこのほど、「Docker Images: Why are Many Cyber Attacks Originating Here? - Check Point Blog」において、Dockerイメージの危険性について伝えた。Dockerイメージには構築と使用に特有の脆弱性があることから、攻撃者の格好の標的となってしまっている。同社は既知の脆弱性を含む基礎コンポーネントの使用、クラウド環境の動的な性質、簡単な配布方法によって、セキュリティインシデントが引き起こされていると指摘している。 Docker Images: Why are Many Cyber Attacks Originating Here? - Check Point Blog Dockerイメージは攻撃者にとって好ましいターゲットの一つとなっている。一般的にさ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
🛑 You don't need passport.js - Guide to node.js authentication ✌️
GitHub - 99designs/aws-vault: A vault for securely storing and accessing AWS credentials in development environments
