普通は役所のシステムって構築してから5年とか7年は塩漬けにして使うもので、一度やらかしてしまうと名誉挽回の機会なんて向こう数年は与えられないんだけど、こと本件に関しては高市総務大臣から「今すぐ私がマニュアルなしでも使えるように直しなさい」と叱責いただいて、しっかりと予算的なサポートも得られたことで、たったの数ヶ月で立て直すことができた。 この数ヶ月は外部のセキュリティやPKIの専門家の方から様々なサポートをいただいて何とか実現したんだけれども、役所のシステム開発としては非常識というか、極めて難易度が高い案件だった。「え？単にChromeやSafariをサポートするだけでしょ、難しい訳ないじゃん」と思う諸兄は、もうしばらくこの話に付き合って欲しい。 もともとマイナポータルは日本を代表するITベンダーと通信キャリアの3社が開発したんだけど、大臣からの叱責を受け「ちゃんとお金を払うから直してよ」
Intro Cookie は、ブラウザに一度保存すれば、次からその値を自動的に送ってくるという、非常に都合の良い仕様から始まった。 State Less が基本だった Web にセッションの概念をもたらし、今ではこれが無ければ実現できないユースケースの方が多い。 冷静に考えればふざけてるとして思えないヘッダ名からもわかるように、当初はこのヘッダがこんなに重宝され、 Web のあり方を変えるかもしれないくらい重要な議論を巻き起こすことになるとは、最初の実装者も思ってなかっただろう。 そんな Cookie が今どう使われ、 3rd Party Cookie (3rdPC) の何が問題になっているのかを踏まえ、これからどうなっていくのかについて考える。 Cookie のユースケース Web にある API の中でも Cookie はいくつかの点で特異な挙動をする 一度保存すれば、次から自動で送る
ユーザー アカウント、認証、パスワード管理に関する 13 のベスト プラクティス2021 年版 | Google Cloud 公式ブログ
※この投稿は米国時間 2021 年 5 月 7 日に、Google Cloud blog に投稿されたものの抄訳です。 2021 年用に更新: この投稿には、Google のホワイトペーパー「パスワード管理のベスト プラクティス」のユーザー向けとシステム設計者向けの両方の最新情報を含む、更新されたベスト プラクティスが含まれています。 アカウント管理、認証、パスワード管理には十分な注意を払う必要があります。多くの場合、アカウント管理は開発者や製品マネージャーにとって最優先事項ではなく、盲点になりがちです。そのため、ユーザーが期待するデータ セキュリティやユーザー エクスペリエンスを提供できていないケースがよくあります。 幸い、Google Cloud には、ユーザー アカウント（ここでは、システムに対して認証を受けるすべてのユーザー、つまりお客様または内部ユーザー）の作成、安全な取り扱い、
note のやらかしのあのへんについて。 認証自作、 Rails 、 Devise - Diary パーフェクト Rails 著者が解説する devise の現代的なユーザー認証のモデル構成について - joker1007’s diary 認証サーバーの実装は本質的に難しいです。セキュリティが絡むものは「簡単な実装」などなく、プロアマ個人法人問わず、個人情報を守るという点で、同じ水準を要求されます。悪意あるハッカーは常にカモを探していて、もし認証が破られた場合、自分だけではなく大多数に迷惑が掛かります。初心者だから免責されるといったこともありません。全員が同じ土俵に立たされています。 とはいえ、認証基盤を作らないといろんなサービスが成立しません。そういうときにどうするか。 Firebase Authentication で、タイトルの件なんですが、 Firebase Authenticat
認証と認可の超サマリ OAuth とか OpenID Connect とか SAML とかをまとめてざっと把握する本
認証と認可についての知識が必要になったので、基礎的なことを学んでいます。 一切何も知らない状態から手当たり次第に細かく調べるのは大変だったので、超サマリを整理してみようと思います。 この本は「個々の要素に詳しくなる必要はないんだけど、概要くらいはさっと把握しておきたい」とか「手当たり次第に詳細調査をする前に、一瞥してこれから踏み込もうとしている領域の超俯瞰マップを作る」という感じで使うことを想定しています。 同じ様な方の役に立ったら、とても嬉しいです。 この本は筆者の理解に連動して追記修正される可能性があります。
pictBLandとpictSQUAREに対する不正アクセスがあり、パスワードがソルトなしのMD5ハッシュで保存されていたことが話題になっています。 2023年8月16日に外部のフォーラムにpictSQUAREより窃取した情報と主張するデータ販売の取引を持ち掛ける投稿が行われた（中略）パスワードはMD5によるハッシュ化は行われているもののソルト付与は行われていなかったため、単純なパスワードが使用されていた29万4512件は元の文字列が判明していると投稿。（それ以外の26万8172件はまだMD5ハッシュ化されたままと説明。） 不正アクセスによるpictBLand、pictSQUAREの情報流出の可能性についてまとめてみた - piyolog より引用 これに関連してMD5ハッシュやソルトに関するツイート(post)を観察したところ、どうもソルトの理解が間違っている方が多いような気がしました。
こんばんは。ritouです。 Digital Identity技術勉強会 #iddance Advent Calendar 2020 1日めの記事です。 qiita.com 初日なのでゆるふわな話をしましょう。 何の話か もうだいぶ前ですね。9月のお話です。こんなTweetを見かけました。 社内Slackにいる「OAuth認証」と書くと訂正してくれるbotが丁寧な解説をするようになっていた 認証(Authentication)と認可(Authorization)は間違えやすいわりにミスると甚大な被害をもたらしがちなので、常日頃から意識を高めていきたいですね pic.twitter.com/oVQxBgZcHS— greenspa (@greenspa) 2020年9月28日 このbotに対する思うところはもう良いです。 今回は、「OAuthの仕様に沿ってID連携を実装するいわゆる"OAut
HTML5のLocal Storageを使ってはいけない（翻訳）｜TechRacho by BPS株式会社
概要 原著者の許諾を得て翻訳・公開いたします。 英語記事: Randall Degges - Please Stop Using Local Storage 原文公開日: 2018/01/26 著者: Randall Degges 日本語タイトルは内容に即したものにしました。 画像は元記事からの引用です。 初版公開: 2019/10/19 追記更新: 2024/04/05 -- リンク情報を記事末尾に移動しました 本気で申し上げます。local storageを使わないでください。 local storageにセッション情報を保存する開発者がこれほど多い理由について、私にはさっぱり見当がつきません。しかしどんな理由であれ、その手法は地上から消えてなくなってもらう必要がありますが、明らかに手に負えなくなりつつあります。 私は毎日のように、重要なユーザー情報をlocal storageに保存す
はじめに X.509 証明書について解説します。(English version is here → "Illustrated X.509 Certificate") ※ この記事は 2020 年 7 月 1 日にオンラインで開催された Authlete 社主催の『OAuth/OIDC 勉強会【クライアント認証編】』の一部を文書化したものです。勉強会の動画は公開しており、X.509 証明書については『#4 X.509 証明書（１）』と『#5 X.509 証明書（２）』で解説しているので、動画解説のほうがお好みであればそちらをご参照ください。 1. デジタル署名（前提知識） この記事を読んでいただくにあたり、デジタル署名に関する知識が必要となります。つまり、「秘密鍵を用いて生成された署名を公開鍵で検証することにより」、「対象データが改竄されていないこと」や「秘密鍵の保持者が確かに署名したこと
日々権限設計で頭を抱えてます。この苦悩が終わることは無いと思ってますが、新しい課題にぶつかっていくうちに最初のころの課題を忘れていきそうなので、現時点での自分の中でぐちゃぐちゃになっている情報をまとめようと思い、記事にしました。 所々で「メリット」「デメリット」に関連する情報がありますが、そのときそのときには色々と感じることがあっても、いざ記事にまとめるときに思い出せないものが多々ありました。フィードバックや自分の経験を思い出しながら随時更新する予定です。 TL;DR（長すぎて読みたくない） 想定する読者や前提知識 この記事での権限とは 権限の種類 ACL(Access Control List) RBAC(Role-Based Access Control) ABAC(Attribute-Based Access Control) どの権限モデルを採用するべきか 権限を適用する場面 機能
やはりお前らの「公開鍵暗号」はまちがっている。
※タイトルの元ネタは以下の作品です。 はじめに この記事は、公開鍵暗号の全体感を正しく理解するためのものです。数学的な部分や具体的なアルゴリズムは説明しません。気になる方は最後に紹介するオススメ書籍をご覧ください。 少し長いですが、図が多いだけで文字数はそこまで多くありません。また、専門的な言葉はなるべく使わないようにしています。 ただしSSHやTLSといった通信プロトコルの名称が登場します。知らない方は、通信内容の暗号化や通信相手の認証（本人確認）をするためのプロトコルだと理解して読み進めてください。 公開鍵暗号の前に：暗号技術とは 公開鍵暗号は暗号技術の一部です。暗号と聞くと、以下のようなものを想像するかもしれません。 これは情報の機密性を守るための「暗号化」という技術ですが、実は「暗号技術」と言った場合にはもっと広い意味を持ちます。まずはこれを受けて入れてください。 念のため補足して
Firebase入門 フリマアプリを作りながら、認証・Firestore・Cloud Functionsの使い方を学ぼう！ - エンジニアHub｜Webエンジニアのキャリアを考える！
エンジニアHub > 記事一覧 > Firebase入門 フリマアプリを作りながら、認証・Firestore・Cloud Functionsの使い方を学ぼう！ Firebase入門 フリマアプリを作りながら、認証・Firestore・Cloud Functionsの使い方を学ぼう！ Firebaseでは、バックエンドやインフラに精通したメンバーがいなくても、モバイルやWebフロントの開発に集中できます。Authentication、Firestore、Cloud Functions、さらにセキュリティルールまで、クックパッドの岸本卓（@_sgr_ksmt）さんが、実践的に解説します。
攻撃に立ち向かうイヌさんThe English version is available here. タイトル訂正: 「自作サービス『に』→『が』DDoS攻撃された話」「それはDDoSではない」という指摘に関して末尾に追記 (6/18)SaaSを開発していると本当にいろんな事が起こります。それらは時に開発者に喜びや悲しみ、怒り、感謝、落胆や興奮をくれます。思い返してみれば結局はみんないい思い出になるものです。先週末に、拙作の小さなウェブサービスがDDoS攻撃を受けました。言わずもがな、悪い出来事です。本稿ではこの事故がどんなものだったのか、どうやって対処したのかについてお話します。 どうもTAKUYAです。僕はInkdropというクロスプラットフォームなMarkdownノートアプリを独りで3年以上開発・運用しています。ユーザ数2万人以下のとてもニッチなSaaSで、僕はこのサービスで生計を立
こんにちは。エムスリー・QLife(エムスリーのグループ会社)・エムスリーヘルスデザイン(エムスリーのグループ会社)でエンジニアとして各種作業に関わっている山本です！ 以前もメール送信の話を書かせていただいたことがありますが、今回もまたメールネタとなります。今回のお題はメールセキュリティです。 大量メール送信のための予備知識 - エムスリーテックブログ すでにご覧になった方もいるかと思いますが、次のようなニュースが流れています。 www.proofpoint.com この「GoogleとYahooの新Eメール認証要件」ってつまりどういうことよ？ というところを具体的にどのように進めているかについて書かせていただきたいと思います。 2023/12/18追記 : Googleからメール送信にTLSを使うことが追加要件として示されました。 TL;DR とりあえず何から始める？ 何はともあれ実際に
世界一わかりみの深いOAuth入門
滅びてほしい認証系の実装の話
こんにちは、富士榮です。 ちょっと前に某所でダメダメな認証系の技術実装ってなんだろうねぇ、、という話をしていたことをXで呟いたところ、色々とご意見を頂けましたのでまとめて書いておきます。 考えていると結局のところ、サービス提供側が意図していることとは全然違うことが起きている気がするので、この辺はしっかり考えて実装したいところですね。（実装ミスは問題外として） カテゴリ滅びてほしいもの実装側がやりたいこと利用者が感じること実際に起きていること代替手法認証CAPTCHAbot避けぐにゃぐにゃ文字が読めない バイクと自転車の違いとは？ユーザの離脱、カゴ落ちパスキーの利用 新しいタイプのCAPTCHA（通常は画面に出ない） リスクベース認証との組み合わせによる抑制認証パスワード誰でも使える認証手段の用意忘れる。複雑なパスワードをそれぞれのサービス毎に管理するのは無理パスワードの使い回し。パスワード
はじめに こんにちは。株式会社Flatt Securityセキュリティエンジニアの村上 @0x003f です。 本稿では、Webアプリケーション上で実装される「ログイン機能」の実装パターンをいくつか示し、その「仕様の中で起きうる脆弱性」とその対策について解説していきます。 「ログイン機能」はToB、ToC問わず多くのWebアプリケーションで実装されている機能で、XSSやSQL Injection、Session Fixationといったような典型的な脆弱性の観点については、なんらかの解説を見たことのある方も多いと思います。 しかし、「仕様の脆弱性」というのはあまり多く語られていない印象です。今回はそのようなタイプの脆弱性についての解説を行います。なお、IDaaSを用いずに自前でログイン機能を実装しているケースを複数パターン想定しています。 はじめに ログイン機能の仕様パターンとセキュリティ
パーフェクトRails著者が解説するdeviseの現代的なユーザー認証のモデル構成について - joker1007’s diary
最近、パーフェクトRuby on Railsの増補改訂版をリリースさせていただいた身なので、久しぶりにRailsについて書いてみようと思う。 まあ、書籍の宣伝みたいなものです。 数日前に、noteというサービスでWebフロント側に投稿者のIPアドレスが露出するという漏洩事故が起きました。これがどれぐらい問題かは一旦置いておいて、何故こういうことになるのか、そしてRailsでよく使われるdeviseという認証機構作成ライブラリのより良い使い方について話をしていきます。 (noteがRailsを使っているか、ここで話をするdeviseを採用しているかは定かではないので、ここから先の話はその事故とは直接関係ありません。Railsだったとしても恐らく使ってないか変な使い方してると思うんですが、理由は後述) 何故こんなことが起きるのか そもそも、フロント側に何故IPアドレスを送ってんだ、という話です
米Googleの「Workspace」を含む同社の多くのサービスが12月14日の午後9時ごろから約45分間使えなくなっていた障害の原因は、各種サービスにログインするための認証ツールのストレージクォータの問題だったと、Googleが同日、英Guardianなどのメディアに声明文を送った。 Googleの広報担当者によると、このダウンの原因は、Googleとサードパーティのサービスへのログイン方法を管理する認証ツールの障害だったという。認証を処理するサービスのためのストレージが不足すると自動的に割当を増やす（ストレージクォータ）ツールが正常に動作しなかった。 この問題により、GmailやGoogleカレンダーなど、利用するためにログインが必要なサービスが利用できなくなった。また、Googleの認証プラットフォームを利用するサードパーティのサービスでも、ユーザーがログインできなくなっていた。Go
このツイートを見て、「アプリで再ログインを頻繁要求されるってユーザビリティ良くないな。」と思ったのですが、普段裏側の仕組みは意識していなかったりテックリードの方に任せきりだったりしていたので、これを機に調べてみました。 そもそもスマホアプリ の時代、もはやauthenticationですらないと思うのよね。（何を言ってるかわからねえだろうと思うが。） — Hiromitsu Takagi (@HiromitsuTakagi) 2019年7月8日 この記事は「アプリでログインしっぱなしは、どのように実現されるの？」という疑問と調べた結果を共有するために書いていきます。 間違いや「もっとこんな仕組みが使われてるよ！」等のツッコミがあれば、どしどし貰えると助かります！ 疑問1. アクセストークンという仕組みとは？ 「なぜアクセストークンという概念が必要なのか？」 モバイルアプリでユーザー認証をし
SPAのログイン認証のベストプラクティスがわからなかったのでわりと網羅的に研究してみた〜JWT or Session どっち？〜 - Qiita
SPAのログイン認証のベストプラクティスがわからなかったのでわりと網羅的に研究してみた〜JWT or Session どっち？〜JavaScriptRailsJWT認証React SPAのログイン周りについて、「これがベストプラクティスだ！」という情報があまり見当たらないので、様々な可能性を模索してみました。 いろいろな状況が想定され、今回記載する内容に考慮の漏れや不備などがありましたら是非コメントでご指摘いただきたいです！特に「おすすめ度：○」と記載しているものに対しての批判をどしどしお待ちしております！ この記事でおすすめしているものであっても、ご自身の責任で十分な検討・検証の上で選択されてください。 前提 想定しているAPIは、 ログイン外のAPIにはPOST/PUT/DELETEのものがなく、GETのみ GETのAPIにはDBを更新するなどの操作がない とし、そのためログイン外では
しばたです。 昨年10月にGoogle(Gmail)および米国Yahoo!においてスパム対策の強化がアナウンスされました。 この件に関してつい先日まで他人事でいたのですが、実は全然他人事では済まないことが発覚し突貫で知識を仕入れています。 アナウンスに対する具体的な対応策についてはこちらのZennの記事を見れば全部わかる感じです。 最高ですね。 また、メール送信にAmazon SESを使っている場合はAWSのブログを確認すると良いでしょう。 「これらの記事を読み解けば万事解決！」という感じではあるのですが、私自身が学んだなかで予め知っておくと良さそうに思えた点がいくつかありました。 本記事ではその辺を共有するのと、実際にAmazon SESの環境を作って動作確認をしたのでその結果も合わせて共有します。 はじめに覚えておくと良い基礎知識 Zennの記事でも詳細な解説がありますが、個人的に「最
高木浩光＠自宅の日記 - 天動説設計から地動説設計へ：7payアプリのパスワードリマインダはなぜ壊れていたのか（序章）
■ 天動説設計から地動説設計へ：7payアプリのパスワードリマインダはなぜ壊れていたのか（序章） 7payの方式はなぜ許されないのか、なぜあんな設計になってしまったのか、どう設計するのが正しいのか、急ぎ書かなくてはいけないのだが、前置きが長くなっていつ完成するかも見えない。取り急ぎ以下のツイートでエッセンスを示しておいた*1が、すでにわかりかけている人達にしか刺さらなそうだ。 そもそもスマホアプリ の時代、もはやauthenticationですらないと思うのよね。（何を言ってるかわからねえだろうと思うが。） — Hiromitsu Takagi (@HiromitsuTakagi) July 8, 2019 同様のことは4年前にNISCのコラムに書いたが、消えてしまっているので、ひとまず、その原稿を以下に再掲しておく。 スマホ時代の「パスワード」のあり方を再考しよう 高木浩光 2015年2
マイクロサービスにおける認証と認可の、一般論としての設計パターンを調べたところ、Web 上の複数の記事で似たようなパターンが登場していた。ここでは、まず認証と認可が実現したい一般的な要件と、そのマイクロサービスでの難しさを整理し、認証と認可に分けて調査したパターンをまとめた。 あくまで “一般論” なので、実際には個々のドメインにあわせてアレンジが必要 往々にしてこの “アレンジ” に価値が宿るものだが、まずはセオリーを知っておきたいというモチベーションで調査した Web 上の記事を読んでまとめただけなので、手を動かしての確認はしておらず、理解が甘い部分はご容赦ください 具体的な通信方式やサービス間通信のセキュリティといった具体論までは踏み込めていない。このへんはサービスメッシュやゼロトラストネットワークといったトピックが登場すると思われる これらは次回以降の Todo としています その
秒間100万リクエストをさばく - Googleの共通認可基盤 Zanzibar - 発明のための再発明
はじめに Googleの提供するサービス郡が共通して利用している認可システムにはZanzibarという名前がついています。ZanzibarはGoogleDrive・Google Map・Youtubeなどの巨大なサービスにも使用されています。 そのため、利用量も凄まじく 数10億のユーザー 数兆のACL(access control list) 秒間100万リクエスト もの量をさばいています。 にも関わらず、Zanzibarはこれを10ミリ秒以内に返します(95パーセンタイル)。 この記事では、そんなZanzibarの内部構造に関する論文「Zanzibar: Google’s Consistent, Global Authorization System」の中から、主に大量のリクエストをさばくための工夫を紹介します。 ちなみに、以前Googleの社内システム用の認可システム「Beyond
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session.
パスワードレスな認証方式である「パスキー」が急速に普及しています。OS、ブラウザ、パスワード管理ツール、サービス提供者のどれもが整いつつあり、ついに本当にパスワードが必要ない世界がやってきたことを感じます。この記事では、本腰を入れてパスキーを使い始めて快適になるまでの様子をまとめます。技術的な厳密さ・網羅性には踏み込まず、いちユーザーとしての入門記事という位置付けです。 パスキーとは パスキー - Wikipedia 認証、セキュリティに関しては門外漢なので、Wikipediaのリンクを置いておきます。私よりはWikipediaのほうが信用に足るでしょう。 そこから辿れるホワイトペーパー：マルチデバイス対応FIDO認証資格情報を読むと、多少ストーリーもわかります。FIDO2というデバイスに格納された秘密鍵に依存したパスワードレス認証の仕様に、暗号鍵（と訳されていますが秘密鍵のことで良い……
このツイートを見て、「アプリで再ログインを頻繁要求されるってユーザビリティ良くないな。」と思ったのですが、普段裏側の仕組みは意識していなかったりテックリードの方に任せきりだったりしていたので、これを機に調べてみました。 そもそもスマホアプリ の時代、もはやauthenticationですらないと思うのよね。（何を言ってるかわからねえだろうと思うが。） — Hiromitsu Takagi (@HiromitsuTakagi) 2019年7月8日 この記事は「アプリでログインしっぱなしは、どのように実現されるの？」という疑問と調べた結果を共有するために書いていきます。 間違いや「もっとこんな仕組みが使われてるよ！」等のツッコミがあれば、どしどし貰えると助かります！ 疑問1. アクセストークンという仕組みとは？ 「なぜアクセストークンという概念が必要なのか？」 モバイルアプリでユーザー認証をし
SPA認証トークンはlocalStorageでもCookieでもない、Auth0方式はいいねというお話 - @mizumotokのブログ
SPA認証トークンをどこに保存するかは論争が絶えません。localStorageやCookieがよく使われますが、Auth0は違う方法を採用しています。この記事では、Auth0のトークン管理の方式を理解でき、トークン管理上のセキュリティへの理解を深めることができます。 SPAの認証トークンをどこに保存するか ブラウザでトークンを保存できる場所 保存場所の比較 メリット・デメリット Auth0のアプローチ トークンはインメモリに保存 OpenID Connect準拠とトークン取得のUI/UXの悪化回避を両立 Auth0のjsライブラリ ログイン アクセストークンの（再）取得 図解 ログイン アクセストークンの（再）取得 自サービス内の認証だけのもっと簡易な構成 ログイン IDトークン取得 まとめ SPAの認証トークンをどこに保存するか React やVueで認証付きSPA（Single Pa
モニクル社内3分LTで発表しました。技術職以外の人向けに話したので、抽象度高めにしてあります。
不正アクセスによるIDとパスワードの漏洩を受けて、MD5によるハッシュ化について話題になっていました。システムを作る上で、パスワードの管理や認証はどう設計すべきかを考えるために、少し整理をしてみます。もし事実誤認があれば、どしどしご指摘ください。 == 2023/8/21追記 == この記事は、ハッシュの保存の仕方一つとっても、沢山の対策方法が必要であるということをお伝えするために記載しています。そして、これから紹介する手法を取れば安全とお勧めしている訳ではないので、その点をご留意いただければと思います。攻撃手法に応じての対応策の変遷を知っていただくことで、セキュリティ対策は一度行えば安全というものではないことを知って頂くキッカケになれば幸いです。 == 追記終わり == パスワードのハッシュ化 まず最初にパスワードの保存方法です。何も加工しないで平文で保存するのは駄目というのは、だいぶ認
認証しないWeb認証 限定公開URLのセキュリティについて考える 2020/8/7 API Meetup Online #3- フューチャー株式会社 渋川よしき
GTA新作リークに使われた“多要素認証疲れ”攻撃とは 1時間以上通知攻め、従業員の根負け狙う：この頃、セキュリティ界隈で 人気ゲーム「グランド・セフト・オート」（GTA）などを手掛けるゲームメーカーの米Rockstar Gamesや米Uber Technologiesのネットワークが不正侵入を受け、情報が流出する事件が相次いだ。同じような被害は過去にMicrosoftやCisco、Twitterなどの大手でも発生している。各社とも、そうした侵入を防ぐために多要素認証を設定して従業員のアカウントを保護していたが、攻撃者は「MFA Fatigue（多要素認証疲れ）」攻撃と呼ばれる手口を使ってMFA（多要素認証）を突破していた。 多要素認証で守られたアカウントは、ユーザー名とパスワードを入力してログインしようとすると、登録された端末に電話をかけたりプッシュ通知を送信したりする方法で、そのログイン
ritouです。このしずかなインターネットにおける初投稿です。 おそらく、このしずかなインターネットのID連携では次のような設計になっていま「した」。問い合わせをさせていただき、対応いただきました。 これまでもQiitaなどで同様の実装例が紹介されていた際にはコメントさせていただいていたものですので、アンチパターンの紹介記事として読んでいただければと思います。 「Googleアカウントでログイン」ではじめると、ユーザーが作成され、Googleから受け取ったメールアドレス([email protected])が設定される 次回から「Googleアカウントでログイン」をすると、Googleから受け取ったメールアドレスでユーザーを参照 試しに、次のような流れで動作を確認してみます。 「Googleアカウントでログイン」でアカウント作成([email protected]) 「メールアドレス変更」
社内向け勉強会で発表した内容です。 30分でと書いてありますが、実際には50分かかりました。 また時間の関係で結構省いたりしている箇所があります。 2020/07/19追記 ご指摘をいただいた箇所を多々修正いたしました。 特にOIDCとSPAの章が初版とは大幅に変更されていますのでご注意ください。 Twitter: @DddEndow
この本の概要 テレビ会議やリモートワークが普及する中，情報を守る暗号や本人確認のための認証技術の重要性が増しています。本書は公開鍵暗号や署名などの理論を基礎から詳しく解説し，TLS1.3やHTTP/3，FIDOなどの新しい技術も紹介します。更にブロックチェーンで注目されている秘密計算，ゼロ知識証明，量子コンピュータなど最先端の話題も扱います。 こんな方におすすめ 暗号と認証の基礎を学習したい人 Web担当者やセキュリティ担当者など 1章 暗号の基礎知識 01 情報セキュリティ 情報セキュリティの三要素 情報セキュリティと暗号技術 利便性とコスト 追加された要件 02 暗号 暗号とは よい暗号と使い方 暗号の動向を知る 03 認証 パスワードによる認証 パスワード攻撃者の能力 パスワードの攻撃手法 認証の分類 認可 OAuth 04 古典暗号 シフト暗号 換字式暗号 符号化 2章 アルゴリズ
2023/10/05 Offersさんのイベントでの資料です。 https://offers.connpass.com/event/295782/ イベント後の満足度アンケート（5点満点）の結果は以下になります。 5点: 49% 4点: 39% 3点: 8% 2点: 4% こちらのスライドの内容は以下の本の抜粋になります。デモの内容、このスライドでは触れていないことについてご興味ある場合は以下の本をご参照ください。 https://authya.booth.pm/items/1296585 https://authya.booth.pm/items/1550861 本発表で扱っていないセキュリティに関しては以下の本がおすすめです。 https://authya.booth.pm/items/1877818 本の評判 https://togetter.com/li/1477483
はじめに この記事では、OAuth 2.0 の『クライアント認証』について説明します。 RFC 6749 に記述されているクライアント認証方式のほか、クライアントアサーションやクライアント証明書を用いるクライアント認証方式についても説明します。 1. クライアント認証方式 1.1. トークンエンドポイント 認可サーバーがあります。 認可サーバーからアクセストークンの発行を受けたいクライアントアプリケーションがあります。 アクセストークンは、幾つかの例外を除き、認可サーバーのトークンエンドポイントから発行されます。そのため、認可サーバーはトークンエンドポイントを用意します。 クライアントアプリケーションは、アクセストークンの発行を受けるために、トークンエンドポイントにトークンリクエストを投げます。 認可サーバーは、トークンレスポンスを返します。この応答の中に、アクセストークンが含まれます。
JWTセキュリティ入門
SECCON Beginners Live 2023「JWTセキュリティ入門」の発表資料です。
パスキーの基本とそれにまつわる誤解を解きほぐす
2023 年は文句なく「パスキー元年」になりました。非常にたくさんのサービスがパスキーに対応し、2024 年はいよいよパスキー普及の年になりそうです。 本記事では、パスキーの基本を振り返ったうえで、パスキーでみなさんが勘違いしやすい点について解説します。 2023 年は本当にたくさんのウェブサイトがパスキーに対応しました。例を挙げます: Adobe Amazon Apple eBay GitHub Google KDDI Mercari Mixi MoneyForward Nintendo NTT Docomo PayPal Shopify Toyota Uber Yahoo! JAPAN もちろんこのリストですべてではないですが、これらだけでも、世界人口のかなりをカバーできるはずで、まさに大躍進と言えます。もしまだパスキーを体験していないという方がいたら、ぜひこの機会にお試しください。
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
何故お役所ってオワコンIEが大好きなの？｜楠 正憲（デジタル庁統括官）
牧歌的 Cookie の終焉 | blog.jxck.io
ちょっとでもセキュリティに自信がないなら、 Firebase Authentication を検討しよう
ソルト付きハッシュのソルトはどこに保存するのが一般的か - Qiita
OAuth認証とは何か?なぜダメなのか - 2020冬 - r-weblife
図解 X.509 証明書 - Qiita
アプリケーションにおける権限設計の課題 - kenfdev’s blog
自作サービスがDDoS攻撃された話 - 週休７日で働きたい
Gmailのメール認証規制強化への対応って終わってますか？ - エムスリーテックブログ
世界一わかりみの深いOAuth入門
Webサービスにおけるログイン機能の仕様とセキュリティ観点 - Flatt Security Blog
Googleの45分間ダウンの原因は認証ツールのストレージクォータの問題
アプリで「ログインしっぱなし」はどのように実現されているか？ - Qiita
突貫でおぼえるSPF、DKIM、DMARC | DevelopersIO
Microservices における認証と認可の設計パターン
各社のログインAPIで返ってくるIDは何であるのかと、PPIDの現状について
パスキーが快適すぎる - yigarashiのブログ
アプリで「ログインしっぱなし」はどのように実現されているか？ - Qiita
次世代Web認証「パスキー」 / mo-zatsudan-passkey
何故パスワードをハッシュ化して保存するだけでは駄目なのか？ - NRIネットコムBlog
認証しないWeb認証 限定公開URLのセキュリティについて考える 公開版
GTA新作リークに使われた“多要素認証疲れ”攻撃とは 1時間以上通知攻め、従業員の根負け狙う
メールアドレスをキーにしてID連携を行う設計の危うさ｜ritou
30分でOpenID Connect完全に理解したと言えるようになる勉強会
図解即戦力 暗号と認証のしくみと理論がこれ1冊でしっかりわかる教科書
仕様が読めるようになるOAuth2.0、OpenID Connect 入門
OAuth 2.0 クライアント認証 - Qiita
trunk-room.hatenablog.com
cherio199.blog.fc2.com
www.google.com
anond.hatelabo.jp
togetter.com
vitup.jp