並び順

ブックマーク数

期間指定

  • から
  • まで

41 - 80 件 / 542件

新着順 人気順

authorizationの検索結果41 - 80 件 / 542件

  • マイクロサービスにおける内部通信の認証について

    "Backend Engineer’s meetup ~マイクロサービスにおける認証認可基盤~"の発表資料です。 https://connpass.com/event/142624/

      マイクロサービスにおける内部通信の認証について
    • W3C、中央集権的な管理を不要にする「Decentralized Identifiers (DIDs)」(分散型識別子)の仕様が勧告に到達

      W3C、中央集権的な管理を不要にする「Decentralized Identifiers (DIDs)」(分散型識別子)の仕様が勧告に到達 World Wide Web Consortium (W3C)は、「Decentralized Identifiers (DIDs) 」(分散型識別子)バージョン1.0(以下、W3C DID)の仕様が勧告に到達したと発表しました。 W3C press release: "Decentralized Identifiers (DIDs) v1.0 becomes a W3C Recommendation" "This new type of verifiable identifier... will enable both individuals and organizations to take greater control of their onl

        W3C、中央集権的な管理を不要にする「Decentralized Identifiers (DIDs)」(分散型識別子)の仕様が勧告に到達
      • LINEがオープンソースで「LINE FIDO2 Server」公開。パスワード不要でログインできる「FIDO2/WebAuthn」を実現

        LINEがオープンソースで「LINE FIDO2 Server」公開。パスワード不要でログインできる「FIDO2/WebAuthn」を実現 LINEは、スマートフォンやPCの指紋認証や顔認証などを用いることでパスワード不要でログイン処理を可能にする標準技術「FIDO2」や「WebAuthn」に対応したサーバ「LINE FIDO2 Server」をオープンソースで公開しました。 これにより、さまざまなWebアプリケーションやモバイルアプリケーションなどでFIDO2/WebAuthnを利用したログインが容易に実装できるようになることが期待されます。 LINE Security R&DチームがFIDO2認証標準を実装したFIDO2 ServerをOSSとして公開しました。 FIDO2-Serverは、FIDO2の登録と認証の主要部分を提供します。さまざまなWebブラウザとOSプラットフォーム、お

          LINEがオープンソースで「LINE FIDO2 Server」公開。パスワード不要でログインできる「FIDO2/WebAuthn」を実現
        • マイクロサービス時代のセッション管理 - Retty Tech Blog

          この記事はRetty Advent Calendar 2019 21日目の記事です。エンジニアの 神@pikatenor がお送りします。11日目の記事に書かれた「弊社エンジニアの神(注・人名であり実名です)」とは私のことです。 qiita.com さて世はまさにマイクロサービス大航海時代、大規模化した組織・肥大化したコードベースのメンテナンスを継続的に行っていくべく、アプリケーションを機能別に分割する同手法が注目を集めていることは皆さんもご存知でしょう。 マイクロサービスアーキテクチャ特有の設計課題はいくつかありますが、今回は認証情報のような、サービス間でグローバルに共有されるセッション情報の管理のパターンについて調べたことをまとめてみたいと思います。 背景 HTTP は本質的にステートレスなプロトコルですが、実際の Web サービス上では複数リクエストをまたがって状態を保持するために、

            マイクロサービス時代のセッション管理 - Retty Tech Blog
          • OAuthにおける認可コード横取り攻撃とその対策

            OAuthにおける認可コード横取り攻撃とその対策 Jul 5, 2021 前回の記事で示したように、カスタムURLスキームを偽装した不正アプリは正規アプリへのディープリンクを乗っ取れる。この挙動の悪用シナリオとして、正規アプリと認可サーバー間のOAuthフローにおける認可コード横取り攻撃が知られている。この攻撃への対策を把握するためにiOS環境でシナリオを再現し、PKCEの有効性を確認した。 要約 OAuth 2.0の拡張機能であるPKCEを導入することで認可コード横取り攻撃を無効化できる。OAuth 2.0の仕様では、認可サーバーはネイティブアプリをクライアント認証できない。そのため、認可サーバーは認可コードを横取りした不正アプリと正規アプリを識別できない。しかし、PKCEの仕組みにより認可サーバーは正規アプリを識別できるようになり、認可コード横取り攻撃の検知が可能となる。 ネイティブア

              OAuthにおける認可コード横取り攻撃とその対策
            • OAuth 2.0 の勉強のために認可サーバーを自作する - Qiita

              逆に、RFC 6749 以外で定義されている認可フローをサポートする場合、新たに別のエンドポイントの実装が必要になることがあります。例えば CIBA(Client Initiated Backchannel Authentication)ではバックチャネル認証エンドポイント(backchannel authentication endpoint)、デバイスフロー(RFC 8628)ではデバイス認可エンドポイント(device authorization endpoint)の実装が求められます。 この記事では、認可エンドポイントとトークンエンドポイントを実装します。サポートする認可フローは認可コードフローのみ、サポートするクライアント・タイプはパブリックのみとします。 2. 注意点 下記の理由、および書かれていないその他の理由により、本実装は商用利用には適していません。 セキュリティー上必須

                OAuth 2.0 の勉強のために認可サーバーを自作する - Qiita
              • 指紋認証は500円あれば作れる「偽指紋」で簡単に突破できることを示すムービー

                PCやスマートフォンの認証方法として指紋認証を利用している人も多いはず。しかし、実は指紋認証は本人不要・指紋で汚れた端末の写真さえあれば、5ドル(約550円)程度で作成した「偽指紋」で簡単に突破できてしまうことが、ムービーで示されています。 Your Fingerprint Can Be Hacked For $5. Here’s How. - Kraken Blog https://blog.kraken.com/post/11905/your-fingerprint-can-be-hacked-for-5-heres-how/ 指紋がいかに簡単に偽造できてしまうのかは、以下のムービーを見るとよくわかります。 Kraken Security Labs Bypasses Biometric Security With $5 In Materials - YouTube PCやスマートフォン

                  指紋認証は500円あれば作れる「偽指紋」で簡単に突破できることを示すムービー
                • マイクロサービスの認証・認可とJWT / Authentication and Authorization in Microservices and JWT

                  OCHaCafe Season4 #4の資料です. デモのソースコード等はこちらをご参照ください.

                    マイクロサービスの認証・認可とJWT / Authentication and Authorization in Microservices and JWT
                  • 一般企業であまり前例がない「認証VLAN」を導入した、その後の学び - MonotaRO Tech Blog

                    こんにちは。サービスインフラ-Bグループの宮本・高野です。 今回はManabiCon第3回で発表した「梅田オフィスで認証VLANを導入したプロジェクト」について紹介します。 自己紹介 梅田オフィス構築後に発生した問題 前提 フリーアドレス 通信品質の安定 本題 そもそもVLANとは何なのか? じゃあ認証VLANとは何なのか? 認証VLANのキーワード「IEEE802.1X」とは? プロジェクト概要 プロジェクト体制 プロジェクトの予定期間 実現したいこと 検証時の苦労 苦労したことその1: 必要機材とテストパターンの洗い出し 苦労したことその2:検証環境の構築 苦労したことその3:VLAN設計変更 苦労したことその4:有線LAN接続時、通信が不安定になる 苦労したことその5:認証VLANを利用しているPCへリモートデスクトップ接続ができない 在宅勤務・出社勤務 802.1X の認証モードに

                      一般企業であまり前例がない「認証VLAN」を導入した、その後の学び - MonotaRO Tech Blog
                    • Laravel の認証・認可パッケージが多すぎてわけわからんので図にまとめた - Qiita

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

                        Laravel の認証・認可パッケージが多すぎてわけわからんので図にまとめた - Qiita
                      • スマホを壊してGoogle製二要素認証アプリのバックアップコードが生成不能になったという体験談、バックアップ方法はこれ

                        ワンタイムパスワードを用いた二要素認証は、ウェブサービス利用時のセキュリティ向上に役立ちます。しかし、Google製ワンタイムパスワード発行アプリ「Google認証システム(Google Authenticator)」の利用者からは「スマートフォンを壊した結果、Google Authenticatorのバックアップコード再発行が不可能になった」という報告が寄せられています。 Tell HN: It is impossible to disable Google 2FA using backup codes | Hacker News https://news.ycombinator.com/item?id=34441697 Google Authenticatorは、各種ウェブサービスにログインするためのワンタイムパスワードを発行するアプリです。例えば、以下はDiscordにログインする際

                          スマホを壊してGoogle製二要素認証アプリのバックアップコードが生成不能になったという体験談、バックアップ方法はこれ
                        • ドコモが「パスキー」を導入してフィッシング被害報告が0件に パスワードレス認証の効果

                          パスワードを使わないパスワードレス認証であるパスキーを推進するFIDO Allianceは会見を開き、既に70億を超えるオンラインアカウントがパスキー利用可能な状態になって、利用が拡大していることをアピールした。国内でも利用が拡大しており、新たにメルカリがボードメンバーに加盟し、住信SBIネット銀行がアライアンスに加盟した。 FIDO Allianceの1年の取り組みが紹介された。写真左からメルカリ執行役員CISO市原尚久氏、LINEヤフーLY会員サービス統括本部ID本部本部長伊藤雄哉氏、FIDO Japan WG座長でNTTドコモのチーフ・セキュリティ・アーキテクト森山光一氏、FIDO Allianceエグゼクティブディレクター兼最高マーケティング責任者のアンドリュー・シキア氏、FIDO Alliance FIDO2技術作業部会共同座長でGoogle ID&セキュリティプロダクトマネージ

                            ドコモが「パスキー」を導入してフィッシング被害報告が0件に パスワードレス認証の効果
                          • 経済産業省、全ECサイトが義務化対象 セキュリティー対策で脆弱性対策と本人認証導入を義務化 | 日本ネット経済新聞|新聞×ウェブでEC&流通のデジタル化をリード

                            2023.01.24 経済産業省、全ECサイトが義務化対象 セキュリティー対策で脆弱性対策と本人認証導入を義務化 経済産業省は1月20日、ECサイトの脆弱性対策と本人認証の仕組みを導入することを義務化する方針を固めた。2024年3月末までに、全てのECサイトが脆弱性対策と本人認証を導入することを、検討会の報告書案に盛り込んでいる。 ECサイトと本人認証の仕組みの導入の義務化は、「クレジットカード決済システムのセキュリティ対策強化検討会」の第6回会合で提出された報告書案に盛り込まれた。 報告書案では、クレジットカード番号の不正利用被害が増え続ける問題を背景に、「ECサイトからクレジットカード情報が漏洩することへの対策」「漏洩したクレジットカード情報が不正に使われることへの対策」の2点を盛り込んだ。 具体的には、「クレジットカード番号等の適切管理義務の水準を引き上げるべく、サイト自体の脆弱性対

                              経済産業省、全ECサイトが義務化対象 セキュリティー対策で脆弱性対策と本人認証導入を義務化 | 日本ネット経済新聞|新聞×ウェブでEC&流通のデジタル化をリード
                            • 「Google認証システム」がアカウント同期に 機種変が気楽に

                              米Googleは4月24日(現地時間)、2段階認証アプリ「Google Authenticator」(日本では「Google認証システム」)をアップデートし、ワンタイムコードを端末ではなく、Googleアカウントに(つまりクラウドに)保存するようにしたと発表した。これで端末を紛失してもロックアウトされることがなくなり、機種変更時の移行作業も不要になる。 Google認証システムは2010年にリリースされた、サービスやアプリへの2要素認証(2FA)によるログインで利用できるアプリ。AndroidだけでなくiOS版もあり、TwitterやFacebookなど多数のサービスで利用できる。 これまではワンタイムコードを1つの端末にしか保存できなかったため、その端末を紛失したり盗難されたりすると、このアプリを使って2FAを設定したサービスやアプリにログインできなくなっていた。 既にこのアプリを使って

                                「Google認証システム」がアカウント同期に 機種変が気楽に
                              • 生年月日をパスワードにするよう指定 子育て支援サイトが話題 パスに認証以外の役割があった

                                神奈川県の子育て支援サイト「かながわ子育て応援パスポート」が、利用登録の際に子供の生年月日をパスワードにするよう指定していることがTwitterで話題になっている。指摘を受け、県は仕様を修正する予定。 かながわ子育て応援パスポートは、小学校6年生以下の子供を持つ子育て世代向けに、特典やサービス、支援施設などの情報を発信しているWebサイト。利用登録時にパスワードの設定画面で「最年少のお子さんの生年月日を半角数字で入力してください」と求めている。生年月日の書式になっていない場合は登録できず、設定後の変更はできない。 パスワードに認証以外の役割 県によると、パスワードに生年月日を指定しているのは、同サイトのパスワードがアカウント認証の他に、生年月日を確認する役割も持っているからだという。同サイトのサービスは12歳になって最初の3月31日以降に使えなくなるが、有効期限を判定するためにパスワードを

                                  生年月日をパスワードにするよう指定 子育て支援サイトが話題 パスに認証以外の役割があった
                                • Next.jsとAuth0で会員制メディアを作る【1. 認証編】

                                  こんにちは、柴田です。 今回は「会員制メディア」のチュートリアルを全3回に分けてお届けします。 === 認証編ページ作成編完成編=== 会員制メディアは、一部の記事は会員しか見れないような形式のメディアです。 ビジネスでは近年よくあるユースケースであり、もしかしたら個人ブログに導入してみても一風変わっていて面白いかもしれません。 また、応用すれば課金しないと見れない記事のような仕組みも作れると思います。 今回想定している仕様は以下の通りです。 記事一覧画面と全公開記事(/public配下)は事前生成をしておき、静的に配信する会員向け記事(/private配下)はログイン済みユーザーのみ閲覧可能とし、SSRで配信する Next.jsを用いてJamstackとSSRの合わせ技を行い、認証にはAuth0を用います。 1. Next.jsプロジェクトを用意まずは、Next.jsのプロジェクトを作成

                                    Next.jsとAuth0で会員制メディアを作る【1. 認証編】
                                  • 狙われるワンタイムパスワード、多要素認証を破る闇サービスが浮上

                                    狙われるワンタイムパスワード、多要素認証を破る闇サービスが浮上:この頃、セキュリティ界隈で(1/2 ページ) 不正アクセスを防ぐ対策の代表である、多要素認証。ワンタイムパスワードを実装する例が多いが、この仕組みを突破しようとする攻撃が増えつつあるという。 ネット上のアカウントに対する不正アクセスを防ぐため、今や多要素認証は欠かせない対策となった。たとえIDとパスワードが盗まれたとしても、ワンタイムパスワードの入力が必要な状態にしておけば、アカウントは守られるという想定だ。ところがその仕組みを突破しようとする攻撃が増えつつある。 暗号資産取引所大手のCoinbaseでは、顧客約6000人がSMSを使った多要素認証を突破され、暗号通貨を盗まれる事件が発生した。 BleepingComputerによると、2021年3月~5月にかけ、何者かがCoinbase顧客のアカウントに不正侵入して暗号通貨を

                                      狙われるワンタイムパスワード、多要素認証を破る闇サービスが浮上
                                    • パスキーは本当に2要素認証なのか問題、またの名を、あまり気にせず使えばいいと思うよ。|kkoiwai

                                      この記事の内容は、個人の意見であり感想です。くれぐれもよろしくおねがいします。 とりあえずドラフトですが公開します。識者のみなさまの暖かく、そして鋭いツッコミを期待します。 パスキーについて、非常にわかりやすいブログをえーじさんが書いてくださいました。コレを読んで頂ければほとんどのことが分かると思います。 先日の次世代Webカンファレンスで、私は、「結局、パスキーは秘密鍵と公開鍵のペア」と申し上げた立場からも、この疑問はごもっともだと思いましたので、すこし、私の思うところを述べたいと思います。 パスキーは2要素認証の場合が多いほとんどのユーザは、OS標準のパスキーを使うのではないかと思います。そして、生体認証、もしくは画面ロック用のパスワードやPIN等が設定されていない限り、OS標準のパスキーを使うことができません。そして、OS標準パスキーの利用時には、生体認証もしくは画面ロック解除のため

                                        パスキーは本当に2要素認証なのか問題、またの名を、あまり気にせず使えばいいと思うよ。|kkoiwai
                                      • 従業員を標的にした認証サービスに対するスミッシングについてまとめてみた - piyolog

                                        2022年8月7日、米国のクラウドコミュニケーションプラットフォームサービスを提供するTwilioは従業員がスミッシングによるアカウント侵害を受け、その後に同社サービスの顧客関連情報へ不正アクセスが発生したことを公表しました。また、Cloudflareも類似の攻撃に受けていたことを公表しました。ここでは関連する情報をまとめます。 米国2社が相次ぎ公表 TwilioとCloudflareは、従業員に対し、何者かがIT管理者からの通知になりすましたSMSを送り、記載されたURLからフィッシングサイトへ誘導される事例が発生したことを報告。 2022年8月7日 Twilio Incident Report: Employee and Customer Account Compromise 2022年8月10日 Cloudflare The mechanics of a sophisticated

                                          従業員を標的にした認証サービスに対するスミッシングについてまとめてみた - piyolog
                                        • 仕様起因の脆弱性を防ぐ!開発者向けセキュリティチェックシート(Markdown)を公開しました - Flatt Security Blog

                                          はじめに こんにちは。株式会社Flatt Securityセキュリティエンジニアの村上 @0x003f です。 これまで弊社ブログでは様々な「仕様とセキュリティ観点の解説記事」を発表してきました。今回はいままでの記事を改めて紹介しつつ、読者の皆様が開発中のサービスでセルフチェックを行えるよう「仕様とセキュリティ観点チェックリスト」を作成しました。ご活用いただけると幸いです。 ダウンロードは下記のGitHubリンクよりどうぞ。 また、株式会社Flatt Securityではお客様のプロダクトに脆弱性がないか専門のセキュリティエンジニアが調査するセキュリティ診断サービスを提供しています。料金に関する資料を配布中ですので、ご興味のある方は是非ご覧ください。 はじめに アプリケーションの仕様起因の脆弱性とは アプリケーションの仕様起因の脆弱性を防ぐために 仕様の脆弱性によく見られる共通点 1. ク

                                            仕様起因の脆弱性を防ぐ!開発者向けセキュリティチェックシート(Markdown)を公開しました - Flatt Security Blog
                                          • アップル、グーグル、マイクロソフトの3社「FIDO」新機能サポートを表明――スマホの指紋認証でパソコンのWebサイトログイン可能に

                                              アップル、グーグル、マイクロソフトの3社「FIDO」新機能サポートを表明――スマホの指紋認証でパソコンのWebサイトログイン可能に
                                            • 「過去最悪の水準」 ネットバンク不正送金、急増の理由 破られた“多要素認証の壁”

                                              2019年9月からネットバンキングでの不正送金による被害が急増している。その背景には、多要素認証を迂回する手段が登場したことが挙げられるという。 この数週間、複数の公的機関やセキュリティベンダーが2019年のサイバーセキュリティ動向のまとめを公表しました。その中でも驚かされたのが、ネットバンキングでの不正送金による被害の急増ぶりです。警察庁の発表によると、それ以前は横ばいだった不正送金被害が19年9月から急増して過去最悪の水準になっており、その多くはフィッシングメールによる偽サイトへの誘導によるものとみられています。 実はこの数年、ネットバンキングを狙ったサイバー犯罪による被害は横ばいか、やや減少傾向にありました。 確かに14~15年にかけては、金融機関の名前をかたったフィッシングメールを送り付け、ネットバンキングのパスワードを盗み取って不正送金を行う手口が横行し、年間で30億円を超える被

                                                「過去最悪の水準」 ネットバンク不正送金、急増の理由 破られた“多要素認証の壁”
                                              • 完全無料のIDaaS!?Google Cloud Identity Freeを試してみる

                                                Google Cloud Identity Services昨日開催された「リーグオブ情シス #7」でも紹介されていた、Google Cloud Identity Freeを試してみます。 Google Cloud Identity Freeとはデバイス管理やディレクトリ管理、SAMLを利用したSSOなどGoogle Cloud Identityのほとんどの機能を無料で利用できるライセンス体系です。 閲覧だけに限って言えば、Google Driveの共有ドライブも利用することが可能です。 作成できるユーザー数は「50」までに制限され、プロビジョニングなどはできませんが、ユーザーの組織管理という観点においてはほとんどのことを十分にこなすことが可能です。 Google Workspaceを利用している場合は、同じ組織内にユーザーを共存させることも可能なので、小さな組織でパート・アルバイトの方な

                                                  完全無料のIDaaS!?Google Cloud Identity Freeを試してみる
                                                • マイクロサービス時代のセッション管理 - Retty Tech Blog

                                                  この記事はRetty Advent Calendar 2019 21日目の記事です。エンジニアの 神@pikatenor がお送りします。11日目の記事に書かれた「弊社エンジニアの神(注・人名であり実名です)」とは私のことです。 qiita.com さて世はまさにマイクロサービス大航海時代、大規模化した組織・肥大化したコードベースのメンテナンスを継続的に行っていくべく、アプリケーションを機能別に分割する同手法が注目を集めていることは皆さんもご存知でしょう。 マイクロサービスアーキテクチャ特有の設計課題はいくつかありますが、今回は認証情報のような、サービス間でグローバルに共有されるセッション情報の管理のパターンについて調べたことをまとめてみたいと思います。 背景 HTTP は本質的にステートレスなプロトコルですが、実際の Web サービス上では複数リクエストをまたがって状態を保持するために、

                                                    マイクロサービス時代のセッション管理 - Retty Tech Blog
                                                  • 認可のベストプラクティスとDDDでの実装パターン

                                                    最近、少々複雑な権限機能の開発を担当している中で、対応方針を悩んでいたことがありました。 権限機能というものは取り扱いが難しく、影響範囲が広いにも関わらず、対応漏れや考慮不足があると情報漏洩に繋がってしまいます。 また、機能拡張をしてく中でも対応漏れを起こさないようにする必要があるなど、考えることも多く頭を悩ませておりました。 そこで、認可処理の設計のベストプラクティスやDDDの実装パターンに認可処理を組み込む方法など、色々と調べていたのですが、その中でいくつか知見を得られたのでまとめようと思います! 権限と認可 権限と切っては切れない関係にあるのが認可です。 権限はある操作を実行できる権利を指します。 それに対して、認可は操作を実行する許可を出すため仕組みのことを指します。 例えば、ブログ投稿サービスで考えてみると、以下のような感じです。 権限: 投稿者はポストを編集できる。 認可: ユ

                                                      認可のベストプラクティスとDDDでの実装パターン
                                                    • Auth0のアクセストークンをLocal Storageに保存するのは安全?メリット・デメリットをin-memory方式と比較して検討する - Flatt Security Blog

                                                      ※追記: 本記事の続編としてin-memory方式からアクセストークンを奪取するPoCを下記記事で公開しました。ぜひあわせてご覧ください。 はじめに こんにちは。 セキュリティエンジニアの@okazu-dm です。 この記事では、Auth0のSPA SDKでアクセストークンのキャッシュを有効化する際の考慮ポイントについて紹介し、それを切り口にアクセストークンの保存場所に関してin-memory方式とlocalStorage方式の2つについて解説します。 Auth0のようなIDaaSは昨今かなり普及が進んでいると思いますが、Flatt Securityの提供するセキュリティ診断はAuth0に限らずFirebase AuthenticationやAmazon CognitoなどのIDaaSのセキュアな利用まで観点に含めて専門家がチェックすることが可能です。 ご興味のある方は是非IDaaS利用部

                                                        Auth0のアクセストークンをLocal Storageに保存するのは安全?メリット・デメリットをin-memory方式と比較して検討する - Flatt Security Blog
                                                      • サーバサイドでJWTの即時無効化機能を持っていないサービスは脆弱なのか? - くろの雑記帳

                                                        きっかけ 昨年(2021年9月ごろ)に徳丸さんのこのツイートを見て、「2022年にはJWTを用いたセッション管理に代表される、ステートレスなセッション管理は世の中に受け入れられなくなっていくのだろうか?」と思っていました。 OWASP Top 10 2021 A1に「JWT tokens should be invalidated on the server after logout.」(私訳:JWTトークンはログアウト後にサーバー上で無効化すべきです)と書いてあるけど、どうやって無効化するんだ? ブラックリストに入れる?https://t.co/bcdldF82Bw— 徳丸 浩 (@ockeghem) 2021年9月10日 JWT大好きな皆さん、ここはウォッチしないとだめですよ。これがそのまま通ったら、ログアウト機能でJWTの即時無効化をしていないサイトは脆弱性診断で「OWASP Top

                                                          サーバサイドでJWTの即時無効化機能を持っていないサービスは脆弱なのか? - くろの雑記帳
                                                        • 「Amazonを不正利用された」──SNS上で報告相次ぐ 「二段階認証を突破された」などの声も

                                                          「Amazon.co.jpを不正利用された」──X(元Twitter)では9月上旬からそんな投稿が相次いでいる。「Amazonギフトカードを大量購入された」「二段階認証を設定していたのに、それを突破された」などの報告が上がっている。 Xでは「(アカウントに)二段階認証を設定していたにもかかわらず不正アクセスされ、Amazonギフトカードを大量に購入された」と被害を訴える声が多く見られる。特に話題になっているユーザーの投稿によると「注文履歴を非表示にされ、不正利用に気が付かないままクレジットカードの請求が来た」と語っている。 このユーザーがAmazonのサポートに問い合わせしたところ「同様の案件が多発している」「現状では手口が分からないのでどうやって侵入してるのか調査中」などと返事があったという。その後、被害額は全て返金してもらったとしている。 Amazonではサイバーセキュリティ対策の一環

                                                            「Amazonを不正利用された」──SNS上で報告相次ぐ 「二段階認証を突破された」などの声も
                                                          • HerokuのOAuthトークン流出で、やっておくといいことリスト(コメント大歓迎)

                                                            2022年4月16日(日本時間)にアナウンスがあった、Heroku/Travis-CIのOAuthトークンの流出および悪用を受けて、ユーザーとしてやっておくといいことをまとめました。 GitHubのOrganizationのオーナー向けと個人向けで分けてあります。 追記: 複数の補足のコメントを頂き、記事にも取り込んでいます。ありがとうございます! 注意 執筆者はGitHub, Heroku, Travis-CIの専門家ではありません。この記事は誤っている可能性があります。 この記事は現在調査中の問題について書かれています。最新情報は必ず公式サイトをご確認ください。 GitHub Heroku Travis CI インシデントの概要 GitHubがHerokuとTravis-CIのOAuthアプリケーションに発行したトークンが流出・悪用したことで、それらの連携が有効だった多くのOrgani

                                                              HerokuのOAuthトークン流出で、やっておくといいことリスト(コメント大歓迎)
                                                            • パスキーとは--パスワードに代わる認証方法の基礎

                                                              おそらく、読者の皆さんも多くのパスワードを使っているはずだ。 パスワードマネージャーの助けを借りたとしても、パスワードはほとんどの人にとって、ますます大きな負担になっている。 p455w0rd123のようなばかげたパスワードを設定して、使い回すことのできた時代は、とっくに終わっている。現在では、すべてのオンラインアカウントを、複雑で一意のパスワードによって保護する必要がある。 さらに、多数のパスワードの1つが侵害された場合に備えて、常に警戒しておかなければならない。 もっと良い解決策が必要だ。実は、パスワードよりも優れた解決策が存在する。 それはパスキーだ。 パスキーとはどんなものなのか パスキーは、ウェブサイトとアプリの認証手段である。Appleが2022年6月に「iOS」と「macOS」でパスキー(同社の独自規格ではなく、普通名詞である)のサポートを追加したことで、広く知られるようにな

                                                                パスキーとは--パスワードに代わる認証方法の基礎
                                                              • Twitterのショートメールを使った2要素認証が2023年3月20日以降は有料に、無料のまま2要素認証を有効にする方法は?

                                                                Twitterはアカウントのセキュリティを強化するための方法として2要素認証(2FA)を提供しています。2FAでは「ショートメール」「認証アプリ」「セキュリティキー」の3つのいずれかを使って認証を行うこととなるのですが、このうちショートメールを使ったものを有料化するとTwitterが発表しました。 An update on two-factor authentication using SMS on Twitter https://blog.twitter.com/en_us/topics/product/2023/an-update-on-two-factor-authentication-using-sms-on-twitter Twitter to charge for SMS-based two-factor authentication - 9to5Google https://

                                                                  Twitterのショートメールを使った2要素認証が2023年3月20日以降は有料に、無料のまま2要素認証を有効にする方法は?
                                                                • 心臓の音で個人認証、精度95%以上 音のリズムやピッチを分析

                                                                  Innovative Tech: このコーナーでは、テクノロジーの最新研究を紹介するWebメディア「Seamless」を主宰する山下裕毅氏が執筆。新規性の高い科学論文を山下氏がピックアップし、解説する。 スペインのUniversity Carlos III of Madrid、イランのShahid Rajaee Teacher Training University、イランのInstitute for Research in Fundamental Sciences (IPM)による研究チームが開発した「ECGsound for human identification」は、心電図から取得した心拍音を分析し、その人が誰かを特定するバイオメトリクス技術だ。心電図(ECG)信号をオーディオ波形ファイルに変換し、5つの音楽的特性を分析することで識別する。 今回はこれまでと違い、ノイズ(直流成分や

                                                                    心臓の音で個人認証、精度95%以上 音のリズムやピッチを分析
                                                                  • パスワード不要の認証技術「パスキー」はパスワードよりもエクスペリエンスが悪いという批判

                                                                    FIDOアライアンスが仕様を策定した「パスキー」は、パスワードではなく生体情報を用いて認証する「FIDO 2.0」を「Webauthn」標準に基いて利用して得た資格認証情報をデバイス単位で管理運用する技術です。このパスキーが抱える問題点について、Webauthn標準に関わったエンジニアのFirstyearことウィリアム・ブラウン氏が自身のブログで解説しています。 Firstyear's blog-a-log https://fy.blackhats.net.au/blog/2024-04-26-passkeys-a-shattered-dream/ Webauthnがパスワードに代わる認証技術として大きな可能性を秘めていると考えていたブラウン氏は、2019年にオーストラリアからアメリカに渡り、友人と共にWebauthnのRust実装であるwebauthn-rsの開発を始めました。その過程で

                                                                      パスワード不要の認証技術「パスキー」はパスワードよりもエクスペリエンスが悪いという批判
                                                                    • GitHub、コード提供の全ユーザーに2要素認証(2FA)を義務付けへ 2023年末までに

                                                                      同氏によると、現在GitHubで2FAを使っているのは全アクティブユーザーの約16.5%のみ。傘下のnpmにいたっては、わずか6.44%のみという。 npmは2月、上位100のライブラリのメンテナに2FAを義務付けた。5月末までに上位500に拡大する計画だ。 関連記事 「ロシアをGitHubから切り離して」の意見に公式が返答 「私たちのビジョンは、全ての開発者のホームになること」 「GitHubからロシアを切り離して」──ロシアのウクライナ侵攻を受けて、このような件名の投稿がGitHub上に掲載された。さまざまな物議を醸したが、GitHubは「私たちのビジョンは、どこに住んでいても、全ての開発者のホームになることだ」と返答をした。 GitHub傘下のnpm、上位100のパッケージメンテナは2FA必須に GitHub傘下のパッケージリポジトリnpmは、上位100のライブラリのメンテナは2要素

                                                                        GitHub、コード提供の全ユーザーに2要素認証(2FA)を義務付けへ 2023年末までに
                                                                      • GitHubでhttpsのパスワード認証が廃止された。Please use a personal access token instead. - Qiita

                                                                        GitHubでhttpsのパスワード認証が廃止された。Please use a personal access token instead.GitGitHub $ git push origin branch名 remote: Support for password authentication was removed on August 13, 2021. Please use a personal access token instead. remote: Please see https://github.blog/2020-12-15-token-authentication-requirements-for-git-operations/ for more information. fatal: unable to access 'https://github.com/名前/リ

                                                                          GitHubでhttpsのパスワード認証が廃止された。Please use a personal access token instead. - Qiita
                                                                        • [2023-01-31 12:00 JST 更新] JWTのシークレットポイズニングに関する問題

                                                                          By Artur Oleyarsh January 10, 2023 at 12:33 AM Category: Cloud, Vulnerability Tags: CVE-2022-23529, exploit, open source, Prisma Cloud, remote code execution, Vulnerability Exploitation 2019年1月30日 PST 本脆弱性の悪用シナリオの前提条件に関するコミュニティからのフィードバックを受け、私たちはAuth0と協力してCVE-2022-23529を撤回することを決定しました。 本稿で解説したセキュリティの問題はJsonWebTokenライブラリが安全でない方法で使用された場合には依然として懸念されるものです。そのシナリオでは、すべての前提条件を満たせばこの問題を悪用できる可能性があります。私たちは、その

                                                                            [2023-01-31 12:00 JST 更新] JWTのシークレットポイズニングに関する問題
                                                                          • さよならパスワード マイクロソフト、顔認証など標準に - 日本経済新聞

                                                                            IT(情報技術)システムの認証からパスワードをなくす動きが広がっている。新型コロナウイルス下で在宅勤務が進む中、漏洩リスクが高いという見方が強まったためだ。米マイクロソフトはメール「アウトルック」やチャット「チームズ」といった自社アプリで顔認証などを標準とした。導入コストも下がり始め、多くの企業が脱パスワードを検討すべき時期を迎えた。スマートフォンに指をのせると、傍らのパソコンの画面が切り替わ

                                                                              さよならパスワード マイクロソフト、顔認証など標準に - 日本経済新聞
                                                                            • OAuth 2.1 の標準化が進められています - Qiita

                                                                              IETFのOAuth WGでは、今あるOAuth2.0関連の仕様を整理し、一つの仕様としてまとめなおし OAuth2.1 として標準化するとりくみが進められています。 今回は、簡単にOAuth2.1について紹介します。 OAuth 2.0 OAuth 2.0は2012年10月に「RFC6749 The OAuth 2.0 Authorization Framework」として標準化されています。その後、OAuth2.0の改善は続けられ、セキュリティ向上のために利用すべき機能(PKCE)などが追加されているほか、逆に非推奨になっている機能(Implicit Grant)などがあります。 IETFのOAuth WGではOAuth2.0を安全に利用するためのベストカレントプラクティスを「OAuth 2.0 Security Best Current Practice」としてまとめています。 この

                                                                                OAuth 2.1 の標準化が進められています - Qiita
                                                                              • SaaSをAzure ADでシングルサインオンを構成する流れをわかりやすくまとめてみた

                                                                                組織内でクラウドアプリケーションの導入が増え、 Azure AD で SSO することが増えました。感覚的には2021年比で数倍です。初めて設定した時は緊張しながら実施したものですが、数を積んでだいぶ慣れてきました。 依頼をもらって設定するのは、SAMLばかりです。そのSAMLをほかのメンバーでも対応できるようにしたいので、自分が説明するために流れをまとめてみました。アレコレ、端折ってますがご容赦を。 覚えておく サービスプロバイダ(SP):クラウドアプリケーション、SaaSのこと。IDプロバイダ(IdP):認証機能側。AzureADとか。 SP-Initiated:クラウドアプリケーションでログインしようとすると、IdPに飛んで、認可されたらクラウドアプリを開ける方法。入口はSP側にある。IdP-Initiated:IdPでログインしている状態で、指定のURLを開くと、クラウドアプリケー

                                                                                  SaaSをAzure ADでシングルサインオンを構成する流れをわかりやすくまとめてみた
                                                                                • Touch ID、Face IDに次ぐ第三の革命「Optic ID」 - iPhone Mania

                                                                                  Appleの複合現実(MR)ヘッドセットVision Proが2日米国で発売に至りましたが、同機では新たな認証システム「Optic ID」が導入されています。Optic IDはAppleの3番目の生体認証となります。 ■3行で分かる、この記事のポイント 1. AppleのMRヘッドセットVision Proで新たな認証システム「Optic ID」が導入された。 2. 安全な近赤外光で眼球を照らし、眼球カメラで虹彩の画像を撮影する。 3. 認証の際、登録された生体データとユーザーの虹彩が一致するかが判断される。 データはSecure Enclave内で処理 2013年に導入されたTouch IDは指紋により生体認証を行うものですが、2017年にiPhone Xで顔認証Face IDが新たに導入されました。 Face IDは最新のiPhoneでもデフォルトの認証システムとなっていますが、Vis

                                                                                    Touch ID、Face IDに次ぐ第三の革命「Optic ID」 - iPhone Mania