並び順

ブックマーク数

期間指定

  • から
  • まで

1 - 40 件 / 218件

新着順 人気順

openidの検索結果1 - 40 件 / 218件

  • ソルト付きハッシュのソルトはどこに保存するのが一般的か - Qiita

    pictBLandとpictSQUAREに対する不正アクセスがあり、パスワードがソルトなしのMD5ハッシュで保存されていたことが話題になっています。 2023年8月16日に外部のフォーラムにpictSQUAREより窃取した情報と主張するデータ販売の取引を持ち掛ける投稿が行われた(中略)パスワードはMD5によるハッシュ化は行われているもののソルト付与は行われていなかったため、単純なパスワードが使用されていた29万4512件は元の文字列が判明していると投稿。(それ以外の26万8172件はまだMD5ハッシュ化されたままと説明。) 不正アクセスによるpictBLand、pictSQUAREの情報流出の可能性についてまとめてみた - piyolog より引用 これに関連してMD5ハッシュやソルトに関するツイート(post)を観察したところ、どうもソルトの理解が間違っている方が多いような気がしました。

      ソルト付きハッシュのソルトはどこに保存するのが一般的か - Qiita
    • Gmailのメール認証規制強化への対応って終わってますか? - エムスリーテックブログ

      こんにちは。エムスリー・QLife(エムスリーのグループ会社)・エムスリーヘルスデザイン(エムスリーのグループ会社)でエンジニアとして各種作業に関わっている山本です! 以前もメール送信の話を書かせていただいたことがありますが、今回もまたメールネタとなります。今回のお題はメールセキュリティです。 大量メール送信のための予備知識 - エムスリーテックブログ すでにご覧になった方もいるかと思いますが、次のようなニュースが流れています。 www.proofpoint.com この「GoogleとYahooの新Eメール認証要件」ってつまりどういうことよ? というところを具体的にどのように進めているかについて書かせていただきたいと思います。 2023/12/18追記 : Googleからメール送信にTLSを使うことが追加要件として示されました。 TL;DR とりあえず何から始める? 何はともあれ実際に

        Gmailのメール認証規制強化への対応って終わってますか? - エムスリーテックブログ
      • 滅びてほしい認証系の実装の話

        こんにちは、富士榮です。 ちょっと前に某所でダメダメな認証系の技術実装ってなんだろうねぇ、、という話をしていたことをXで呟いたところ、色々とご意見を頂けましたのでまとめて書いておきます。

          滅びてほしい認証系の実装の話
        • 突貫でおぼえるSPF、DKIM、DMARC | DevelopersIO

          しばたです。 昨年10月にGoogle(Gmail)および米国Yahoo!においてスパム対策の強化がアナウンスされました。 この件に関してつい先日まで他人事でいたのですが、実は全然他人事では済まないことが発覚し突貫で知識を仕入れています。 アナウンスに対する具体的な対応策についてはこちらのZennの記事を見れば全部わかる感じです。 最高ですね。 また、メール送信にAmazon SESを使っている場合はAWSのブログを確認すると良いでしょう。 「これらの記事を読み解けば万事解決!」という感じではあるのですが、私自身が学んだなかで予め知っておくと良さそうに思えた点がいくつかありました。 本記事ではその辺を共有するのと、実際にAmazon SESの環境を作って動作確認をしたのでその結果も合わせて共有します。 はじめに覚えておくと良い基礎知識 Zennの記事でも詳細な解説がありますが、個人的に「最

            突貫でおぼえるSPF、DKIM、DMARC | DevelopersIO
          • パスキーが快適すぎる - yigarashiのブログ

            パスワードレスな認証方式である「パスキー」が急速に普及しています。OS、ブラウザ、パスワード管理ツール、サービス提供者のどれもが整いつつあり、ついに本当にパスワードが必要ない世界がやってきたことを感じます。この記事では、本腰を入れてパスキーを使い始めて快適になるまでの様子をまとめます。技術的な厳密さ・網羅性には踏み込まず、いちユーザーとしての入門記事という位置付けです。 パスキーとは パスキー - Wikipedia 認証、セキュリティに関しては門外漢なので、Wikipediaのリンクを置いておきます。私よりはWikipediaのほうが信用に足るでしょう。 そこから辿れるホワイトペーパー:マルチデバイス対応FIDO認証資格情報を読むと、多少ストーリーもわかります。FIDO2というデバイスに格納された秘密鍵に依存したパスワードレス認証の仕様に、暗号鍵(と訳されていますが秘密鍵のことで良い……

              パスキーが快適すぎる - yigarashiのブログ
            • 総務省 | 安全なパスワードの設定・管理 | 国民のためのサイバーセキュリティサイト

              安全なパスワードの設定・管理 企業・組織におけるパスワードは、ユーザ名と組み合わせることで企業・組織内の情報資産へのアクセスの可否を決める重要なものです。パスワードの重要性を再認識して、適切なパスワード管理を心がけましょう。 他人に自分のユーザアカウントを不正に利用されないようにするには、推測されにくい安全なパスワードを作成し、他人の目に触れないよう適切な方法で保管することが大切です。 安全なパスワードの設定 安全なパスワードとは、他人に推測されにくく、ツールなどの機械的な処理で割り出しにくいものを言います。 理想的には、ある程度長いランダムな英数字の並びが好ましいですが、覚えなければならないパスワードの場合は、英語でも日本語(ローマ字)でもよいので無関係な(文章にならない)複数の単語をつなげたり、その間に数字列を挟んだりしたものであれば、推測されにくく、覚えやすいパスワードを作ることがで

                総務省 | 安全なパスワードの設定・管理 | 国民のためのサイバーセキュリティサイト
              • パスワードはおしまい! 認証はパスキーでやろう

                はじめに パスワードは古来より認証に良く使われる方法ですが、その運用の難しさからセキュリティの懸念とその対策としての運用の複雑さ(複雑で長い文字列、90日でパスワード変更など)が要求される大きく問題をもった仕組みです。 その根本的な解決策としてFIDO Allianceを中心に推進されている 「パスワードレス」 が注目されています。これはPINや生体認証とデバイス認証を使ったMFAからなっており、フィッシングやパスワード流出に強い上に、ユーザも複雑なパスワードを覚えなくて良い、という大きなメリットがあります。最近はこの流れでPassKeyというものが登場し、Apple/MS/Googleのプラットフォーマが対応したことで、本格運用に乗せれるフェーズになってきました。というわけで以下に解説動画を作ったのですが、動画中で時間の都合で触れきれなかったところや、JavaScriptによる実装のサン

                  パスワードはおしまい! 認証はパスキーでやろう
                • AIイラストが理解る!StableDiffusion超入門【2024年最新版】A1111、Forge対応|賢木イオ @studiomasakaki

                  AIイラストが理解る!StableDiffusion超入門【2024年最新版】A1111、Forge対応 こんにちは、2022年10月からAIイラストの技術解説記事を連載してます、賢木イオです。この記事は、これまでFANBOXで検証してきた120本(約70万文字)を超える記事をもとに、2024年春現在、画像生成を今から最短距離で学ぶための必要情報をまとめたメインコンテンツです。 これから画像生成を学びたい初心者の方や、手描きイラストにAI技術を取り入れてみたい方が最初に読む記事として、必要知識が網羅的に備わるよう解説しています。素敵なイラストを思い通りに生成するために覚えるべきことを紹介しつつ、つまずきやすいポイントや参照すべき過去記事、やってはいけないことなどを紹介していますので、最初にこの記事から読んでいただくとスムーズに理解できるはずです。 解説役は更木ミナちゃんです。よろしくお願い

                    AIイラストが理解る!StableDiffusion超入門【2024年最新版】A1111、Forge対応|賢木イオ @studiomasakaki
                  • 次世代Web認証「パスキー」 / mo-zatsudan-passkey

                    モニクル社内3分LTで発表しました。技術職以外の人向けに話したので、抽象度高めにしてあります。

                      次世代Web認証「パスキー」 / mo-zatsudan-passkey
                    • 何故パスワードをハッシュ化して保存するだけでは駄目なのか? - NRIネットコムBlog

                      不正アクセスによるIDとパスワードの漏洩を受けて、MD5によるハッシュ化について話題になっていました。システムを作る上で、パスワードの管理や認証はどう設計すべきかを考えるために、少し整理をしてみます。もし事実誤認があれば、どしどしご指摘ください。 == 2023/8/21追記 == この記事は、ハッシュの保存の仕方一つとっても、沢山の対策方法が必要であるということをお伝えするために記載しています。そして、これから紹介する手法を取れば安全とお勧めしている訳ではないので、その点をご留意いただければと思います。攻撃手法に応じての対応策の変遷を知っていただくことで、セキュリティ対策は一度行えば安全というものではないことを知って頂くキッカケになれば幸いです。 == 追記終わり == パスワードのハッシュ化 まず最初にパスワードの保存方法です。何も加工しないで平文で保存するのは駄目というのは、だいぶ認

                        何故パスワードをハッシュ化して保存するだけでは駄目なのか? - NRIネットコムBlog
                      • 【無料】台湾で収録された自然環境音ライブラリ、99Sounds「Nature Sounds」無償配布開始! | Computer Music Japan

                        Nature Soundsには、ロイヤリティーフリーのネイチャー・フィールド・レコーディングが以下のカテゴリーで収録されています: 動物、森、雨、水、風。 最も人気のあるRain SoundsとWater Soundsライブラリに追加するのに最適な音源です。新しいNature Soundsは、よりバラエティに富んだサウンドを提供し、サウンドデザイン、映画、ソーシャルメディア、音楽制作に最適です。 Free To Use Soundsの友人が台湾で録音し、99Soundsの訪問者に無料でダウンロード提供しています。 Free To Use Soundsのウェブサイトでは、世界中の様々な場所で録音されたフィールドレコーディングをご覧いただけます。 Nature Soundsには、24ビットWAVフォーマット(192kHz、ステレオ)の音声が83曲収録されています。 ダウンロードサイズは2.9G

                          【無料】台湾で収録された自然環境音ライブラリ、99Sounds「Nature Sounds」無償配布開始! | Computer Music Japan
                        • メールアドレスをキーにしてID連携を行う設計の危うさ|ritou

                          ritouです。このしずかなインターネットにおける初投稿です。 おそらく、このしずかなインターネットのID連携では次のような設計になっていま「した」。問い合わせをさせていただき、対応いただきました。 これまでもQiitaなどで同様の実装例が紹介されていた際にはコメントさせていただいていたものですので、アンチパターンの紹介記事として読んでいただければと思います。 「Googleアカウントでログイン」ではじめると、ユーザーが作成され、Googleから受け取ったメールアドレス([email protected])が設定される 次回から「Googleアカウントでログイン」をすると、Googleから受け取ったメールアドレスでユーザーを参照 試しに、次のような流れで動作を確認してみます。 「Googleアカウントでログイン」でアカウント作成([email protected]) 「メールアドレス変更」

                            メールアドレスをキーにしてID連携を行う設計の危うさ|ritou
                          • 仕様が読めるようになるOAuth2.0、OpenID Connect 入門

                            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

                              仕様が読めるようになるOAuth2.0、OpenID Connect 入門
                            • JWTセキュリティ入門

                              SECCON Beginners Live 2023「JWTセキュリティ入門」の発表資料です。

                                JWTセキュリティ入門
                              • パスキーの基本とそれにまつわる誤解を解きほぐす

                                2023 年は文句なく「パスキー元年」になりました。非常にたくさんのサービスがパスキーに対応し、2024 年はいよいよパスキー普及の年になりそうです。 本記事では、パスキーの基本を振り返ったうえで、パスキーでみなさんが勘違いしやすい点について解説します。 2023 年は本当にたくさんのウェブサイトがパスキーに対応しました。例を挙げます: Adobe Amazon Apple eBay GitHub Google KDDI Mercari Mixi MoneyForward Nintendo NTT Docomo PayPal Shopify Toyota Uber Yahoo! JAPAN もちろんこのリストですべてではないですが、これらだけでも、世界人口のかなりをカバーできるはずで、まさに大躍進と言えます。もしまだパスキーを体験していないという方がいたら、ぜひこの機会にお試しください。

                                  パスキーの基本とそれにまつわる誤解を解きほぐす
                                • 「外資にやらせていいのか」ふるさと納税、アマゾン参入に懸念の声

                                  アマゾンは2025年春、「ふるさと納税」事業に参入するとの報道された。 REUTERS/Brendan McDermid./File Photo ふるさと納税にアマゾンが2025年春にも参入するとの報道を受け、ふるさと納税制度に対する懸念が広がっている。 ふるさと納税の大手ポータルサイトとしては、楽天ふるさと納税、ふるさとチョイス、さとふる、ふるなびなどが知られている。 自治体の返礼品を紹介しているポータルサイトは、サービスによって異なるが寄付金のうち「10%程度」を手数料として寄付先の自治体から徴収している。一方でアマゾンは手数料を大幅に引き下げたプランを検討しているという。

                                    「外資にやらせていいのか」ふるさと納税、アマゾン参入に懸念の声
                                  • 「認証」を整理する | IIJ Engineers Blog

                                    英語の「Authentication」を整理する ここからは先ほどの分類で言うところの「ユーザ認証」としての「認証」、つまり英語の「Authentication」に該当する「認証」について、さらに整理を進めていきます。 先ほど、「ユーザ認証」を「システムを利用しようとしているユーザを、システムに登録済みのユーザかどうか識別し、ユーザが主張する身元を検証するプロセス」と説明しました。「ユーザの識別」と「身元の検証」はユーザ認証に欠かせませんが、実際は他にも「ユーザの有効/無効状態の確認」や「検証に成功した場合の身元の保証(アクセストークンの発行等)」などの処理も一般的にユーザ認証のプロセスには含まれます。 ここで冒頭の「○○認証」を振り返りましょう。パスワード認証、SMS認証、指紋認証、顔認証は実はここで言うユーザ認証には該当せず、ユーザ認証中の一処理である「身元の検証」を担っていることがお

                                      「認証」を整理する | IIJ Engineers Blog
                                    • Gmailが2024年2月から(大量)送信者に求めてることが分からない闇への防衛術(後編) - Qiita

                                      この記事は 2023年10月7日にGmailと米Yahooさんが投げ込んだ新たな闇要素への防衛術 の後編です。前編はこちら。 ※というか私がまだ防衛術を検討&試行中である ※この記事にはSPFやDKIMなどのメール認証に関する用語が出てきますが、それ自体の解説は含みませのであしからず。 ※Gmailのガイドラインはこちら Googleが(大量)送信者に求めていること9つを3つに分類 では、Gmailさんが求めている事項を見てみます(下記キャプチャーは2023/12/9現在)。 上から①②……と番号を振って日本語を意訳し箇条書きにするとこうです 項番 内容

                                        Gmailが2024年2月から(大量)送信者に求めてることが分からない闇への防衛術(後編) - Qiita
                                      • 「しずかなインターネット」の技術スタックを調べる - laiso

                                        ポエム特化のZenn2との噂の「しずかなインターネット」を使いはじめたので、ユーザーとしてどんな技術が使われているのかを確認していく。 sizu.me おもむろにbuiltwith.comにかけてみる。 builtwith.com ここで分かる情報はブラウザのDevTools眺めてても得られるのであまり収穫はない。 前段にCloudflareのCDNサーバーがいて Next.jsで生成されたレスポンスを返している ことがわかる。 この時点ではキャッシュのみCloudflareなのか、Pages/WorkersでNext.jsのSSRごと動かしているのかは判断できない。 認証 Set-Cookie: __Secure-next-auth.session-token=が含まれているのでNextAuth.jsを使っているのが分かる。 next-auth.js.org Emailでサインアップする

                                          「しずかなインターネット」の技術スタックを調べる - laiso
                                        • 認可のアーキテクチャに関する考察(Authorization Academy IIを読んで)

                                          みなさま、認可の設計に苦しんでいるでしょうか?私は苦しんでいます。苦しまなかった瞬間などありません。昔「アプリケーションにおける権限設計の課題」を執筆しましたが、あれから3年以上が経ちます。 当時は認可の設計に関する情報がうまくまとまっている記事などほとんど無く、調べに調べて得たナレッジを書き記したのが上記の記事です。3年以上経ちますが、苦悩が今も特に変わっていないことが驚きです。 ただし、世の中的には認可のライブラリであったりサービスというのは少しずつ増えてきている印象があります(Auth0の OpenFGA であったりOsoの Oso Cloud 、Asertoの Topaz )。 認可の設計に関する記事も少しずつ増えている印象があり、その中でも本記事で紹介したいのがAuthorization Academyです。 これは認可サービスである Oso Cloud やOSSのライブラリ o

                                            認可のアーキテクチャに関する考察(Authorization Academy IIを読んで)
                                          • SPF (やDMARC) を突破する攻撃手法、BreakSPF | 朝から昼寝

                                            SPF レコードで許可されている IPアドレスの実態がクラウドやプロキシ等の共用サービスのものであるケースは多く、それらの IPアドレスが第三者によって利用できる可能性があることを悪用し、SPF 認証を pass、結果的に DMARC 認証まで pass して詐称メールを送信できてしまうことを指摘した論文が公開されています。 この論文では、上記のような SPF の脆弱な展開に対する攻撃手法を BreakSPF と呼び、関連するプロトコルや基盤の実装に対する分析と共に、その内容が体系的にまとめられています。 本記事では、その論文を参照しながら、簡単に概要をまとめておきます。 補足事項 (2024/3/5) 本記事につきまして、(当サイトとしては) 多くのアクセスいただいているようで (ちょっとビビってま) す。まことに大変ありがたいことに色々とシェアいただいたりしたようです。 そこで、記事の

                                              SPF (やDMARC) を突破する攻撃手法、BreakSPF | 朝から昼寝
                                            • なぜソーシャルログインの際にemailをキーにして参照するのか

                                              ritouです。 Digital Identity技術勉強会 #iddance Advent Calendar 2023 の 初日の記事です。 こちら、参加者を募集中です!気軽に参加してみてください!してくれよ!はよ! なんの話か ちょっと想定以上に反応をいただいたこちらの記事について、ちょっとだけ補足をしたいと思います。 なんの話か詳しく 自分のはてブのコメントをつけたポストにもたくさん反応いただきました。 実際、海外のサービスはメアドをキーにして参照してるところも多く これはサービスのDBのUserテーブルがemailをプライマリキーにしているという話ではありません(が、そう思われた方からDMが来ました)。 最初にパスワード認証やメールでリンクを送信して認証させる仕組みを実装している状態から、ソーシャルログインを実装しようとする際に "email" をキーにした参照をすることがあるんよ

                                                なぜソーシャルログインの際にemailをキーにして参照するのか
                                              • パスキーに入門してみた話 - Qiita

                                                久しぶりの投稿です。 はじめに 昨今、様々なサイトがどんどんパスキーに対応しはじめてきました。 まだまだパスキーがデフォルトになっていくには時間が掛かりそうですが、どのような仕組みでパスキーを実装するのか、早めにキャッチアップしておくのも悪くないと思い、パスキーについて色々と調べてみました。 パスキーとは? パスワードの代わりに、自分の持つデバイスによる生体認証やパターンを用いて認証を行う方法のことです。 次世代認証技術であるFIDO(Fast IDentity Onlineの略で、「ファイド」と呼びます)を使った認証方式(詳細は後述)で、Apple、Google、MicrosoftがFIDOを普及させるために命名したブランド名になります。 FIDOとは? 脆弱なパスワードは安全ではありません。 2段階・2要素認証を採用してもそれを有効にするユーザーは少なく、昨今では2段階認証を突破する攻

                                                  パスキーに入門してみた話 - Qiita
                                                • マルチテナントの実現におけるDB設計とRLS / Utilizing RSL in multi-tenancy

                                                  # 実装の参考資料 - https://soudai.hatenablog.com/entry/2022/11/11/110825 # 類似の登壇内容の動画 - https://www.youtube.com/watch?v=PXy6I-AeI-I

                                                    マルチテナントの実現におけるDB設計とRLS / Utilizing RSL in multi-tenancy
                                                  • 多要素認証を私物スマホでやっていいのか問題

                                                    Hello,World! gonowayです。 弊社がご支援するお客様とお話するなかで、多要素認証のためにIDaaSが提供しているアプリケーション(以降、認証アプリ)を私物モバイル端末にいれていいのか?という疑問に、わたしたちが普段お客様にご案内していることをざっくりまとめてみました。 3行まとめ 現代では外部の不正ログインから守るために多要素認証が必須になってきている。 多要素認証の実現のため、会社モバイル端末であれ私物モバイル端末であれ認証アプリはインストールしてほしい。 私物モバイル端末にインストールしてもらう場合、エンドユーザーへの説明を行うことが必要。また、ガラケーしか持っていないような例外措置への対処を考えることも必要。 前提 認証要素について 認証要素は下記の3種類です。NIST SP800-63を参考にしています。 記憶によるもの:記憶(Something you know

                                                      多要素認証を私物スマホでやっていいのか問題
                                                    • ドコモが「パスキー」を導入してフィッシング被害報告が0件に パスワードレス認証の効果

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

                                                        ドコモが「パスキー」を導入してフィッシング被害報告が0件に パスワードレス認証の効果
                                                      • APIトークン認証の論理設計

                                                        SPAやモバイルアプリから利用するAPIを開発する際の、トークン認証のお話です。 どの認証ライブラリを使うべきという話ではなく、トークン認証の論理的な設計について考察します。 私自身も結論が出ていないので、色んな意見が聞けると嬉しいです。 出発点 ユーザテーブルにアクセストークンを持つのが最も安直な発想だと思います。 ログイン成功時にアクセストークンを発行し、該当ユーザレコードにセット。 同時に有効期限もセットします。 認証時には、アクセストークンが存在し有効期限内であれば、認証を通過させ、 そうでなければ認証失敗とします。 ログアウト時には、該当ユーザレコードのアクセストークンを空にします。 発行日時を持ち、システム内に定義された有効期間をもとに、認証時に計算する方法もあると思います。 Laravel Sanctum 等はそういう実装です(しかもデフォルトでは有効期限なし)。 有効かどう

                                                          APIトークン認証の論理設計
                                                        • カード決済のセキュリティ的な問題点とその対策、IC チップの決済とその仕組み - カンムテックブログ

                                                          エンジニアの佐野です。カンムはカード決済のサービスを提供しています。カード決済にはいくつかの決済手段があり、マグストライプ、IC、IC非接触(俗に言うタッチ決済)、オンライン決済などの機能が提供可能です。iD のようなスマートデバイスにカード情報を入れてスマホでタッチ決済する仕組みもあります。カンムのプロダクトであるバンドルカードはマグストライプとオンライン決済、Pool はマグストライプとオンライン決済に加えて IC接触決済、IC非接触決済(タッチ決済)を提供しています。今日はセキュリティ的な観点から各種決済手段の特徴や問題点とともに、主に IC 決済の仕組みについて小ネタを交えつつ書いていこうと思います。カンムが提供しているカードは Visa カードでありクローズドな仕様や confidential なものについては言及することはできませんが、公開仕様であったり一般的な事柄のみを用いて

                                                            カード決済のセキュリティ的な問題点とその対策、IC チップの決済とその仕組み - カンムテックブログ
                                                          • パスキー時代の"認証要素"の考え方 ~パスキーとパスワードマネージャー~

                                                            ritouです。 サービス、ブラウザ、OSそれぞれのパスキー対応が日々進んでいます。 その中で、パスキーを利用してみて認証要素についてふと考えてしまう人がいるでしょう。 パスキー簡単!けどこれ指紋認証だけ?弱くなってない? SMS OTPを2FAに設定し、パスワードマネージャーも使ってたから使い勝手はあまり変わらない。むしろSMS OTPがないぶんだけ弱くなった? この辺りについて整理します。 認証要素というと、次の3つです。 SYK: Something You Know. パスワード、PIN SYH: Something You Have. 認証アプリ、TOTP生成アプリ、バックアップコード、 SYA: Something You Are. 生体認証 前にこんな記事を書きました。 この内容を説明すると、「うん、わかってる」って人は多いです。 でも、実際に使ってみると心許なく感じたりする

                                                              パスキー時代の"認証要素"の考え方 ~パスキーとパスワードマネージャー~
                                                            • JSON Canvas

                                                              An open file format for infinite canvas data. Infinite canvas tools are a way to view and organize information spatially, like a digital whiteboard. Infinite canvases encourage freedom and exploration, and have become a popular interface pattern across many apps. The JSON Canvas format was created to provide longevity, readability, interoperability, and extensibility to data created with infinite

                                                                JSON Canvas
                                                              • 【Amazon】2段階認証を設定したアカウントで不正アクセス被害の報告が急増(2023年9月12日)

                                                                2023年9月以降、Amazonアカウントの不正アクセス被害が急増しています。不正アクセス被害は2段階認証を設定しているアカウントでも報告されており、何らかの方法で2段階認証をすり抜け、ギフトカードなどを無断購入される被害が増えています。 2段階認証を設定したアカウントで不正アクセス被害が報告 2023年9月以降、Amazonアカウントの不正アクセス被害が相次ぎ発生しており、SNSなどで「ギフトカードを購入された」「2段階認証を突破された」など、被害を報告する声が増えています。 また、2段階認証(2SV)を設定していたとするユーザーからも不正アクセス被害が報告されており、何らかの方法で2段階認証がすり抜けられてしまうことがあるようです。 Amazonのアカウント、不正利用されたー 夜中にギフトカード5,000円×20枚購入されて、速攻メールでどこかに送信されたらしく、即時クレカに請求が来て

                                                                  【Amazon】2段階認証を設定したアカウントで不正アクセス被害の報告が急増(2023年9月12日)
                                                                • パスキーは本当に2要素認証なのか問題、またの名を、あまり気にせず使えばいいと思うよ。|kkoiwai

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

                                                                    パスキーは本当に2要素認証なのか問題、またの名を、あまり気にせず使えばいいと思うよ。|kkoiwai
                                                                  • SPAのアプリケーションで、外部のIdPを使ってOpenID Connect によるログイン機能を開発しようと考えています。IDトークンの保存先として、ブラウザのCookieかサーバーのDBに保存するかの2つの案があると思っています。調べた限り、サーバーサイドで持つべきという意見が多いように見えますが、以下のような背景がある中で開発しても、ブラウザのCookieでは持つべきなのではないのでしょうか? - IDトークン自体にも、個人の属性(氏名等)情報は無いことを確認している - サーバーサイドでIDトーク

                                                                    SPAのアプリケーションで、外部のIdPを使ってOpenID Connect によるログイン機能を開発しようと考えています。IDトークンの保存先として、ブラウザのCookieかサーバーのDBに保存するかの2つの案があると思っています。調べた限り、サーバーサイドで持つべきという意見が多いように見えますが、以下のような背景がある中で開発しても、ブラウザのCookieでは持つべきなのではないのでしょうか? - IDトークン自体にも、個人の属性(氏名等)情報は無いことを確認している - サーバーサイドでIDトークンの署名検証をして、IDトークンの改ざんが無いか確認する - Http Only属性:JSによるCookieへのアクセスを防ぐため - Secure属性:流出防止のため - SameSite=strict:CSRF対策のため 結論から言えば、「どちらでもよい」となります。しかし、恐らく話は

                                                                      SPAのアプリケーションで、外部のIdPを使ってOpenID Connect によるログイン機能を開発しようと考えています。IDトークンの保存先として、ブラウザのCookieかサーバーのDBに保存するかの2つの案があると思っています。調べた限り、サーバーサイドで持つべきという意見が多いように見えますが、以下のような背景がある中で開発しても、ブラウザのCookieでは持つべきなのではないのでしょうか? - IDトークン自体にも、個人の属性(氏名等)情報は無いことを確認している - サーバーサイドでIDトーク
                                                                    • 思わず天を仰いでしまうID関連システムトラブル - =kthrtty/(+blog)

                                                                      こんにちは。アドカレ12/24の記事を簡単にではありますが書かせていただきました。(25日のポストで遅刻ですが) Digital Identity技術勉強会 #iddanceのカレンダー | Advent Calendar 2023 - Qiita はじめに 本日のテーマ:思わず天を仰いでしまうID関連システムトラブル 本日のテーマは、みんな大好き「トラブル」の話です。CIAM(Consumer Identity and Access Management)領域のさまざまなシステムにさまざまな立場で関わり、さまざまなトラブルに遭遇してきた経験を踏まえて、クリスマスの合間の気楽な読み物として記載しましたので、一息ついていただければ幸いです。 今回はトラブルの中でも思わず「天を仰いでしまう」激ヤバトラブルにフォーカスして、私的ランキング形式でお届けしたいと思います。 天を仰ぐトラブルとは? 私

                                                                        思わず天を仰いでしまうID関連システムトラブル - =kthrtty/(+blog)
                                                                      • Azure AD が発行するトークンの有効期間と考え方 (2023 年版)

                                                                        Note 本記事は、2018 年公開の以下の Blog の内容が、現在の機能/技術にマッチしない内容になってきたことを踏まえ、2023 年現在の機能/技術を元に改めて考え方をおまとめしたものとなります。以前に公開した Azure AD が発行するトークンの有効期間について (2018 年公開) の記事は参考のためそのまま残し、新しく本記事を執筆しました。 こんにちは、Azure & Identity サポートの金森です。 Azure AD (AAD) は、Microsoft 365 をはじめ様々なクラウド サービスの認証基盤 (Identity Provider / IdP) として利用されています。その重要な機能としてユーザーの認証が完了したら、アプリケーションに対してトークンを発行するというものがあります。あるサービス (Teams や Exchange Online、他に Azure

                                                                          Azure AD が発行するトークンの有効期間と考え方 (2023 年版)
                                                                        • EXCEL使える人が効率化しても、わからない人に数字直入れで破壊される問題→「全ロック」「いっそ見せない」うまくいった対策色々

                                                                          アルマ🍤🍤 @lellot01 SUM関数がトレンドになってるけど、エクセルできる人間が業務効率化の為にエクセルでこことここだけを入力したら全て自動的に出るよ、という表を作るとするだろ。んで、担当者に渡す。すると、何故か全て数式が消えて直接数字が入っている状態になっているということがよくある。 2024-03-10 14:19:59 アルマ🍤🍤 @lellot01 こことここだけ入力してくださいとかいてあるにもかかわらずだ。そして「数字を入力しても入ってる数字が違うんですけど!あなた何やったの!?」って逆切れされる。見ると数式が全部潰れていて「なんで直入力したんですか?」って聞いても「直入力して何が悪いの?」って答えられる。これ何て現象? 2024-03-10 14:19:59

                                                                            EXCEL使える人が効率化しても、わからない人に数字直入れで破壊される問題→「全ロック」「いっそ見せない」うまくいった対策色々
                                                                          • 認可のベストプラクティスとDDDでの実装パターン

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

                                                                              認可のベストプラクティスとDDDでの実装パターン
                                                                            • パスキーとは--パスワードに代わる認証方法の基礎

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

                                                                                パスキーとは--パスワードに代わる認証方法の基礎
                                                                              • 「Amazonを不正利用された」──SNS上で報告相次ぐ 「二段階認証を突破された」などの声も

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

                                                                                  「Amazonを不正利用された」──SNS上で報告相次ぐ 「二段階認証を突破された」などの声も
                                                                                • CSSだけでif~else文と同じことができる! しかもすべてのブラウザでサポートされています

                                                                                  CSSでif~else文が使えたら、と思ったことはありませんか? もちろんifとかelseはCSSにはありませんが、CSSだけでif~else文と同じようにスタイルを設定できます。 CSSでif~else文を実現するには...記事の続きを読む

                                                                                    CSSだけでif~else文と同じことができる! しかもすべてのブラウザでサポートされています