サクサク読めて、
アプリ限定の機能も多数！
アプリで開く
これはパスキー(FIDO/FIDO2)の安全性と脆弱性と破滅的欠陥そして正しい認証設計の最も包括的かつ総合的な解説である。パスキーの破滅的欠陥の公開はこれが世界初である。次に列挙する事項を読めば欠陥の原理を掴める。全体の文量が多ければ最初はハイライト部分だけ流し読んで要点を掴むのもいいだろう。証拠となる公式文書は後半に記載している。パスキーは公式の案内に従って導入すると強制リセット不可能に陥り攻撃発生後の対応が不可能となり被害の拡大阻止も回復も不可能となる破滅的欠陥により大規模攻撃発生時点で事業破綻が確定する。個々のユーザーが詰むことは数あれどパスキーはサービス側が詰んで事業破綻する史上初にして唯一の破滅的欠陥認証方式である。さらにパスキーは不要なパスキーオンリーにより不要にユーザーと収益を失わせサービスに日々多大な損害を与え続けている。パスキーはマジックリンクを始めとする他の認証方式と併
When I worked on open-source authentication as a student, I never imaginedit powering web-scale services likechatgpt.com. Ory Hydra initially began as aGo-based alternative toKeycloak, avoiding complex JVM dependencies. After releasing the first version in 2015, we quickly saw that the initial design wasn't flexible enough.Building a full Customer Identity and Access Management (CIAM) system
はじめに こんにちは、IT本部IT戦略部テクニカルオペレーショングループの山田です。 認証基盤は、当社のセキュリティと日々の事業活動を支える、最も重要なITインフラの一つです。こうした重要なシステムは、事業の成長や技術トレンドの変化に合わせ、常に最適な状態であり続けるための定期的な見直しが欠かせません。 このような背景から、私達は長年パートナーとして利用してきた認証基盤「Okta」について、現状の評価と今後の方向性を検討するプロジェクトを立ち上げました。 この記事は3部構成を予定しており、今回は第1回目です。それではよろしくお願いします。 私たちの目指す姿 まず前提としてお伝えしたいのは、Oktaが非常に優れたプロダクトであるということです。当社では2012年から10年以上に渡って社内の認証基盤としてOktaを使用しており、迅速なカスタマーサクセスと高度なセキュリティレベルの担保に大きく貢
まことにもっともな疑問だと思います。公開鍵暗号には、狭義の公開鍵暗号と、広義の公開鍵暗号があります。パスキーで使われているのは、広義の公開鍵暗号です。 狭義・広義だと紛らわしいので、狭義の方をPublic Key Encryption(PKE)、広義の方をPublic KeyCryptography(PKC)と表記する場合があります。光成さんのブログ記事がわかりやすいです。 https://blog.cybozu.io/entry/2021/12/28/080000 あなたの「公開鍵暗号」はPKE? それともPKC? - Cybozu Inside Out | サイボウズエンジニアのブログ初めに サイボウズ・ラボの光成です。 いきなりですがクイズです。次のうち正しい説明はどれでしょう。 SSHやFIDO2などの公開鍵認証はチャレンジを秘密鍵で暗号化し、公開鍵で復号して認証する。 ビットコ
Intro パスワード + TOTP は限界を迎え、Passkey へ移行しなければ、サービスがユーザを守りきれなくなった。 逆を言えば、サービスがユーザを守りたいと思うのであれば、Passkey を提供しないわけにはいかない時代に突入している。 では、令和のこの状況において、サービスはどう対応していくべきだろうか? サービスの対応 理想だけを言うなら、Passkey をサポートし、Username-Less のログインを可能にする。その上で、パスワード+TOTP の認証はサポートを止め、保持していてもリスクでしかないパスワードのハッシュを、サーバから消す。鍵の管理とリカバリにだけに注力すれば良い。 というところまで到達できればよいが、現実的にはまだまだ過渡期どころか黎明期だ。サービスをそのように実装できればシンプルで堅牢だが、ユーザはそこまでの準備が整っているとは言えない。 サービスがパ
アカウント温故知新と東京リージョン az-a の呪い 昔話になりますが、私は個人のAWS アカウントを 東京リージョンが利用可能になった 2011年 に作成しました。それ以降 EC2 をはじめとして散発的にAWS リソースを使用してきましたが、時代とともに古いアカウントならではの制限事項が目につくようになってきました。 制限事項の中で最も大きいのが 古いAWS アカウントでは東京リージョンのアベイラビリティゾーン a が使用できない という問題です。AWS CDK しかり、Cfn しかり、何かのハンズオンしかり、基本的に新しめの(?)AWS アカウントを想定しており、その度に「他の人のアカウントではうまくいくが自分のアカウントだとエラーになってしまう」ケースが「稀ではなくよくある」事態となっていました。 こういった経緯を含め、アカウント管理の体制を一新してAWS Organiza
パスキーの本質はユーザー側としてはパスワード入力機会の削減、サービス側としては企業のセキュリティリスクのユーザーへの責任転嫁とコストカットである。 サービス側 企業がユーザーにパスキーを使わせようと強要するのはログイン情報の流出や流出したログイン情報による攻撃のリスクと責任とコストから企業を守るために認証に関する問題がユーザーの責任によってしか発生しないよう責任転嫁したいからに過ぎない。このため認証情報の紛失や盗難などによる喪失リスクと復旧の困難性やその他新たに発生する問題については隠蔽または矮小化される。企業にとってパスキーとはパスワードの定期的変更の最新版なのでありユーザーがパスキーを強要されるのはパスワードの定期的変更を強要された歴史を繰り返しているに過ぎない。 ユーザー側 パスキーの適切な実装におけるユーザーの本質的利益はパスワード入力機会が減ることによりフィッシング被害を受ける機
いろんなアイデンティティ管理系製品やサービスの実験の記録をしていきます。 後は、関連するニュースなどを徒然と。 こんにちは、富士榮です。 先日、IDProで紹介されていた記事を見つつ以下のポストをしました。 パスキーはパスすべきなのか？結局パスキーはパスすべきなのか？ 記事の中では同期ファブリックの安全性や互換性に関する課題が指摘され、デバイス紐付けパスキーという選択肢やUniversalCredential Exchangeによる相互運用性の実現に向けた取り組みの紹介をしました。 結果、エンタープライズでの利用の場合は同期パスキーよりもデバイス紐付けと管理などが現実的なのかな？？などのコメントを各所で頂いたりしました。 そんな中、RSAが最近こんなブログを公開しました。 Are FIDO Passkeys Ready for Enterprise Use? https://www.rs
0. はじめに OpenAM14.5 では学術認証フェデレーション「学認 （GakuNin）」との連携機能を強化し、学認IdP として運用しやすくなりました。特に、送信属性同意機能や、SP の自動登録、属性値のスクリプトによる生成など、Shibboleth IdP が持つ機能と同等の機能を強化しています。 OpenAM は一つのバージョンを長期にサポートすることにより、バージョンアップを気にせずに長期間運用いただけます。また、ソフトウェアを RPM パッケージで提供しており、同梱の Tomcat を含めシステム全体を RPM コマンドなど O.S.と同等のLinux スキルで運用とサポートが可能な製品となっています。 以上のように OpenAM 単体で 学認IdP として構築可能ですが、Microsoft Entra ID（以降 Entra ID） を利用している組織では、学認IdP と
"Let’s use a token to secure thisAPI call. Should I use the ID token or the access token? 🤔 The ID token looks nicer to me. After all, if I know who the user is, I can make better authorization decisions, right?" Have you ever found yourself makingsimilar arguments? Choices based on your intuition may soundgood, but what looks intuitive is not always correct. In the case of ID and access toke
「デジタル認証アプリ」は、マイナンバーカードを使った本人確認を、安全に・簡単にするためのアプリです。行政機関や民間事業者は、デジタル庁が無償で提供するAPI（デジタル認証アプリサービスAPI）を活用することで、マイナンバーカードを使った本人確認を簡単に組み込むことができます。 デジタル認証アプリのご利用を検討する行政機関等、民間事業者の方は、下記サービスサイトからお申込みください（受付開始は、6月24日（月）午後以降となります）。 デジタル認証アプリサービスサイト デジタル庁開発者サイト 参考資料デジタル認証アプリについて（PDF／1,451KB）関連情報「簡単」「安心」に本人確認ができるデジタル認証アプリ（デジタル庁ニュース）
🍪 We usecookies to providenecessary functionality and improve your experience. Read ourCookie Policy. OK Your browser is out of date. For the best experience, upgrade your browser now. We introduced support for time-based one-time passwords (TOTP) way back in the dark ages of 2015. The addition of TOTP storage lets you use 1Password as an authenticator for websites that support two-factor auth
この記事の内容は、個人の意見であり感想です。くれぐれもよろしくおねがいします。 とりあえずドラフトですが公開します。識者のみなさまの暖かく、そして鋭いツッコミを期待します。 パスキーについて、非常にわかりやすいブログをえーじさんが書いてくださいました。コレを読んで頂ければほとんどのことが分かると思います。 先日の次世代Webカンファレンスで、私は、「結局、パスキーは秘密鍵と公開鍵のペア」と申し上げた立場からも、この疑問はごもっともだと思いましたので、すこし、私の思うところを述べたいと思います。 パスキーは２要素認証の場合が多いほとんどのユーザは、OS標準のパスキーを使うのではないかと思います。そして、生体認証、もしくは画面ロック用のパスワードやPIN等が設定されていない限り、OS標準のパスキーを使うことができません。そして、OS標準パスキーの利用時には、生体認証もしくは画面ロック解除のため
弊社オフィスのある西五反田付近は再開発で慌ただしく、高層ビル建設でいつも騒がしい。 ふと窓の外に目をやると鬱蒼とした木々に覆われた廃屋が異質な存在感を示しています。 積水ハウス55億円詐欺事件の舞台となった海喜館です。 目次なぜ騙されたのか事件のいきさつは繰り返し報道されている通りです。 この詐欺は地面師グループと呼ばれる複数の人物によって計画された犯行です。 大手不動産業者が騙されるほどの手口であり、犯行グループの巧妙さが大々的に報じられました。 しかしどうすればこの事件を防げたのかという対策を論じた報道はあまりありません。 もし、あなたが積水ハウスの担当者だったら、司法書士であったならどの様にしてこの詐欺を見抜けばよかったのでしょうか。 原因のひとつに、取引相手の本人確認(KYC)が甘かった事が指摘されています。 地面師グループは「道具屋」と呼ばれる偽造屋にパスポートや免許証、印鑑登録
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
