タグ

認証に関するauientのブックマーク (10)

  • パスキーの本質 - falsandtruのメモ帳

    パスキーの質はユーザー側としてはパスワード入力機会の削減、サービス側としては企業のセキュリティリスクのユーザーへの責任転嫁とコストカットである。 サービス側 企業がユーザーにパスキーを使わせようと強要するのはログイン情報の流出や流出したログイン情報による攻撃のリスクと責任とコストから企業を守るために認証に関する問題がユーザーの責任によってしか発生しないよう責任転嫁したいからに過ぎない。このため認証情報の紛失や盗難などによる喪失リスクと復旧の困難性やその他新たに発生する問題については隠蔽または矮小化される。企業にとってパスキーとはパスワードの定期的変更の最新版なのでありユーザーがパスキーを強要されるのはパスワードの定期的変更を強要された歴史を繰り返しているに過ぎない。 ユーザー側 パスキーの適切な実装におけるユーザーの質的利益はパスワード入力機会が減ることによりフィッシング被害を受ける機

    パスキーの本質 - falsandtruのメモ帳
    auient
    auient 2024/12/19
    「そもそも一般的なユーザーが多数のサービスの多数の復旧コードを適切に管理できるわけがない」
  • Cloudflare PagesにそれなりにちゃんとBasic認証をかける | おそらくはそれさえも平凡な日々

    前回の、社内プライベートポッドキャスト実現方法で、ポッドキャストサイトを静的配信しつつBasic認証をかけるというアイデアを書いた。しかし、Basic認証などなかなか使わなくなり、ネイティブでサポートしている静的ホスティングサービスも少ない。今回はCloudflare PagesのFunctions機能でリクエストをラップするミドルウェアを書けば実現できることが分かり、その方式を採用することにした。多少実装必要になるのと、認証周りを自前で書くのはあまりやりたくはないが、廉価に比較的省力で実現できるので受け入れる。 ネット上にいくつかサンプルは見つかるが、今回実装するにあたっては以下の点を留意した。 コード内に認証情報を載せない 複数ユーザーのIDとパスワードを管理できるようにする パスワードは定数時間比較してタイミング攻撃を防ぐ これらを以下のように解決することとした。 認証情報は環境変数

    Cloudflare PagesにそれなりにちゃんとBasic認証をかける | おそらくはそれさえも平凡な日々
    auient
    auient 2024/09/14
    「パスワードは定数時間比較してタイミング攻撃を防ぐ」同僚さんうらやましい
  • デジタル庁が発表した「デジタル認証アプリ」でできること ざっくり整理 - Qiita

    2024年6月21日にデジタル庁からデジタル認証アプリの発表がありました。 このデジタル認証アプリで何ができるのか、ざっくり整理してみました。 この記事で対象としている方 デジタル認証アプリの概要についてざっくり理解したい方 デジタル認証アプリについて今北産業してほしい方 この記事では技術的な話はなるべく避け、全体像を整理していきます。 技術的な話を理解したい方は、参考リンクより他の方が書かれた記事を参照してみてください。 「デジタル認証アプリ」はどんなものか? 「デジタル認証アプリ」は、マイナンバーカードを使った認証や署名を、安全に・簡単にするための、デジタル庁が提供するアプリです。 (デジタル認証アプリサービスサイトより引用) デジタル認証アプリは、デジタル庁が提供するデジタル認証アプリサービスAPIと組み合わせて1つのサービス(デジタル認証アプリサービス)を構成しています。デジタル認

    デジタル庁が発表した「デジタル認証アプリ」でできること ざっくり整理 - Qiita
  • Firebase Authから内製認証基盤に無停止移行して年間1000万円以上削減した

    症状検索エンジン「ユビー」 では、ローンチ当初から Firebase Auth (GCP Identity Platform) を使っていましたが、OIDCに準拠した内製の認証認可基盤に移行しました。 認証認可基盤そのものは m_mizutani と nerocrux と toshi0607(退職済) が作ってくれたため、僕は移行のみを担当しました。 結果として、強制ログアウトなし・無停止でビジネス影響を出さずに、年間1000万円以上のコスト削減に成功しました[1]。その移行プロセスについて紹介します。認証認可基盤そのものの紹介はあまりしません。 移行した理由 大量の匿名アカウント ユビーでは、アクセスした全ユーザーに対して自動的に匿名アカウントを発行しています。これにより、ユーザーがアカウント登録しているかどうかに関わらず、同じID体系で透過的に履歴情報等を扱うことができます。アカウント

    Firebase Authから内製認証基盤に無停止移行して年間1000万円以上削減した
  • 偽の ID (識別子) のアンチパターン

    こんにちは、Azure Identity サポート チームの 高田 です。 記事は、2023 年 6 月 20 日に米国の Azure Active Directory Identity Blog で公開された The False Identifier Anti-pattern を意訳したものになります。ご不明点等ございましたらサポート チームまでお問い合わせください。 日は、ID の世界における危険なアンチパターンである 偽の ID (識別子) のアンチパターン を取り上げます。アンチパターン とは、繰り返し発生する問題に対する一般的な対応策のことで、こういった問題は多くが悪い結果をもたらし、想定と反対の結果をもたらすリスクとなるものです。パスワードのアンチパターン も聞いたことがあるかもしれません。日お話しする内容は、もしかしたらより危険なパターンかもしれません。 偽の ID (

    偽の ID (識別子) のアンチパターン
  • パスキーとは何か、そしてその課題

    パスキーはフィッシングに強く、テクノロジーに詳しくないユーザーでも使いやすい新しい認証方式で、いずれパスワードを置き換えると言われています。この記事では、パスキーの基と、これからのウェブにとってパスキーがどういう意味を持つのかについてまとめてみます。 パスキーとは何か # 2022 年 12 月 9 日に GoogleAndroidChrome でパスキーがサポートされたとのアナウンスが出ました。Apple もすでに最新版の macOS Ventura、iOS / iPadOS 16 で Safari がパスキーに対応しています。 パスキーは AppleGoogleMicrosoft が協調して使う FIDO クレデンシャルの名前です。エンドユーザーのみなさんがパスワードの代わりとして認識し、直感的にログインできるよう「パスキー」というブランドとアイコンが決まりました。ウ

    パスキーとは何か、そしてその課題
  • Hanko — Authentication Infrastructure for the Passkey Era

    🚀 Startups: Up to 1M active users for $29/month flat — apply today! Authentication Infrastructure for the Passkey EraQuickly integrate Hanko’s embeddable components and APIs to get secure and modern user authentication for your apps. ‍ From passwords all the way to passkeys, 2FA, and SSO. Finally an auth solution that scales – without breaking the bank. And it’s open source.

    Hanko — Authentication Infrastructure for the Passkey Era
  • Laravel の認証・認可パッケージが多すぎてわけわからんので図にまとめた - Qiita

    元ネタ @localdisk さんの記事です。 こちらで概ね適切に説明されているものの,文章のみで図が無くて直感的に把握しづらいので,初心者にもすぐ飲み込ませられるように図に描き起こしてみました。 図 解説 illuminate/auth: 最小限の認証認可コアロジック コアコンポーネント群の laravel/framework に含まれているものです。 Socialite 以外のすべてのパッケージが,実質このコアに依存していることになります。 以下の記事でこのパッケージの詳細について説明しているので,ここでは端折って説明します。 伝統的 Cookie ベースのセッション認証 こちらでも解説している, 「Cookie に識別子を載せ,それに対応する情報はサーバ側のファイルに記録する」 という手法に近いものです。 実装は illuminate/session にあり, PHP ネイティブのセ

    Laravel の認証・認可パッケージが多すぎてわけわからんので図にまとめた - Qiita
  • SPAのログイン認証のベストプラクティスがわからなかったのでわりと網羅的に研究してみた〜JWT or Session どっち?〜 - Qiita

    SPAのログイン周りについて、「これがベストプラクティスだ!」という情報があまり見当たらないので、様々な可能性を模索してみました。 いろいろな状況が想定され、今回記載する内容に考慮の漏れや不備などがありましたら是非コメントでご指摘いただきたいです!特に「おすすめ度:○」と記載しているものに対しての批判をどしどしお待ちしております! この記事でおすすめしているものであっても、ご自身の責任で十分な検討・検証の上で選択されてください。 前提 想定しているAPIは、 ログイン外のAPIにはPOST/PUT/DELETEのものがなく、GETのみ GETのAPIにはDBを更新するなどの操作がない とし、そのためログイン外ではCSRFを考慮しなくてよい、 という前提で話を進めます。 また、XSSに関しては常に対策は必要なのですが(フレームワーク側が自動的にしてくれる部分もある)、認証周りに関係すること以

    SPAのログイン認証のベストプラクティスがわからなかったのでわりと網羅的に研究してみた〜JWT or Session どっち?〜 - Qiita
  • WebAuthnことはじめ | メルカリエンジニアリング

    こんにちは。株式会社メルペイのID Platformチームでエンジニアをしている @nerocrux です。この記事はMERPAY TECH OPENNESS MONTHの12日目の記事です。 はじめに WebAuthnについて 概要 システム構成 登録と認証 登録 認証 Attestation について Attestation検証の概要 AttestationObject のフォーマット AttestationObject の検証 1. AttestationObject のデコード 2. authenticatorData について 3. credentialPublicKey のパース 4. verificationData の準備 5. 証明書フォーマットの変換 6. 署名検証 Assertion について Assertion の検証 1. authenticatorData につ

    WebAuthnことはじめ | メルカリエンジニアリング
  • 1