AWS WAF を使ってアプリケーションに Basic 認証を設定できる🔒️Basic 認証のセキュリティレベルを理解した上で一時的な社内用途などで使いたいという場面はあると思う． 今回は AWS WAF + ALB（固定レスポンス）という簡単な組み合わせを Terraform で実装して試す． 準備 base64 コマンドでエンコードして Basic 認証の値を作っておく． $ echo -n 'user:password' | base64 dXNlcjpwYXNzd29yZA== 👾 variables.tf Basic 認証の値は Terraform コードには直接実装せず variable として渡す． variable "basic_auth_base64" { type = string sensitive = true } 👾 waf.tf 次は aws_wafv2_
株式会社MIXI 開発本部／OIDF-J エバンジェリスト 伊東 諒 2011年ミクシィ（現：MIXI）入社。MIXI Mという基盤システム&WALLETサービス、MIXI IDというMIXI社内のサービス間で利用できる共通アカウントの開発を担当している猫。OpenID ConnectやOAuth 2.0、パスキーといった標準化仕様について社内外での情報発信にも積極的に取り組んでいる。 パスワードレス認証の代名詞として普及が進むパスキー。2022年の登場から数年、世間的な認知度も向上し、オンラインサービスのユーザー認証の仕様を検討するうえでは避けて通れない存在となりつつあります。 株式会社MIXIの伊東 諒さんは、日本でパスキーの推進を積極的に行う一人です。MIXIの認証基盤におけるパスキーの導入も伊東さんの専門性を活かしながら進められました。 パスキーはパスワードの課題を根本から解決する
Advanced Settings Tips & Tricks A brief list of advanced capabilities that may not be immediately obvious when using this site: Sharing the URL in the address bar after making changes in Advanced Settings enables others to open this site with the same configuration. Clicking Authenticate without entering a username is supported. This enables testing "usernameless" authentication. Changing Authenti
Passkeys are the secure, phishing-resistant, and easy to use replacement for passwords, OTPs, and magic links.
ritouです。このしずかなインターネットにおける初投稿です。 おそらく、このしずかなインターネットのID連携では次のような設計になっていま「した」。問い合わせをさせていただき、対応いただきました。 これまでもQiitaなどで同様の実装例が紹介されていた際にはコメントさせていただいていたものですので、アンチパターンの紹介記事として読んでいただければと思います。 「Googleアカウントでログイン」ではじめると、ユーザーが作成され、Googleから受け取ったメールアドレス([email protected])が設定される 次回から「Googleアカウントでログイン」をすると、Googleから受け取ったメールアドレスでユーザーを参照 試しに、次のような流れで動作を確認してみます。 「Googleアカウントでログイン」でアカウント作成([email protected]) 「メールアドレス変更」
はじめに こんにちは。株式会社Flatt Securityセキュリティエンジニアの村上 @0x003f です。 本稿では、Webアプリケーション上で実装される「ログイン機能」の実装パターンをいくつか示し、その「仕様の中で起きうる脆弱性」とその対策について解説していきます。 「ログイン機能」はToB、ToC問わず多くのWebアプリケーションで実装されている機能で、XSSやSQL Injection、Session Fixationといったような典型的な脆弱性の観点については、なんらかの解説を見たことのある方も多いと思います。 しかし、「仕様の脆弱性」というのはあまり多く語られていない印象です。今回はそのようなタイプの脆弱性についての解説を行います。なお、IDaaSを用いずに自前でログイン機能を実装しているケースを複数パターン想定しています。 はじめに ログイン機能の仕様パターンとセキュリティ
TL;DR JWTはCookieを使った認証の代わりに使うのはきつい。 コードを静的にホスティングしているSPAの話。 JWTの有効期間を長くすれば危険で、短くすればUXが犠牲になるというトレードオフがある。 AWS AmplifyはlocalStorageにJWTを保存 悪意のあるThird partyライブラリが混ざっていたらJWTを抜かれる。 yarn.lockが依存している全ライブラリを監査することはつらい。 Auth0ではiFrameを活用してメモリ上にJWTを格納できる Auth0いいね😍 まくら Youtubeが大好きなHiCustomerの小田です。ちょっと遅いですが年明け最初のエントリーです。今年もテックブログをよろしくお願いします😎ちなみに、気分がいいので年明けに観ていたYoutubeのエントリーの中で一番おもしろかった動画を紹介します。世界中で有名な「Auld L
authorization_code_flow ��ժ� ���ժ� @startuml UA -> App: /login UA <-- App: Redirect UA -> 認可サーバー: /auhorize UA <- 認可サーバー: ログインページ表示 UA -> 認可サーバー: ログイン UA <- 認可サーバー: 認可（AppにXXXを許可しますか？ UA -> 認可サーバー: OK UA <-- 認可サーバー: Redierct UA -> App: /callback?code=xxx&state=xxx App -> 認可サーバー: /token に認可コードを渡す App <- 認可サーバー: AccessToken App -> App: セッションにAccessToken保存 UA <- App: ログイン完了 @enduml bad_practice_autho
This webpage was generated by the domain owner using Sedo Domain Parking. Disclaimer: Sedo maintains no relationship with third party advertisers. Reference to any specific service or trade mark is not controlled by Sedo nor does it constitute or imply its association, endorsement or recommendation.
こんにちは、サイオステクノロジー 武井です。 ※本記事の英語版はこちら(Click here to read in English) 今回は、OAuthを認証に利用することの危うさについて書きたいと思います。参考にさせていただきましたのは以下の記事になります。 https://www.thread-safe.com/2012/01/problem-with-oauth-for-authentication.html この記事では、OAuth2.0のImplicit Flowを使って認証を行った場合、悪意のあるユーザーが、簡単に他の誰かになりすますことができてしまうということが書いてあります。 今回、これを私なりにわかりやすく解説を試みてみたいと思います。
考えてみるとほとんどパスワードを保存するコードを書いたことがない。現状のベストプラクティスを知らなかったのでメモ書き。 現状では bcrypt 使うのがいいみたい。b は Blowfish の b。 Modular Crypt Format というフォーマットとコンパチの出力をする。crypt (3) はもともと DES の短いフォーマットだが、弱すぎたため md5 拡張なりSHA512 拡張などが存在している。(htpasswd でも使われているので見たことある人は多いだろう) これの Blowflish を使ったものが bcrypt で、prefix に $2$, $2a$, $2x$, $2y$ $2b$ がついている。prefix の違いはバージョンの違いであり、現在は 2b を使うのが良い。ストレッチング回数も出力に含まれるので、あるとき急にストレッチング回数を増やしても特に問題
はじめに Cloud Endpoints for gRPCの認証まわりでちょっと引っかかったので整理しました。 GCPのドキュメントは大元の英語版であっても間違ってる箇所が多いので注意が必要です。 言語はGolangです。 Cloud Endpoints Cloud EndpointsはAPIを管理するためのサービスです。いまいちわかりにくいですが、こんなことをやってくれます。 gRPC APIをREST APIに変換して提供 APIのモニタリング Auth0やFirebaseでの認証 Cloud Endpointsは大きく3つの形式で利用できます。 OpenAPI (JSON/REST API) 一般的なREST APIをCloud Endpointsで管理する感じ 旧Swagger Endpoints Framework アプリケーションに組み込んで使うタイプ App Engine S
「OAuth 認証」って言葉が出てくると、「認証と認可は違う」とか言い出す人が出てきて、大体の場合「OAuth 認証」言ってた人たちがやりたいことの話とはズレた議論が始まるので、もういっその事「OAuth 認証」とは何かを定義してみましょうかね。 「OAuth 認証」で Relying Party (RP) がやりたかったこと RP (OAuth Client) は、ブラウザの前にいる人を、認証したかったんですよね？ もう少し正確にいうと、ブラウザの前にいる Entity が、RP 側で把握しているどの Identity と紐付いているか、というのを知りたかったんですよね？ いきなり Entity とか Identity とかいう専門用語が出てきてアレですが、そのあたりのことは先日の OpenID TechNight #13 でもお話ししたので、以下のスライドの Entity・Identi
認可と認証技術 OAuth 1.0、OAuth 2.0 および OpenID Connect に関するスライドをアップしました。 アプリ開発で知っておきたい認証技術 - OAuth 1.0 + OAuth 2.0 + OpenID Connect - from Naoki Nagazumi www.slideshare.net 開発している Web アプリで、OAuth 1.0 や OAuth 2.0 および OpenID Connect の認可と認証技術を組み込んだ時に、あれこれ調査して知り得た技術をまとめたものです。 130ページくらいの力作です！ぜひご覧ください。 デモ これのデモはこちらにあります AuthsDemo デモのソースコードはこちらです。 GitHub - ngzm/auths-demo: This is a demo program with using OAuth
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog こんにちは、Yahoo! JAPAN 研究所の五味です。 プライバシー・セキュリティ分野の研究開発の一環で、次世代認証技術に関する業界団体 FIDO (ファイド) アライアンス に参加し、グローバルな企業の方々と共に技術仕様の策定や技術の応用展開に取り組んでいます。FIDOアライアンスの 第1回東京セミナー に関しては、既に、約2年前のブログ「アイデンティティ管理とその動向」にてご紹介していました。 今回は、12月8日に虎ノ門ヒルズフォーラムでFIDOアライアンスにより開催されました第3回東京セミナーでの私の講演内容に関してご紹介いたします。 タイトルは「FIDO認証の進化とさらなる応用展開」で、FIDOアライアンスが技術仕様を策
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
