Gmailが「メール送信者のガイドライン」を改訂し、なりすましメールへの対策を強化する旨を発表しています。今までは原則、なりすましメール対策の有無にかかわらず、メールはいちおうは届いていました。しかし今後は、なりすましとみなされたメールは届かなくなる方向に向かいつつあります。 なりすましメールとみなされないようにするために、メール送信者には、「メール送信ドメイン認証」への対応が求められます。メール送信ドメイン認証の技術には、主に以下の3つがあります。 SPF: Sender Policy Framework (RFC 7208) DKIM: DomainKeys Identified Mail (RFC 6376) DMARC: Domain-based Message Authentication, Reporting, and Conformance (RFC 7489) SPFは従来
pictBLandとpictSQUAREに対する不正アクセスがあり、パスワードがソルトなしのMD5ハッシュで保存されていたことが話題になっています。 2023年8月16日に外部のフォーラムにpictSQUAREより窃取した情報と主張するデータ販売の取引を持ち掛ける投稿が行われた（中略）パスワードはMD5によるハッシュ化は行われているもののソルト付与は行われていなかったため、単純なパスワードが使用されていた29万4512件は元の文字列が判明していると投稿。（それ以外の26万8172件はまだMD5ハッシュ化されたままと説明。） 不正アクセスによるpictBLand、pictSQUAREの情報流出の可能性についてまとめてみた - piyolog より引用 これに関連してMD5ハッシュやソルトに関するツイート(post)を観察したところ、どうもソルトの理解が間違っている方が多いような気がしました。
こんにちは。エムスリー・QLife(エムスリーのグループ会社)・エムスリーヘルスデザイン(エムスリーのグループ会社)でエンジニアとして各種作業に関わっている山本です！ 以前もメール送信の話を書かせていただいたことがありますが、今回もまたメールネタとなります。今回のお題はメールセキュリティです。 大量メール送信のための予備知識 - エムスリーテックブログ すでにご覧になった方もいるかと思いますが、次のようなニュースが流れています。 www.proofpoint.com この「GoogleとYahooの新Eメール認証要件」ってつまりどういうことよ？ というところを具体的にどのように進めているかについて書かせていただきたいと思います。 2023/12/18追記 : Googleからメール送信にTLSを使うことが追加要件として示されました。 TL;DR とりあえず何から始める？ 何はともあれ実際に
滅びてほしい認証系の実装の話
こんにちは、富士榮です。 ちょっと前に某所でダメダメな認証系の技術実装ってなんだろうねぇ、、という話をしていたことをXで呟いたところ、色々とご意見を頂けましたのでまとめて書いておきます。
しばたです。 昨年10月にGoogle(Gmail)および米国Yahoo!においてスパム対策の強化がアナウンスされました。 この件に関してつい先日まで他人事でいたのですが、実は全然他人事では済まないことが発覚し突貫で知識を仕入れています。 アナウンスに対する具体的な対応策についてはこちらのZennの記事を見れば全部わかる感じです。 最高ですね。 また、メール送信にAmazon SESを使っている場合はAWSのブログを確認すると良いでしょう。 「これらの記事を読み解けば万事解決！」という感じではあるのですが、私自身が学んだなかで予め知っておくと良さそうに思えた点がいくつかありました。 本記事ではその辺を共有するのと、実際にAmazon SESの環境を作って動作確認をしたのでその結果も合わせて共有します。 はじめに覚えておくと良い基礎知識 Zennの記事でも詳細な解説がありますが、個人的に「最
しずかなインターネットの技術構成
こんなWebサービスをリリースしたので、技術的な話をまとめておこうと思います。 元々このサービスは、趣味の延長線のような感じで開発を始めました。競合にあたるnoteやはてなブログなどのサービスが確固たる地位を築いているということもあり、「お金にはならないだろうけど、自分の趣味を詰め込んだものにしよう」というゆるい気持ちで開発を続けています（楽しい）。 選定の方針 趣味と言っても文章投稿サービスなので、ユーザーが少数であったとしても長期間運営しなければなりません。そのため、ユーザー数が少なければランニングコストが数千円/月以下、ユーザー数が増えたときは段階的にコストが上がるように選定を行いました。 アプリケーション フルスタックNext.jsアプリケーションをCloud Runにデプロイしています。各APIエンドポイントはNext.jsのAPI Routesで生やしています。 Next.js
パスワードレスな認証方式である「パスキー」が急速に普及しています。OS、ブラウザ、パスワード管理ツール、サービス提供者のどれもが整いつつあり、ついに本当にパスワードが必要ない世界がやってきたことを感じます。この記事では、本腰を入れてパスキーを使い始めて快適になるまでの様子をまとめます。技術的な厳密さ・網羅性には踏み込まず、いちユーザーとしての入門記事という位置付けです。 パスキーとは パスキー - Wikipedia 認証、セキュリティに関しては門外漢なので、Wikipediaのリンクを置いておきます。私よりはWikipediaのほうが信用に足るでしょう。 そこから辿れるホワイトペーパー：マルチデバイス対応FIDO認証資格情報を読むと、多少ストーリーもわかります。FIDO2というデバイスに格納された秘密鍵に依存したパスワードレス認証の仕様に、暗号鍵（と訳されていますが秘密鍵のことで良い……
パスワードはおしまい！ 認証はパスキーでやろう
はじめに パスワードは古来より認証に良く使われる方法ですが、その運用の難しさからセキュリティの懸念とその対策としての運用の複雑さ（複雑で長い文字列、90日でパスワード変更など）が要求される大きく問題をもった仕組みです。 その根本的な解決策としてFIDO Allianceを中心に推進されている 「パスワードレス」 が注目されています。これはPINや生体認証とデバイス認証を使ったMFAからなっており、フィッシングやパスワード流出に強い上に、ユーザも複雑なパスワードを覚えなくて良い、という大きなメリットがあります。最近はこの流れでPassKeyというものが登場し、Apple/MS/Googleのプラットフォーマが対応したことで、本格運用に乗せれるフェーズになってきました。というわけで以下に解説動画を作ったのですが、動画中で時間の都合で触れきれなかったところや、JavaScriptによる実装のサン
モニクル社内3分LTで発表しました。技術職以外の人向けに話したので、抽象度高めにしてあります。
不正アクセスによるIDとパスワードの漏洩を受けて、MD5によるハッシュ化について話題になっていました。システムを作る上で、パスワードの管理や認証はどう設計すべきかを考えるために、少し整理をしてみます。もし事実誤認があれば、どしどしご指摘ください。 == 2023/8/21追記 == この記事は、ハッシュの保存の仕方一つとっても、沢山の対策方法が必要であるということをお伝えするために記載しています。そして、これから紹介する手法を取れば安全とお勧めしている訳ではないので、その点をご留意いただければと思います。攻撃手法に応じての対応策の変遷を知っていただくことで、セキュリティ対策は一度行えば安全というものではないことを知って頂くキッカケになれば幸いです。 == 追記終わり == パスワードのハッシュ化 まず最初にパスワードの保存方法です。何も加工しないで平文で保存するのは駄目というのは、だいぶ認
ritouです。このしずかなインターネットにおける初投稿です。 おそらく、このしずかなインターネットのID連携では次のような設計になっていま「した」。問い合わせをさせていただき、対応いただきました。 これまでもQiitaなどで同様の実装例が紹介されていた際にはコメントさせていただいていたものですので、アンチパターンの紹介記事として読んでいただければと思います。 「Googleアカウントでログイン」ではじめると、ユーザーが作成され、Googleから受け取ったメールアドレス([email protected])が設定される 次回から「Googleアカウントでログイン」をすると、Googleから受け取ったメールアドレスでユーザーを参照 試しに、次のような流れで動作を確認してみます。 「Googleアカウントでログイン」でアカウント作成([email protected]) 「メールアドレス変更」
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
JWTセキュリティ入門
SECCON Beginners Live 2023「JWTセキュリティ入門」の発表資料です。
Preparing for the end of third-party cookies | Privacy Sandbox | Google for Developers
Preparing for the end of third-party cookies Stay organized with collections Save and categorize content based on your preferences. If your site uses third-party cookies, it's time to take action as we approach their deprecation. To facilitate testing, Chrome has restricted third-party cookies for 1% of users from January 4th, 2024. Chrome plans to ramp up third-party cookie restrictions to 100% o
パスキーの基本とそれにまつわる誤解を解きほぐす
2023 年は文句なく「パスキー元年」になりました。非常にたくさんのサービスがパスキーに対応し、2024 年はいよいよパスキー普及の年になりそうです。 本記事では、パスキーの基本を振り返ったうえで、パスキーでみなさんが勘違いしやすい点について解説します。 2023 年は本当にたくさんのウェブサイトがパスキーに対応しました。例を挙げます: Adobe Amazon Apple eBay GitHub Google KDDI Mercari Mixi MoneyForward Nintendo NTT Docomo PayPal Shopify Toyota Uber Yahoo! JAPAN もちろんこのリストですべてではないですが、これらだけでも、世界人口のかなりをカバーできるはずで、まさに大躍進と言えます。もしまだパスキーを体験していないという方がいたら、ぜひこの機会にお試しください。
社内用GitHub Actionsのセキュリティガイドラインを公開します | メルカリエンジニアリング
この記事は、Merpay Tech Openness Month 2023 の4日目の記事です。 こんにちは。メルコインのバックエンドエンジニアの@goroです。 はじめに このGitHub Actionsのセキュリティガイドラインは、社内でGithub Actionsの利用に先駆け、社内有志によって検討されました。「GitHub Actionsを使うにあたりどういった点に留意すれば最低限の安全性を確保できるか学習してもらいたい」「定期的に本ドキュメントを見返してもらい自分たちのリポジトリーが安全な状態になっているか点検する際に役立ててもらいたい」という思いに基づいて作成されています。 今回はそんなガイドラインの一部を、社外の方々にも役立つと思い公開することにしました。 ガイドラインにおける目標 このガイドラインは事前に2段階の目標を設定して作成されています。まず第1に「常に達成したいこと
Gmailが2024年2月から(大量)送信者に求めてることが分からない闇への防衛術(後編) - Qiita
この記事は 2023年10月7日にGmailと米Yahooさんが投げ込んだ新たな闇要素への防衛術 の後編です。前編はこちら。 ※というか私がまだ防衛術を検討＆試行中である ※この記事にはSPFやDKIMなどのメール認証に関する用語が出てきますが、それ自体の解説は含みませのであしからず。 ※Gmailのガイドラインはこちら Googleが(大量)送信者に求めていること9つを3つに分類 では、Gmailさんが求めている事項を見てみます(下記キャプチャーは2023/12/9現在)。 上から①②……と番号を振って日本語を意訳し箇条書きにするとこうです 項番 内容
英語の「Authentication」を整理する ここからは先ほどの分類で言うところの「ユーザ認証」としての「認証」、つまり英語の「Authentication」に該当する「認証」について、さらに整理を進めていきます。 先ほど、「ユーザ認証」を「システムを利用しようとしているユーザを、システムに登録済みのユーザかどうか識別し、ユーザが主張する身元を検証するプロセス」と説明しました。「ユーザの識別」と「身元の検証」はユーザ認証に欠かせませんが、実際は他にも「ユーザの有効／無効状態の確認」や「検証に成功した場合の身元の保証（アクセストークンの発行等）」などの処理も一般的にユーザ認証のプロセスには含まれます。 ここで冒頭の「○○認証」を振り返りましょう。パスワード認証、SMS認証、指紋認証、顔認証は実はここで言うユーザ認証には該当せず、ユーザ認証中の一処理である「身元の検証」を担っていることがお
はじめに ◆この記事は何？ IPA高度資格「情報処理安全確保支援士」のシラバスに掲載されている用語の備忘録です ◆対象は？ 情報処理安全確保支援士の試験勉強をされる方 ◆この記事のねらい 試験範囲の用語の階層を整理します 試験勉強の一助となれば幸いです ◆この記事について シラバスの用語を参考書等を読みながら自分なりに整理した私の暗記用のノートです 試験に向けて高頻度で更新しています ご助言、誤り等あればご指摘いただけると幸いです 試験範囲全体 試験範囲の分解 暗号 認証 ネットワークセキュリティ データベースセキュリティ クライアントセキュリティ httpセキュリティ メールセキュリティ 攻撃と対策 注目技術 ※参考文献の目次をベースに、試験範囲を分解 暗号技術 共通鍵暗号方式 ブロック暗号 ECBモード CBCモード CTRモード（Counterモード） ストリーム暗号 公開鍵暗号方式
ポエム特化の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でサインアップする
みなさま、認可の設計に苦しんでいるでしょうか？私は苦しんでいます。苦しまなかった瞬間などありません。昔「アプリケーションにおける権限設計の課題」を執筆しましたが、あれから3年以上が経ちます。 当時は認可の設計に関する情報がうまくまとまっている記事などほとんど無く、調べに調べて得たナレッジを書き記したのが上記の記事です。3年以上経ちますが、苦悩が今も特に変わっていないことが驚きです。 ただし、世の中的には認可のライブラリであったりサービスというのは少しずつ増えてきている印象があります(Auth0の OpenFGA であったりOsoの Oso Cloud 、Asertoの Topaz )。 認可の設計に関する記事も少しずつ増えている印象があり、その中でも本記事で紹介したいのがAuthorization Academyです。 これは認可サービスである Oso Cloud やOSSのライブラリ o
SPF レコードで許可されている IPアドレスの実態がクラウドやプロキシ等の共用サービスのものであるケースは多く、それらの IPアドレスが第三者によって利用できる可能性があることを悪用し、SPF 認証を pass、結果的に DMARC 認証まで pass して詐称メールを送信できてしまうことを指摘した論文が公開されています。 この論文では、上記のような SPF の脆弱な展開に対する攻撃手法を BreakSPF と呼び、関連するプロトコルや基盤の実装に対する分析と共に、その内容が体系的にまとめられています。 本記事では、その論文を参照しながら、簡単に概要をまとめておきます。 補足事項 (2024/3/5) 本記事につきまして、(当サイトとしては) 多くのアクセスいただいているようで (ちょっとビビってま) す。まことに大変ありがたいことに色々とシェアいただいたりしたようです。 そこで、記事の
Gmailに届かない神奈川県立高校入試のインターネット出願システムのメールを調べてみた | DevelopersIO
Gmailに届かないと報告されている2024年神奈川県立高校入試の出願システム自動返信メール、 2024年1月15日にYahooメールに届いたメールヘッダー情報などから、送信ドメイン認証(SPF、DKIM、DMARC)の確認を試みました。 2024年2月の神奈川県立高校の受験を予定している家族から、 "インターネット出願システムの登録を試みたが、システムからの返信メールがGmailのアドレスが届かないため、代わりにYahooメールを利用した。" との報告を受けました。 今回、2024年1月15日にYahooメールで受信したインターネット出願システムのメールを調査する機会がありましたので、紹介させて頂きます。 2024年1月19日 追記 ネット出願システムの不具合解消後のメールの調査結果を公開しました。 2024年1月18日 追記 ネット出願システムのメールサーバ側の問題について調査結果を公
ritouです。 Digital Identity技術勉強会 #iddance Advent Calendar 2023 の 初日の記事です。 こちら、参加者を募集中です！気軽に参加してみてください！してくれよ！はよ！ なんの話か ちょっと想定以上に反応をいただいたこちらの記事について、ちょっとだけ補足をしたいと思います。 なんの話か詳しく 自分のはてブのコメントをつけたポストにもたくさん反応いただきました。 実際、海外のサービスはメアドをキーにして参照してるところも多く これはサービスのDBのUserテーブルがemailをプライマリキーにしているという話ではありません(が、そう思われた方からDMが来ました)。 最初にパスワード認証やメールでリンクを送信して認証させる仕組みを実装している状態から、ソーシャルログインを実装しようとする際に "email" をキーにした参照をすることがあるんよ
パスキーに入門してみた話 - Qiita
久しぶりの投稿です。 はじめに 昨今、様々なサイトがどんどんパスキーに対応しはじめてきました。 まだまだパスキーがデフォルトになっていくには時間が掛かりそうですが、どのような仕組みでパスキーを実装するのか、早めにキャッチアップしておくのも悪くないと思い、パスキーについて色々と調べてみました。 パスキーとは？ パスワードの代わりに、自分の持つデバイスによる生体認証やパターンを用いて認証を行う方法のことです。 次世代認証技術であるFIDO（Fast IDentity Onlineの略で、「ファイド」と呼びます）を使った認証方式（詳細は後述）で、Apple、Google、MicrosoftがFIDOを普及させるために命名したブランド名になります。 FIDOとは？ 脆弱なパスワードは安全ではありません。 2段階・2要素認証を採用してもそれを有効にするユーザーは少なく、昨今では2段階認証を突破する攻
はじめまして、ますみです！ 先日のOpenAI社の初めてのカンファレンスである「OpenAI Dev Day 2023」で発表されたGPT Builderがついに利用可能になりました！ 上記の発表会にて、「自分で作ったGPTを公開して、たくさん他の人に利用されると、その利用量に応じて、収益がもらえる」という話は非常に話題を呼びました。 そこで、おそらく多くの方が「自分のGPTを作って、収益化したい！」「どうやって自分のGPTを作るのか知りたい！」と気になっている方が多いと思います！ そこで、この記事では、自分のGPTを作るためのツールである「GPT Builderの使い方（始め方）」を徹底解説します！ もしも自社のGPT開発の外注や相談をしたい方は、記事末尾のGoogleフォームよりお問い合わせいただければ、お力になります！ また、「ChatGPT」や「OpenAI Dev Day」につい
Gmailと米国Yahoo!のあれ(2024年2月) - /var/lib/azumakuniyuki
メールシステム担当の人はもちろん、インフラ担当の人もDNSの設定とかで既に知ってはると思いますが、 10月にGoogleが発表した2024年2月から始まるGmailとYahoo!(米国)におけるスパム対策強化のあれです。 海外では数年前から"No Auth, No Entry"って「代表なくして課税なし」みたいな感じで言われているアレです。 識者の方々がいろんなところで記事にしてはりますので、他のところであんまり書かれていない気がするとこだけ記します。 まずは公式情報 Google Googleについては以下の二ヶ所を読んで理解して実践しておけば大丈夫そうです、たぶん。 パラメーターのhl=enをhl=jaに変えると日本語版になりますが、更新されるのが遅いので最初に英語版を見ておくのが良いです。 Email Sender Guidelines(81126) Email Sender Gui
Hello,World! gonowayです。 弊社がご支援するお客様とお話するなかで、多要素認証のためにIDaaSが提供しているアプリケーション（以降、認証アプリ）を私物モバイル端末にいれていいのか？という疑問に、わたしたちが普段お客様にご案内していることをざっくりまとめてみました。 3行まとめ 現代では外部の不正ログインから守るために多要素認証が必須になってきている。 多要素認証の実現のため、会社モバイル端末であれ私物モバイル端末であれ認証アプリはインストールしてほしい。 私物モバイル端末にインストールしてもらう場合、エンドユーザーへの説明を行うことが必要。また、ガラケーしか持っていないような例外措置への対処を考えることも必要。 前提 認証要素について 認証要素は下記の3種類です。NIST SP800-63を参考にしています。 記憶によるもの：記憶(Something you know
切り替える理由 自社の主力製品で利用している技術(WebRTC / WebTransport)がブラウザベースのため TypeScript を利用する Go を採用したのは sqlc が使いたかったという理由 sqlc-gen-typescript が出てきたのでもう Go を使う理由がなくなった 自社サービスチーム全員が Go にまったく興味が無い sqlc 自体は便利 そもそも自社に Go への興味がある人がいない 自社サービスの規模ではボトルネックになるのはデータベースであって言語ではない もしアプリでスケールが必要なときは Rust や Erlang/OTP に切り替えれば良い コネクションプールは PgBouncer を利用すればいい TypeScript からは 1 コネクション 1 接続で問題無い どうせフロントエンドでは TypeScript を書く 自社では React
パスワードを使わないパスワードレス認証であるパスキーを推進するFIDO Allianceは会見を開き、既に70億を超えるオンラインアカウントがパスキー利用可能な状態になって、利用が拡大していることをアピールした。国内でも利用が拡大しており、新たにメルカリがボードメンバーに加盟し、住信SBIネット銀行がアライアンスに加盟した。 FIDO Allianceの1年の取り組みが紹介された。写真左からメルカリ執行役員CISO市原尚久氏、LINEヤフーLY会員サービス統括本部ID本部本部長伊藤雄哉氏、FIDO Japan WG座長でNTTドコモのチーフ・セキュリティ・アーキテクト森山光一氏、FIDO Allianceエグゼクティブディレクター兼最高マーケティング責任者のアンドリュー・シキア氏、FIDO Alliance FIDO2技術作業部会共同座長でGoogle ID&セキュリティプロダクトマネージ
OpenAI の DevDay で発表された、GPTs は、特定のタスクに特化したカスタムモデルを作成できる ChatGPT Plus で利用できる新しい機能です。作った GPTs は、自分だけで使うのはもちろん、友達にシェアしたり。ウェブ上で公開することもできます。 この GPTs の機能である Actions を使うと、OpenAPI Schema を元に、外部 API を ChatGPT エージェントが実行するようになります。 この機能を使って Notion などの様々なサービスと GPTs を繋げてみたので、そのデモと GPTs のつくりかたを解説します。 デモ Notion は、API と呼ばれる開発者が Notion のデータを操作し、外部アプリケーションやサービスと連携するための機能が公開されています。そこで、Notion API の OpenAPI スキーマを書いて検索、デ
APIトークン認証の論理設計
SPAやモバイルアプリから利用するAPIを開発する際の、トークン認証のお話です。 どの認証ライブラリを使うべきという話ではなく、トークン認証の論理的な設計について考察します。 私自身も結論が出ていないので、色んな意見が聞けると嬉しいです。 出発点 ユーザテーブルにアクセストークンを持つのが最も安直な発想だと思います。 ログイン成功時にアクセストークンを発行し、該当ユーザレコードにセット。 同時に有効期限もセットします。 認証時には、アクセストークンが存在し有効期限内であれば、認証を通過させ、 そうでなければ認証失敗とします。 ログアウト時には、該当ユーザレコードのアクセストークンを空にします。 発行日時を持ち、システム内に定義された有効期間をもとに、認証時に計算する方法もあると思います。 Laravel Sanctum 等はそういう実装です（しかもデフォルトでは有効期限なし）。 有効かどう
エンジニアの佐野です。カンムはカード決済のサービスを提供しています。カード決済にはいくつかの決済手段があり、マグストライプ、IC、IC非接触(俗に言うタッチ決済)、オンライン決済などの機能が提供可能です。iD のようなスマートデバイスにカード情報を入れてスマホでタッチ決済する仕組みもあります。カンムのプロダクトであるバンドルカードはマグストライプとオンライン決済、Pool はマグストライプとオンライン決済に加えて IC接触決済、IC非接触決済(タッチ決済)を提供しています。今日はセキュリティ的な観点から各種決済手段の特徴や問題点とともに、主に IC 決済の仕組みについて小ネタを交えつつ書いていこうと思います。カンムが提供しているカードは Visa カードでありクローズドな仕様や confidential なものについては言及することはできませんが、公開仕様であったり一般的な事柄のみを用いて
2023年9月以降、Amazonアカウントの不正アクセス被害が急増しています。不正アクセス被害は2段階認証を設定しているアカウントでも報告されており、何らかの方法で2段階認証をすり抜け、ギフトカードなどを無断購入される被害が増えています。 ２段階認証を設定したアカウントで不正アクセス被害が報告 2023年9月以降、Amazonアカウントの不正アクセス被害が相次ぎ発生しており、SNSなどで「ギフトカードを購入された」「2段階認証を突破された」など、被害を報告する声が増えています。 また、2段階認証（2SV）を設定していたとするユーザーからも不正アクセス被害が報告されており、何らかの方法で2段階認証がすり抜けられてしまうことがあるようです。 Amazonのアカウント、不正利用されたー 夜中にギフトカード5,000円×20枚購入されて、速攻メールでどこかに送信されたらしく、即時クレカに請求が来て
この記事の内容は、個人の意見であり感想です。くれぐれもよろしくおねがいします。 とりあえずドラフトですが公開します。識者のみなさまの暖かく、そして鋭いツッコミを期待します。 パスキーについて、非常にわかりやすいブログをえーじさんが書いてくださいました。コレを読んで頂ければほとんどのことが分かると思います。 先日の次世代Webカンファレンスで、私は、「結局、パスキーは秘密鍵と公開鍵のペア」と申し上げた立場からも、この疑問はごもっともだと思いましたので、すこし、私の思うところを述べたいと思います。 パスキーは２要素認証の場合が多いほとんどのユーザは、OS標準のパスキーを使うのではないかと思います。そして、生体認証、もしくは画面ロック用のパスワードやPIN等が設定されていない限り、OS標準のパスキーを使うことができません。そして、OS標準パスキーの利用時には、生体認証もしくは画面ロック解除のため
【バックエンド】駆け出しエンジニアが目指すジュニアレベルのエンジニアとは【2024年版】 - Qiita
はじめに こんにちは。 普段はフロントエンドの開発をメインでやっておりますmamiと申します。 最近バックエンドの方の勉強や、少しずつですがDB設計やAPI作成などの業務もやらせてもらえるようになったので、自分のエンジニアとしてのレベル感や、この先目指すべき道筋を明確にしたいな〜という思いでこの記事を書いております。 これは自分のための記事であると同時に、同じように駆け出し中のエンジニアさんや、ミドル層を目指す手前のエンジニアさんにも刺さる内容になっているかと思います。 今、自分がどのようにキャリアアップしていくべきなのか、どのような道筋でスキルを磨いていけばいいのか。そんなふうに悩んでいる方は是非読んでみてください。 ※内容はバックエンドエンジニアが対象になりますが、フロントエンドの方もなにか通じるものがある…かもしれません。 ちなみにですがフロントエンドの方の記事は下記で執筆しています
ESETは11月22日(現地時間)、「Your voice is my password – the risks of AI-driven voice cloning」において、生成AIにより合成した音声を悪用したソーシャルエンジニアリング攻撃の実験に成功したと伝えた。この実験では、従業員が自社の最高経営責任者(CEO: Chief Executive Officer)になりすまして、財務責任者から自分宛てに送金させることに成功しており、生成AIの危険性について注意喚起している。 Your voice is my password – the risks of AI-driven voice cloning これは事前にCEOの許可を得て行っ実験であり、ここで解説する手法をまねることは犯罪となる可能性があることに注意。この実験と同様の攻撃が今後増加する可能性があると懸念されており、企業や組
こんにちは。アドカレ12/24の記事を簡単にではありますが書かせていただきました。(25日のポストで遅刻ですが) Digital Identity技術勉強会 #iddanceのカレンダー | Advent Calendar 2023 - Qiita はじめに 本日のテーマ：思わず天を仰いでしまうID関連システムトラブル 本日のテーマは、みんな大好き「トラブル」の話です。CIAM(Consumer Identity and Access Management)領域のさまざまなシステムにさまざまな立場で関わり、さまざまなトラブルに遭遇してきた経験を踏まえて、クリスマスの合間の気楽な読み物として記載しましたので、一息ついていただければ幸いです。 今回はトラブルの中でも思わず「天を仰いでしまう」激ヤバトラブルにフォーカスして、私的ランキング形式でお届けしたいと思います。 天を仰ぐトラブルとは？ 私
Note 本記事は、2018 年公開の以下の Blog の内容が、現在の機能/技術にマッチしない内容になってきたことを踏まえ、2023 年現在の機能/技術を元に改めて考え方をおまとめしたものとなります。以前に公開した Azure AD が発行するトークンの有効期間について (2018 年公開) の記事は参考のためそのまま残し、新しく本記事を執筆しました。 こんにちは、Azure & Identity サポートの金森です。 Azure AD (AAD) は、Microsoft 365 をはじめ様々なクラウド サービスの認証基盤 (Identity Provider / IdP) として利用されています。その重要な機能としてユーザーの認証が完了したら、アプリケーションに対してトークンを発行するというものがあります。あるサービス (Teams や Exchange Online、他に Azure
.app 1 .dev 1 #11WeeksOfAndroid 13 #11WeeksOfAndroid Android TV 1 #Android11 3 #DevFest16 1 #DevFest17 1 #DevFest18 1 #DevFest19 1 #DevFest20 1 #DevFest21 1 #DevFest22 1 #DevFest23 1 #hack4jp 3 11 weeks of Android 2 A MESSAGE FROM OUR CEO 1 A/B Testing 1 A4A 4 Accelerator 6 Accessibility 1 accuracy 1 Actions on Google 16 Activation Atlas 1 address validation API 1 Addy Osmani 1 ADK 2 AdMob 32 Ads
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
DMARC をなめるな - 弁護士ドットコム株式会社 Creators’ blog
ソルト付きハッシュのソルトはどこに保存するのが一般的か - Qiita
Gmailのメール認証規制強化への対応って終わってますか？ - エムスリーテックブログ
突貫でおぼえるSPF、DKIM、DMARC | DevelopersIO
パスキーが快適すぎる - yigarashiのブログ
次世代Web認証「パスキー」 / mo-zatsudan-passkey
何故パスワードをハッシュ化して保存するだけでは駄目なのか？ - NRIネットコムBlog
メールアドレスをキーにしてID連携を行う設計の危うさ｜ritou
仕様が読めるようになるOAuth2.0、OpenID Connect 入門
「認証」を整理する | IIJ Engineers Blog
IPA高度資格「情報処理安全確保支援士」暗記すべき用語を体系整理 - Qiita
「しずかなインターネット」の技術スタックを調べる - laiso
認可のアーキテクチャに関する考察（Authorization Academy IIを読んで）
SPF (やDMARC) を突破する攻撃手法、BreakSPF | 朝から昼寝
なぜソーシャルログインの際にemailをキーにして参照するのか
【超入門】GPT Builderの使い方！【GPTs / ChatGPT】
多要素認証を私物スマホでやっていいのか問題
自社サービスのバックエンドを Go から TypeScript へ切り替えるための整理
ドコモが「パスキー」を導入してフィッシング被害報告が0件に パスワードレス認証の効果
GPTsでNotion APIを叩くようにしてみたらやばかった
カード決済のセキュリティ的な問題点とその対策、IC チップの決済とその仕組み - カンムテックブログ
【Amazon】２段階認証を設定したアカウントで不正アクセス被害の報告が急増（2023年9月12日）
パスキーは本当に２要素認証なのか問題、またの名を、あまり気にせず使えばいいと思うよ。｜kkoiwai
ESET社員、生成AIで自社CEOの声を作って不正送金させる実験に成功
思わず天を仰いでしまうID関連システムトラブル - =kthrtty/(+blog)
Azure AD が発行するトークンの有効期間と考え方 (2023 年版)
BudouX: 読みやすい改行のための軽量な分かち書き器