  |
はてなキーワード:ドメイン名とは
「SUKI SUKI」とスペースを含む表記がhttps://sukisuki-shop.com/news/配下のページにあるという情報もある。
「SUKISUKIトレカ forPEAK SPOT」や「SUKISUKIトレカ forKAWAII LAB.」は別の規約が主として適用されるように思う。別サービスであって、さらに後者は運営者がアソビシステムではないと明示されているという情報もある。
SUKISUKIメインサービスは特定商取引法に基づく表記からして、アソビシステム(株)が運営しているという情報もある。
ところでSUKISUKIメインサービスのうち「特典会」と呼ばれるもののうち、チェキの売買（宛名入りのチェキの場合は請負要素もあるかも）に関し、そのチェキの最終顧客向け発送についての（運送業者が使う）ラベルには「SUKI SUKI株式会社」とあるという情報もある。
この商号で調べると、法人番号9011001169146で令和7年4月24日に法人情報指定との情報もある。
SUKISUKIメインサービスのFAQ的ページへのリンクを押すとhttps://docs.asobidas.com/ に行くという情報もある。このURLのドメイン名部分は(株)アソビダス に関連している可能性がある。アソビダスとSUKISUKIを関連付けて説明する、（おそらく）第三者メディアの記事もある、という情報もある。
感想みたいなことだが、たまに運営法人がよくわからないケースは他社でもあるけれど、基本的に信用できないと考えている。
SUKISUKIメインサービスについては、そのサービス経由でアソビシステム所属のグループのアイドルのチェキなどが実際に入手できているケースがみられ、YouTubeでもその模様の一部が配信されているなど透明性も一定程度あり、信用はしてもいいかもしれない。もし問題を起こせばアソビシステムの名前を傷つけるくらいのことはあろう。
ところで仮にSUKISUKIメインサービスで購入ないし請負わせることをしたとき、アソビシステム運営だが「SUKI SUKI株式会社」とかに個人情報が（規約などに明示されることなく）提供されるのだとすると、個人情報保護の観点で問題がある可能性がある
パスキーの設定のタイミングで秘密鍵の作成と公開鍵の登録のところをまるっとジャックできるのであれば、偽のパスキーを登録することができるからである
想定している攻撃シナリオのイメージがよくわからないです。「第三者が何らかの方法で正規のパスキーを窃取する」シナリオでは無いですよね（これは別の手段で防御すべき課題です）。
「偽のパスキーを登録」というのは「フィッシングサイトに対してユーザがパスキーを作ってしまう」ということですか？
フィッシングサイトのドメインに対して作られたパスキーはフィッシングサイトでしか使えないものなので全く意味がありません。
ドメイン騙せないという点においてもそんなものhttpsで達成できていることであり、パスキーだから何かが変わることではない
いいえ。ドメイン名の検証を人間の目でやるのではなく、ブラウザが内部的に行うところが大きな違いです。
人間が「ここは正規サイトだ」と思い込んでパスキーを使ってログインしようとしても、ブラウザが不一致と判断すれば不可能です。
この文章は作者の認知や信念を吹き込まれた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する意味ないです。パスキー一要素だけで、全然セキュリティ強度は高いです。
ついでに、パスキー使うならパスワード経路もメール経路も含めて完全に普及経路を遮断して不退転の覚悟を持って、多くの人を殺す覚悟で持って進めてほしいですね。☺️
それくらいパスキーは劇薬です。本気で覚悟持ってパスキー利用に進みますか？☺️
半端に混在させるくらいなら、
私は長い間、Google Chromeのユーザであった。
君はとても素晴らしいブラウザであった。
どんなウェブサイトでも、瞬時に正しく表示してくれた。君が表示できないのであれば、それはWebサイトが間違っているか、あるいは世界中の誰にもできないことなのだと諦められた。
数年前までは。
この数年で急に何かが起こったわけではない。少しずつ、私が広告から距離を取る方法に慣れてきたのだ。
最初はブラウザの拡張で広告をブロックするところから始まった。
ブラウザの拡張で広告をブロックする方法は、たびたびウェブサイトのレイアウトを破壊した。無理もないことだ。
Webサイトのオーナーにとってみれば、あるはずのものがなくなっているのだから。
そのため、ウェブサイトの閲覧中にそういう気配を察して、ブラウザの拡張をオフにすることもよくあることだった。
その気配を読めずに、このサイトぶっ壊れてる、と誤解してしまうことも本当によくあった。
安心して使えないと言えば、ブラウザの拡張を使うと、ブラウザに尿辞されている全てのコンテンツを見られてしまうことになるので、センシティブなサイトを見るときには止めるのが常識だった。
センシティブなサイトというのは、まあ色々だ。特にログイン画面を開いて、パスワードを入力した後、拡張を有効にしたままだったことに気づいてドキドキしたこともあった。
それからしばらく経ち、広告をブロックするためにDNS を使うようになった。
専用のDNS リゾルバーを設定することで、広告関連のドメイン名を解決できなくする仕組みだ。私はこれに感動した。
これによってブロックできる広告の種類が増えた。今まではブラウザの拡張を使っていた時は、ブロックできるのは基本的にはPCのブラウザの広告だけだった。
DNSを使った仕組みを使えば、スマホのブラウザに表示される広告はもちろん、アプリ内に表示される広告もブロックできるのだ。
導入した当初の感動は、今でも覚えている。
広告がブロックされるとそのスペースにグレー（グレーでなかったかもしれない。忘れてしまった）の四角が代わりに表示されるのだが、スマホのブラウザでウェブサイトを見ると、三分の一ぐらいがグレーだった。
それからまたしばらく経ち、Microsoft Edge に乗り換えた。スマホ版のEdge はデフォルトの機能として広告のブロックができる。
今はそれを有効にして使っている。引き続きDNSを使った広告のブロックも併用している。
これでほとんどの広告はブロックできているし、広告の跡地にグレーの四角が表示されることも無くなった。
非常に快適なだけでなく、一周回って、古き良きインターネット、という感覚を味わえるので、特にインターネット中高年にはおすすめだ。
そういうわけで、もうスマホではEdge がメインのブラウザになってしまったので、PC でもブラウザはEdge を使っている。
Windows でも、Mac でもEdge を使っている。以前は全ての環境でGoogle Chrome だったのだが、今は特にスマホ版のウェブサイトでGoogle Chrome を要求する一部のサイト（吉野家のサイトがそうだ）でしか使っていない。
一昔前、職場ではIEしか対応していないウェブサービスを使うためにIE を開いていたぐらいに老人の私にとって、今のGoggleChrome は完全に昔のIE だ。
（そうはいっても、当時のIEよりは遥かにマシなIEではある。それは認める。）
「example.com」ディレクトリの中の「some」ディレクトリの中の「page」ページ
「example.com」なんてドメイン名に見えるような紛らわしいディレクトリ名を好き好んで使うかよ、という議論はさておき
