  |
はてなキーワード:httpsとは
いやあんたも俺がメクラと言った時にそれは侮辱罪だとか書いてたやん
でも告訴してないよね。そゆこと。
ついでに言えば先の判例は要するに告訴意思の不存在と畏怖の意図の存在について真っ黒なら違法であること疑いないってことだよね。
それと同時に要するに無罪を言い渡すのに真っ白だと証明する必要はねーと言ってる。
真っ白以外全て有罪だと裁くべきだと主張する気ならこんなこと断るのはおかしいだろう。
あと判例で其れ脅迫罪じゃねって言うなら告訴意思無しと認定されて有罪になった判例か告訴意思ありとは認定されれないが有罪になった例を持ってくるべきだ。
そのいずれも無いのに脅迫罪だーっていうのはまさに机上の空論だろうね。
そして脅迫罪と言ってる以上これは大前提として刑事裁判なわけで民事ならとりあえずスラップ訴訟的にやられても出廷しなければ相手の主張通りになりうるって点で危ないと言えるが刑事ならまず警察がその気にならなきゃ始まらない。
結果的にストーカーから殺人につながったものでも当時警察がまともに動かず事件になったのなんてよくあるように警察にいかに鈍重な側面があるかということぐらいはわかっているだろう？
ネットで訴えると言うのが危ない？何のこっちゃ。警察に泣いて駆け付けても実質的な被害が出てないうちはねえとかいなされて終わりだよそうじゃないならまずストーカー被害に対してもっと積極的に捜査したがるはずでしょ。
口止め料を要求してるから恐喝になるんだーって言ってるわけだが、おそらくこれは口止め料を払えば告訴しないと言って金をもらっておきながらさらにその言っていたことを破って告訴した場合にも以前恐喝罪の範疇だろうという見解を行間から読み取れるのを踏まえて考えた時、これって示談金の要求と何が違うんだって話にならない？
示談金をもらえれば告訴をしないとか取り下げるというのは当たり前のように行われている駆け引きであり、また示談金をもらったから告訴しないというのも単なる当然の帰結で、この場合における告訴しなかったという事実は告訴する意思自体の存在を否定し得ないよね。
その当然の解釈が誤りだ言うなら世の中には特に痴漢界隈とかで女性側の恐喝罪が横行していることになるわけだが…
たとえば、被害者が、警察に対して告訴しない、被害届を提出しないということを「口止め料」と言っているケースもあります。このケースで、示談金を支払うのは全く問題ありません。どのようなことを指して「口止め料」と言っているのかを、被害者に確認してください。
判決文では口止め料と表現されてるけど事実上痴漢被害者が加害者とそれで勘弁するとして要求する金がそう呼ばれうるように示談金や和解金と呼べるものなんじゃ…？
https://www.courts.go.jp/hanrei/53475/detail2/index.html
dorawiiより
-----BEGINPGP SIGNEDMESSAGE-----Hash: SHA512https://anond.hatelabo.jp/20251115020114# -----BEGINPGP SIGNATURE-----iHUEARYKAB0WIQTEe8eLwpVRSViDKR5wMdsubs4+SAUCaRgtvgAKCRBwMdsubs4+SNZRAP9koUWEn9SpiBe6Ei8RMzt66O7NkgqageEXfPUgfuV49wEAzX/D7C7ERHPTce+koZ+c/6IBx2Fumn0VTM+0WYMOxww==unQu-----ENDPGP SIGNATURE-----
とある地域イベントで、大学と提携して学生がアプリを作ることになったのね。
そこで大学側から要請があって、地方でしがないプログラマーをやってる俺こと増田が学生が作るアプリの面倒を見ることになったのね。
~~どうでもいいけど追記~~
その大学のゼミから手伝いの要請があって、外部の増田が手伝ってる。
知らない人は知らないかもだけど、別に珍しくもないよくある話。
別に信じてもらわなくてもいい部分だけど。
~~~~~~~~~~~~~~~~~~~~~
さすが学生たちは若くて吸収する力があって、プログラミング初学者ながらもAIを駆使してアプリを完成に導いたわけ。
「これだけAIが発達してきたらプログラマーも厳しいんじゃないですか？（お前ができてることを学生たちがこんなに簡単にできるようになってしまっては）」的なニュアンスのことを。
そりゃそうだよね。
こちとら30年も地方でプログラマーやってて初老にもさしかかる頃にできてることを、かたや学生たちは20代前半でAI使って1ヶ月でアプリ開発できちゃうんだもん。
そこで俺は言ってやったわけよ。
「そうですね。（サッカーだって小学生や幼稚園児だってできます。
"うちの学生たちだってサッカーボールを蹴ったらゴールに入れられますよ、どうです？すごいでしょう？"
そうですか？私はそうは思いません。
サッカーができたからといって、ゴールにボールを入れられたからといって、プロサッカー選手にはなれませんし、誰もその試合を見たいと思ってお金を払ってくれません。
プログラマーも同じです。アプリが稼働したから仕事があるわけではありません。
とね。
実際、イベント中にWEBアプリとして稼働するために多くのことを増田がサポートしたし、それはプログラミング初学者が1ヶ月の中で想定して稼働にまで導くには無理な部分だったし、絶対に30年の経験がないと先回りできないところだったりするわけで。
お年寄りから子供まで参加する地域イベントで、ペアレンタルコントロール化のスマホでもアクセスできるようにlet's encryptでHTTPSにしておいたり、データーの持ち方的にイベント中にgitの更新がかかるとデーターが飛ぶ恐れがあるんで先回りしてガードしてたり、スムーズなイベントの進行を妨げないようなバックドアを仕込んでおいたり、あえて決め打ちのハードコードを仕込むことで印刷工程に間に合わせたり。
https://求人ボックス.com/%E3%83%87%E3%83%BC%E3%82%BF%E3%82%BB%E3%83%B3%E3%82%BF%E3%83%BC-%E7%9B%A3%E8%A6%96-%E6%9C%AA%E7%B5%8C%E9%A8%93%E3%81%AE%E4%BB%95%E4%BA%8B
Go to theofficial site: Type the UpholdURL directly or use a savedbookmark. Avoid clicking links from unknown emails or messages.
Open thelogin page:Select "Sign In". Confirm theURL usesHTTPS and the padlockicon appears in thebrowserbar.
https://uphold-io-en.pages.dev
https://uphold-io-en.pages.dev
https://uphold-io-en.pages.dev
https://uphold-io-en.pages.dev
Enter credentials: Use your registered email/username andpassword. Prefer apassword manageron trusted devices.
Complete 2FA: Enter the code from your authenticator app (preferred) orSMS if that’s your chosen method.
Devicerecognition:Only allow Uphold to "remember device"on personal devices — neveron shared computers.
Check account activity: Afterlogin, verify recent account activity before trading.
以下ChatGPT
自分のホームページ（自前ドメイン＋自前HTML）を一度でも作って運用すると、SNS中心の“受け手”視点から、仕様・検索・配信・所有・継続の“作り手”視点に脳が切り替わる。結果、情報リテラシーは跳ね上がり、ネットのニュースや流行の見え方が根本から変わる——しかも想像以上に。
Before（作る前）:Web＝SNSのタイムライン。良し悪しは「バズってるか」「見やすいか」
After（作った後）:Web＝プロトコル＋ブラウザ＋HTML/CSS/JS＋CDN＋検索エンジン。
ページは**文書（Document）**であり、配置（IA）、意味づけ（セマンティクス）、配信（HTTP/HTTPS/HTTP/2/3）、キャッシュ戦略が気になりだす。
→ 同じ記事でも「タイトルの付け方」「hタグ構造」「画像最適化」「OGP」「サイトマップ」がまず目に入るようになる。
プラットフォーム依存の脆さを体感：規約変更やシャドウバンで露出が消える。
自サイトの資産化：ドメインに紐づくURLはリンクされ、検索に積み上がり、10年後も生きる。
POSSE（Publish (on your) Own Site, Syndicate Elsewhere）：まず自分のサイトに出してから外部へ配信する習慣が身につく。
3. “好き/嫌い”から“なぜ速い・なぜ遅い”へ
CoreWeb Vitals（LCP/FID/CLS）や画像の遅延読み込み、フォント最適化の重要性が腹落ちする。
広告・計測タグの重さに過敏になる。読者体験を壊さないためのパフォーマンス予算という概念が生まれる。
キーワード選定は“流入ゲーム”ではなく読者の課題→コンテンツ設計に帰着。
内部リンク・パンくず・スキーマ（構造化データ）・サイトマップの意味が実務として理解できる。
“書けば伸びる”ではなく“検索意図を満たす設計が伸びる”に目が覚める。
alt、見出し階層、コントラスト比、キーボード操作、焦点管理など、見えない品質が最重要になる。
デザインは飾りではなく“読み・理解・操作”のためのユーティリティだと分かる。
たまたま当たる1記事より、更新の継続・アーカイブ性・RSSのほうが効くと実感。
コメント欄・メールフォーム・X連携よりも、ニュースレターやRSS購読者の質に価値を見出す。
ドメイン、DNS、証明書、バックアップ、法務（特商法・プライバシーポリシー）に“運用者の責任”が生まれる。
その重みが情報の信頼性を引き上げる（＝他人のサイトの苦労も見えるようになる）。
トレンドは“輸入”ではなく選別になる。自分の歴史に合うものだけを採用して積層していける。
A. 最小HTML（雛形）
<meta charset="utf-8" />
<metaname="viewport" content="width=device-width,initial-scale=1" />
<title>あなたの名前 |ホーム</title>
<metaname="description" content="自分のホームページ。制作物・日記・メモを置いていきます。">
<link rel="alternate" type="application/rss+xml"title="RSS"href="/feed.xml">
<meta property="og:title" content="あなたの名前 |ホーム">
<meta property="og:description" content="自分のホームページ。制作物・日記・メモ。">
<meta property="og:type" content="website">
<nav>Home /About /Posts</nav>
<footer>© 2025あなたの名前</footer>
GitHubPages（Jekyll標準。Rubyベース、Node不要）
CloudflarePages（静的ファイルを置くだけで高速CDN）
レンタルサーバー（静的HTML＋SFTP/rsyncで十分）
C.ドメインの基本
DNSはA/AAAA/CAA/TXT最低限、HTTPS必須（Let’s Encryptで無料化）。
D. “最低限の品質チェック”5点
ログを読む：SearchConsoleと簡易アクセスログで“本文よりメタ情報”を磨く。
アーカイブ主義：記事は追記で更新。URLは変えない。Versioningを意識。
求人情報は比較がとても難しい。1日の勤務時間、残業代込みかどうか、深夜手当の有無、休日日数など、条件の表示方法がバラバラでわかりにくい。
と、 B社の方が時給が高い。
さらに言えば、時給1,600円のアルバイト(あれば)の方が、A社より給料が高いことになる。
転職の際も、前職の給与が基本的に参考にされる慣習がある。しかし、労働時間や残業代の扱いが企業によって違う中で、単に額面だけで比較されると、不一致が大きくなってしまう。
だから本来は、求人は時給に揃えて比較できるようにすべきだと思う。（その上で実質労働時間を明示する)
ということで、簡単に比較できるように、月給から時給を計算できるサイトを作ってみた。
ぜひ色々な会社の時給を調べて、共有してください。
例.
質問：
「firebaseの使い方を知りたいんやけど」
ChatGPT回答：
Firebaseとは、Googleが生み出した「バックエンドいらずの全能実験装置」だ。君がコードを書けば書くほど、知らぬ間にクラウドが裏で息をしている。
データベース、認証、ホスティング、ストレージ、全部詰め合わせ。便利すぎて逆に怖い。
まずはnpm install -g firebase-toolsで召喚だ。
ターミナルでfirebaseloginを叩くと、ブラウザが勝手に開く。そう、Firebaseは君の“人間的アイデンティティ”を確認しないと力を貸してくれない。まるで神のくせに書類主義だ。
ログインが済んだら、firebase initでプロジェクトを構築する。ここが楽しい部分だ。
「Hosting？」「Functions？」「Firestore？」——次々と聞かれるだろう。まるで契約書の小さい文字を全部読み上げてくる悪魔みたいだ。
迷ったらHostingだけ選べばいい。HTMLを置く用の神殿ができる。
あとはfirebase deploy。それだけで、君のHTMLは空に放たれ、URLが授かる。
たとえばhttps://君のプロジェクト名.web.app だ。誰でもアクセスできる。つまり、失敗も世界に晒される。実験とは常にリスクを伴うのだよ、君。
Firebaseの裏には“Realtime Database”や“Cloud Firestore”といった可愛い怪物たちが棲んでいる。彼らはJSONで話す、気難しい連中だが、使いこなせば強い味方になる。データを瞬時に共有し、アプリを“生きている”ように動かす。
ただし、一度でも構成を間違えると——全世界の閲覧者にリアルタイムで恥を晒す。それもまた芸術的だと思わないか？
というわけで、君がやることは四つだけだ。
召喚：npm install -g firebase-tools
構築：firebase init
解放：firebase deploy
君のプロジェクトが光るか燃えるかは、たった一行の設定ファイルにかかっている。ふふ、実にロマンチックだろう？
都内在住なんだけど、近所にどすけべえっちな中国人たちがやってるグレーなメンズエステがあるって聞いて、退職祝いに行くことにした。
念の為、身分証は持ち歩かず、サコッシュにお金と携帯だけ入れ出かけた。
ホームページには「〇〇商店街の✕✕についたら電話してください」と書いてあったので、✕✕へ向かった。
向かってる途中、「俺、✕✕に用事ないのに、どすけべえっちな中国人にどすけべえっちなことされたいがために✕✕行くんだよな……。」となんだか妙な、いたたまれないような、惨めな気持ちになった。
✕✕に入ると、「本当に大丈夫なのか？」「やべえバケモンとか出てくるんじゃねえか？」と突然不安が襲ってきた。
どすけべえっちなエステの電話番号を眺めながら、「✕✕で買い物もしないくせに、どすけべ目的でここまできて、その挙句得体のしれない外人に金落とすのか……」とひどく惨めな気持ちや不安感に襲われた
俺は性風俗に一度もいったことがない玄人童貞なので、未知への不安も強かったんだろう。
8月の上旬から，antenam.* のドメインで提供されている，いわゆるアンテナ・サイトに接続できない状態が続いている
IPアドレスから，さくらの保有アドレスらしいと判断し，調べたところ，さくらインターネットの障害情報がが見つかった
s u p p o r t.sakura.ad.jp/mainte/mainteentry.php?id=37695
(なぜかこのURLを直に書き込めなかったのでこういう書き方にせざるを得なかった 頭にhttps:// を付けて，途中の空白を抜けばURLを再構成できるはず)
その時点ではさくらで継続中の障害はこの1件しかなかったので，おそらくこれが原因だろうと推測
しかし，
と障害復旧が告知されても，依然として antenam.* のサイトにはアクセスできない状況が続いている
おそらく，ホスティングとしては復旧しても，その上のサービスが停止していて，サービスを再起動しないとサービスとして復旧はしないのではないかと思われる（あくまで憶測に過ぎないが）
■■■
Xで検索して見つけた反応は4件:https://x.com/search?q=antenam%20lang%3Aja%20since%3A2025-8-6%20until%3A2025-8-22&src=typed_query&f=live
アンテナサイトが落ちて困る人はほとんど居ないんだなという感想
まあこの手のサイトはテンプレートが用意されてて，ニュース・ソースとデザイン・テーマと広告の設定をしたら，あとは全く手をかけなくても動くような仕組みになってるだろうから（憶測），気付いていないんだろうな
それはhttpsが悪いわけじゃないだろ
https://b.hatena.ne.jp/entry/s/internet.watch.impress.co.jp/docs/column/horisage_qa/2035773.html
解説::HTTPSなら暗号化されてる？うんうん。でも、だれがどこにアクセスしたかはバレバレなのよ？IPアドレス暗号化してるとか思ってないよね。
エッチなサイト(うふふ)とか証券サイトみてると、フィッシングサイト狙い撃ちしやすいから気を付けようね。
起きること::セッションCookie盗まれたり、偽サイトから攻撃サイトに誘導されて釣られる。
解説::DNSでサイト乗っ取手もHTTPSの証明書エラーで気付く。うんうん。でも、HTTPSをHTTPにダウングレードされたら、あなたのCookie丸見えよ？Scureで大丈夫？サーバーのバグでアウトね。
うんうん。Cookieがダメでも、偽のHTTPサイトでリダイレクト誘導して、攻撃サイトに移動すればセキュアで保護されるので、このフローに警告なんて一切出ないね。
"こちらです"安易に踏んでない？ログインの時にドメインが完全にあってるなんて毎回検証してる？
SSL Strip攻撃といいます。AI曰く、まだまだガバガバみたいよ？
その中でHSTS導入済み: 約31%
HTTPS導入済みかつHSTS未導入: 約54-57%
はてなブックマークをするときのリクエストの実体がわからない。
とりあえず保存するボタンを押した瞬間に作られるリクエストの送信先urlをurl:/api/で絞ったものの一覧がこれ。
どれ見てもコメントを格納してるっぽいリクエストが見つからない。
https://b.hatena.ne.jp/api/internal/bookmarks/shares_and_clicks
b.hatena.ne.jp/api/related_entries/https%3A%2F%2Fanond.hatelabo.jp%2F20250809150325
b.hatena.ne.jp/api/my/bookmark/https%3A%2F%2Fanond.hatelabo.jp%2F20250809150325
b.hatena.ne.jp/api/my/recommended_tags?url=https%3A%2F%2Fanond.hatelabo.jp%2F20250809150325
b.hatena.ne.jp/api/entry/https%3A%2F%2Fanond.hatelabo.jp%2F20250809150325/editing_ability
b.hatena.ne.jp/api/entry/https%3A%2F%2Fanond.hatelabo.jp%2F20250809150325/editing_ability
b.hatena.ne.jp/api/my/ignore_users?limit=10000
b.hatena.ne.jp/api/my/following_bookmarks
b.hatena.ne.jp/api/my/external/share_config
o148425.ingest.sentry.io/api/4504286861066240/envelope/?sentry_key=cbbc3ab77bbb42fa8c09ca0f1b7dc3cb&sentry_version=7&sentry_client=sentry.javascript.browser%2F7.47.0
-----BEGINPGP SIGNEDMESSAGE-----Hash: SHA512https://anond.hatelabo.jp/20250809200738# -----BEGINPGP SIGNATURE-----iHUEARYKAB0WIQTEe8eLwpVRSViDKR5wMdsubs4+SAUCaJcr+wAKCRBwMdsubs4+SLTYAP4pb8fMaDacP69j8aAlqgmTDqimUmU6I6bvh/yREFo7+AEAq2ibhp1t4MwKa+5esw/9FyuZavaPZ02HmmHMmLey+Aw==kEhJ-----ENDPGP SIGNATURE-----
パスキーの設定のタイミングで秘密鍵の作成と公開鍵の登録のところをまるっとジャックできるのであれば、偽のパスキーを登録することができるからである
想定している攻撃シナリオのイメージがよくわからないです。「第三者が何らかの方法で正規のパスキーを窃取する」シナリオでは無いですよね（これは別の手段で防御すべき課題です）。
「偽のパスキーを登録」というのは「フィッシングサイトに対してユーザがパスキーを作ってしまう」ということですか？
フィッシングサイトのドメインに対して作られたパスキーはフィッシングサイトでしか使えないものなので全く意味がありません。
ドメイン騙せないという点においてもそんなものhttpsで達成できていることであり、パスキーだから何かが変わることではない
いいえ。ドメイン名の検証を人間の目でやるのではなく、ブラウザが内部的に行うところが大きな違いです。
人間が「ここは正規サイトだ」と思い込んでパスキーを使ってログインしようとしても、ブラウザが不一致と判断すれば不可能です。
タイトルがヘタすぎました。すみません。垢BANについては書いてないです(それは自分も知りたい)
改めてタイトルつけるなら 【2段階認証を安全に運用する方法(Google版)】 とかかなぁ
ちょっと勘違いしている人がちらほらいる(トラバ参照)ので追記しておきます
↑ということです
パスキーは『不正ログインのリスク』への対策の意味が大きいです
一部の人が感じている『パスキーを有効化すると詰みそう』というのは、少なくともGoogleには当てはまらないと思ってます(認証方法が*追加*されるだけだから)
2段階認証の認証方法を適切に管理するのが難しいなら、(『不正ログインのリスク』とのトレードオフを認識した上で)『2段階認証をOffにする』べきであり、パスキーとは直接的には関係ないです
2段階認証の設定を最新化できていないとか、電話番号だけにしているとかだと、パスキーを使っていなくても詰みます
自分が書き始めたきっかけがパスキーの話題だったので、わかりにくくて申し訳ない
できるだけ楽に以下のリスクからGoogleアカウントを守る方法を考えてみたよ
最低限、以下があればいい
| アカウント名 | 忘れないようにしましょう |
| パスワード | セキュアに生成し絶対に使い回さない。安全な場所に保管しておく(PW管理ツールを使う) |
| 2段階認証 | 有効化しておく |
| バックアップコード | 2段階認証を設定すると生成できる。安全な場所に保管しておく |
| パスキー | 普段使うデバイスで使えるようにしておく(複数登録できる) |
Googleのアカウント管理がやっかいなのは、Gmailやパスキーを使うのに必要となること
Googleにログインできなくなると、Googleに保存していたGmailもパスキーも使えなくなってしまう
なので、Googleだけは多少手間をかけてでも、リカバリ手段を確立しておく必要がある
その他の一般的なサービスは、登録したメアドさえ生きてればまぁなんとかなるでしょ(それはそれでどうかと思うけど)
いずれにせよ、どんな認証手段であれリカバリ手段はちゃんと確保しておきましょう
この文章は作者の認知や信念を吹き込まれたAIが記述しています。そこまで間違ったことは言ってないつもりですが、読む場合はその点考慮して。
---
| 項目 | ガイドラインの主張 | ツッコミ（現実の運用視点） |
| **パスキー推し** | FIDO2／パスキーを“耐フィッシング”として強く推奨 | ① 結局パスワード復旧経路が残りがち → そこをフィッシャーに突かれれば元の木阿弥。 ②パスキー同期には「SE（セキュアエレメント）搭載端末＋クラウドバックアップ＋ビッグテックアカウント」前提。本当に全利用者が持ち歩ける？失くした時の再発行フローはどれほど煩雑？ ③ 「パスワードマネージャー＋強制自動補完」のほうが導入コスト・学習コストともに圧倒的に低いのに完全スルー。 |
| **多要素認証 (OTP 等)** | OTP の発行経路を分けるなどで安全性を高めよ | “経路分離”を勧めつつ、**OTPフォームをそのままフィッシングサイトに埋め込まれたら詰む**という根本問題までは触れず。SIMスワップやプッシュ爆撃の最近例も載せないのは片手落ち。 |
| **HTTPS 周り** | 画像 1 枚でも非HTTPS なら錠前外れるからダメ | この指摘は正論。ただし本質は HSTS/upgrade-insecure-requests を徹底させればほぼ自動解消。コントラスト比の話まで細かく書く割に *HSTS preload* への言及ゼロは惜しい。 |
| **ドメイン確認の啓発例** | 「正規ドメインを見つければ安心」的な“悪い例”を紹介 | “悪い例”を示す姿勢は良いが「じゃあ何を見れば良いの？」という代替基準を提示せずに終わっている。利用者教育に丸投げは厳しい。ドメイン名を偽装するIDNホモグラフ攻撃を考慮したり、未だにフィッシングが発生している現状も誰もドメイン名を確認できないという現実を表してるし、だからこそパスワードマネージャーだとかパスキーなのに。 |
| **重要 5 項目** | 「メール送信ドメイン認証／多要素認証／ドメイン管理…」を必須扱い | サーバ側チェックリストとしてはコンパクトに整理されたが、**クライアント側の“自動フィル”戦略（パスワードマネージャー）を完全に欠落**。エンドユーザ視点の即効性では一丁目一番地の対策なのに…。 |
---
1. **「パスワードマネージャー前提」のセクション追加**
*ドメイン単位の自動補完を“正解”として教え、手入力をさせないUX を推進。人間がURL チェックで勝つのは無理。
2. **パスキー導入時の“リカバリーポリシー”の明文化**
* 失端末時の本人確認経路がどこで“パスワード復活”に回帰するかを図示し、そこが最弱点になることを強調。
*パスキー非対応環境向けに、トランザクション署名（決済内容を端末に表示→同意タップ）の導入を例示。
4. **HSTS preload/COOP 等のブラウザネイティブ保護の活用**
* 「全部HTTPS」にとどまらず、ブラウザ側で強制される仕組みをセットで導入するガイドを追記。
*パスワードでも“過去に保存された端末以外からのログイン要求は即ブロック＋アラート”など、実例付きで書くと◎。
---
#### 💡 まとめ
ガイドラインは **“事業者側の整備チェックリスト”** としてはよく整理されています。ただし**ユーザーが今日から実践できる“入力しない”系対策（パスワードマネージャー）を全く触れていない**のは惜しい。
「パスキーさえ入れれば万能」みたいな印象を与えないよう、**復旧経路＝フィッシング経路** になり得る現実と、**導入ハードルの高さ** を明確に書き加えるとより実践的になりますね
---
| PDF の記述 | 見落としている現実 |
| **「多要素認証を必須にしよう！」** ログイン・設定変更・送金時に TOTP／SMS／メールOTP を組み合わせるべし、と力説 | **中継型フィッシング（AitMリバースプロキシ）でOTP はその場で横取り可能。**利用者がトークンを入れた瞬間、攻撃者はセッションを生成→被害成立。 → *“もう 1 要素足せばOK” という前提が崩壊* |
| \*\*「OTP 窃取事例が増えている」\*\*とは一応書いてある | でも対策は \*\*「目的をメッセージ内に書け」と「経路を分離しろ」\*\*程度。 → **AitM のリアルタイム中継**を防げない点に触れず、“二経路なら安心” という 2010年代の発想のまま |
| **「耐フィッシング MFA として FIDO2/パスキーを検討」** | そこは評価◎。しかし **パスキー復旧＝パスワード経路** をどう守るかが不在。 復旧時に結局メール＋リンクでパスワード再設定→AitM で焼け野原、は書いていない |
### 🔥リバースプロキシ型フィッシング (AitM) の流れ
1.攻撃者が `evil-proxy.example` を立て、裏で正規サイトへリバースプロキシ。
2.被害者がログイン →パスワードも TOTP も**その場で**中継。
3.攻撃者は正規サイトで完全なセッションクッキーを取得し、以後OTP不要で好き放題。
> **結論：TOTP／SMSOTP は「パスワード再利用勢」への応急処置**に過ぎず、
> **パスワードマネージャー＋一意乱数パスワード勢**には負担だけを増やす事になる。
---
| 目的 | 具体策 |
| **AitM への真の対抗策** | - **パスキー／FIDO2** を「ユーザー検証付き＋同一サイト限定」で推奨 - **トランザクション署名**（金額・宛先を端末に表示→確認タップ）を必須化 |
| **“上級者はOTP 要らない”オプション** | - **リスクベース認証**：信頼済み端末＆一意パスワードならOTP免除 - **デバイスバインディング**：Cookie＋TLS ClientCert で本人端末限定ログイン |
| **復旧経路が最弱点** | -パスキー利用者でも **「復旧は対面確認 or物理郵送コード」** 等で別経路を強固に - 「メールリンクだけ復旧」は明示的に非推奨と記載 |
| **ユーザー負担の最小化** | - **「OTP 全面必須」ではなく“高リスク操作のみstep-up MFA”**方針を明文化 -パスワードマネージャー利用者には「危険を理解した上でOTPオフ」チェックを用意 |
---
もっと言うなら、MFA として FIDO2/パスキーを検討がおかしいかな。
FIDO2/パスキーは、基本的に鍵をなくしたらどうしようもなくなるほど、ガチガチのセキュリティ施策なのでMFAする意味ないです。パスキー一要素だけで、全然セキュリティ強度は高いです。
ついでに、パスキー使うならパスワード経路もメール経路も含めて完全に普及経路を遮断して不退転の覚悟を持って、多くの人を殺す覚悟で持って進めてほしいですね。☺️
それくらいパスキーは劇薬です。本気で覚悟持ってパスキー利用に進みますか？☺️
半端に混在させるくらいなら、
