#Authentication #Security 既知のデータ侵害で利用されたパスワードかどうかを検証できるサービス、API https://haveibeenpwned.com/Passwords

Multi Factor Authentication 多要素認証 #Security #Authentication

#Security #Authentication 一定回数の不正なパスワード入力後にアカウントを一時的または永続的にロックするブルートフォース攻撃対策 主な問題点 DoS攻撃の標的になりやすい（攻撃者が大量のアカウントをロック可能） ユーザー名の列挙が可能（存在するアカウントのみがロックされる） ヘルプデスクへの負担増加 低速攻撃や複数ユーザー対象の攻撃に無効

#Security ゴールドスタンダード（Gold Standard）は、セキュアなシステム設計における基本原則で、C-I-Aを保護する執行メカニズムとして機能します。 認証（Authentication）: ユーザーが本人であることを証明 認可（Authorization）: 認証されたユーザーの行動の許可・拒否を決定 監査（Auditing）: システムアクティビティの信頼できるログを維持 ラテン語で金を意味する「Aurum」の化学記号「Au」に由来し、3つの原則が「Au」で始まることからこの名称が付けられています。 https://designingsecuresoftware.com/text/ch1-gold/

#Team Organization Team Topologiesにて紹介される4つのチームタイプの内の1つ 認証や認可・決済等のサブシステムを構築しストリームアラインドチームにAPIを提供する

#Software Design #Cloud Native The Twelve-Factor Appを現代のクラウドネイティブ環境向けに拡張した方法論。Kevin Hoffmanによって著され、オリジナルの12要因を15要因に拡張している。 追加された3つの新要因 2. API First - サービス設計において、実装前にAPIインターフェースを定義し契約駆動開発を促進 API Architecture 14. Telemetry - メトリクス、ログ、トレースの収集を通じた包括的な監視機能 Observability 15. Authentication and Authorization - 認証・認可をアプリケーション設計の第一級の関心事として組み込む Authentication Authorization 既存要因の改訂 Kubernetes ConfigMap/Secretsなどコンテナ時代の設定管理や、Infrastructure as Code（IaC）による環境構築など、現代的なベストプラクティスを反映した注釈が追加されている。 https://www.vmware.com/docs/ebook-beyond-the-12-factor-app

#Security #Authentication 簡単かつ安価にDV証明書を発行する認証局 https://letsencrypt.org/ja/

#API Architecture #Network 外部トラフィックに対してリバースプロキシ・ロードバランシングが持つようなネットワークのルーティング・セキュリティと可用性の向上に加え、以下のような機能横断的な要件を扱う役割 認証 認可 レートリミット リトライ サーキットブレーカー etc.

#Security #Authentication ブルートフォース攻撃を軽減するための認証ロック機構。ユーザーが正常に認証された後、そのブラウザに発行される特別なCookie 従来のアカウントロックアウトと比較して以下の利点がある DoS攻撃に対して耐性がある IPアドレスではなくブラウザCookieを基準とするため予測可能で実装しやすい ボットネットや代理経由の攻撃に対応しやすい 認証リクエスト時に有効なDevice Cookieの有無を確認し、未信頼クライアント（Device Cookieなし）からの認証試行回数を記録してロックアウトを実施する 実装にはJWT、Redis/Memcachedによるロックリスト管理、HMAC署名による改ざん防止などが用いられる https://owasp.org/www-community/Slow_Down_Online_Guessing_Attacks_with_Device_Cookies

#Security #Authentication #Blog ブルートフォース攻撃を防ぐための対策をまとめたOWASP Communityの記事 主な対策方法 アカウントロックアウト機能（DoS攻撃に悪用されるリスクに注意） Device Cookies（デバイスごとの認証ロック機構、DoS攻撃に対して耐性がある） パスワード検証時の遅延追加 IPアドレスベースのレートリミット CAPTCHAの導入 複数の秘密の質問による認証強化 単一の技術では回避されやすいため、複数の対策を組み合わせることが重要 https://owasp.org/www-community/controls/Blocking_Brute_Force_Attacks

#Security #Authentication 総当たり攻撃。パスワードや暗号鍵などを、可能な組み合わせを全て試すことで解読を試みる攻撃手法 対策として以下のような方法がある 強力なパスワードポリシーの適用（zxcvbn-ts、Pwned Passwordsによる検証） アカウントロックアウト機能 レートリミットによるログイン試行回数の制限 MFAの導入 CAPTCHAの利用 https://www.ipa.go.jp/security/vuln/websecurity/brute-force.html

#TypeScript #Security #Authentication パスワード強度を検証するライブラリ https://github.com/zxcvbn-ts/zxcvbn

#Security #Authentication #OWASP HTTP Cookie https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html

#Security #Authentication #OWASP Session Management zxcvbn-ts Pwned Passwords TLS Client Authentication MFA OAuth2 OpenId SAML Brute Force https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html

#Security #Authentication HTTPプロトコルにおける認証方式 ユーザー名とパスワードをコロンで連結した文字列をBase64エンコードした結果を、Authorizationヘッダーに付与することでリクエストを行う

#Security #Authentication ingressgatewayに対して、JWTの検証を行うためのカスタムリソース（CRD） https://istio.io/latest/docs/reference/config/security/request_authentication/

#Security #Authentication Istioにおいてマイクロサービス間のmTLSを設定するカスタムリソース（CRD） https://istio.io/latest/docs/reference/config/security/peer_authentication/

Completely Automated Public Turing test to tell Computers and Humans Apart #Security #Authentication 人間とボット（自動プログラム）を区別するための技術 主な目的はブルートフォース攻撃の防止、スパムやボットによる自動投稿の防止、不正なアカウント作成の防止 代表的な実装として、Google reCAPTCHA、hCaptcha、テキストベースCAPTCHAなどがある アクセシビリティの観点から、音声CAPTCHAなどの代替手段の提供が推奨される https://www.cloudflare.com/ja-jp/learning/bots/how-captchas-work/

#Security #Authentication 公開鍵と名前や住所等の識別情報を組み合わせることで、鍵の所有者を識別し正しい鍵であることを保証する証明書 認証局にデジタル署名をさせて発行される

JSON Web Token #Security #Authentication トークン自体の情報（例: 期限）を自身で構造化して保持することで、共有データベースへ保持・検索をする必要がないトークン。トークンが自身の情報を持つことで外部からのトークン取り消しのような操作はできない JWTは.によって3つのセクションの文字列に分割できる（署名がない場合3つ目のセクションは空） それぞれのセクションの文字列は構造化されたJSONをBase64URLエンコードした結果となっている ヘッダー 1つ目のセクションはヘッダーとして以下のような構造を持つ { "typ": "JWT", "alg": "RSA256" } algで指定する署名アルゴリズムは3つ目の署名セクションの解読にて用いる ペイロード 2つ目のセクションはトークン自体のペイロードになる。ペイロードの中身はJSONであれば自由だが、JWTクレームと呼ばれる役割が明示・明示された項目群が存在する。 例として　iss（発行者）、sub（対象者）、exp（有効期限）などがある 署名 3つ目のセクションはHMACやRSAのような署名アルゴリズムを使った結果が保持される RFC 7519 - JSON Web Token (JWT)

CA #Security #Authentication 信頼されたデジタル証明書の発行者