  |
はてなキーワード:スワップとは
DCには勝てるレーンがマジで無かったよ 強いて言えばmidがワンチャンあるけど、Coreは他チームも強いからせいぜい互角になっちゃう
jgにとっては間違いなくやっててキツいチームだっただろうな
それでjgが「俺がキャリーチャンプを」って思っちゃう気持ちは分かるんだけど、レーンで有利引けないって分かってるなら尚のこと集団戦を安定させられるチャンプにするべきだったね キル取れないけどデスを重ねない程度にはレーニング出来てたし
本文にも書いたけど、ご指摘の通りjgのコールは実際微妙。敵味方の構成やパワークパイクも全然考えてない感じで、ミクロはともかくコーラーには向いてなかったね
練習中、相手のTopにVladがいるのに「これlate行ったら絶対負けるから～」みたいな発言が一回も出なかったし、考えてもないみたいだった
＞これじゃ萎縮して選手もやりづらい
本人が上手いことと教えるのが上手いことって別なんだよなって強く思ったね
見てた限り、練習でのらいじんはマクロ面をめちゃくちゃ重視してたんだけど、そんなことよりレーニングどうにかしろよって見てる側としてはずっと思ってたな スワップの練習なんかしてる場合じゃなかったと思う
全員基本的な座学と全チャンプに対する知識が圧倒的に足りてない コーラーに知識が足りてなくて優勢劣勢の判断が正しく出来ないのは特に致命的
スクリムやる暇があるなら同じ時間でソロキュー回させるべきだったと思うよ
らいじんは生徒の実力をあまりにも過大評価し過ぎてたよな 基礎があって上手い人に教える方が向いてそうだと思った
そこであんま上手くない奴をちゃんと一から叩き上げする他チームとの差が出たね
追記：
TopはTank固定だからレーンで有利取れる可能性は低いけど、集団戦の立ち回りは普通にかなり上手かったと思う
他チームより明確に上手いTankがいるってだけでメチャクチャなアドだから尚のことそれを活かせるpickをjgは選ぶべきだった
「Topには期待出来ない」って事実に反する雰囲気がリスナーには出来上がってたけど葛葉には関係ないし、あれでTankが頭一つ抜けてチーム内で上手いって分からないならjgにもコーラーにも向いてなかったな……
え？って思ったら、誰かに蹴られて、そのまま電車に押し込まれた。
慌てて降りたけど、蹴ってきたのは弱者男性。
フードかぶってて、うつむいてて、でもしっかりこっち見てニヤッとしてた。
そして走って逃げ出した。ダッシュで。
ふざけんなって思って、すぐに私の能力「PositionShift（ポジション・シフト）」を発動。
座標の入れ替え。弱者男性の今いる場所とを、ちょうど線路の上をスワップ。
運悪く、いや運よく、電車は動き出した。
ぎぎ…って音。ブレーキ？いや、遅い。
そいつの顔、真っ青だった。
口パクで何か言ってたけど、もうどうでもよかった。
目が赤く光って、周囲の空間が歪み始めた。
「ロスト・サンクチュアリ」って聞こえた。
なんか発動した。世界がぐにゃってなった。
電車も、人も、音も消えてた。
…は？なにこの展開。
回答頂いたのに夏バテで寝込んでいたため、匿名ダイアリーを読むことができず申し訳ありません。
＞『パスワード再設定用の連絡先が電話番号だけだと、パスワードを忘れたうえに電話番号を手放したら詰む』
パスキーとは関係なく、そんなことはどこにも書かれておらず、推測して対処しろと言うのは素人にはずいぶんな対応。
後、パスキーのリカバリはできないので、パスワードはまだまだ必要ですって案内してほしいものです。
＞Googleにおけるパスワード忘却時のリカバリ手段は「再設定用の電話番号またはメールアドレス」であり、2FAやパスキーの設定は無関係
パスキー設定アカウントでスマホ紛失時にパスキーでログインできない状況の手順をテストした際に確認した事象で
何故かパスキーのリカバリではなく、パスワードでのログインを要求されるのでパスワードリカバリを試しています。
パスキーが無関係であるならパスキーでログインできない場合はパスワードでログインする必要あること（パスワードでログインできること）を表記してもらいたいですね。
＞単純に、あなたが「パスワードを間違えた」から、パスワードの再設定の処理になっているのです
「気持ちを汲む」必要はありませんが、パスキーでログインできない人がどのような状況なのかを考慮したリカバリ手段が提供されてしかるべきと考えています。
「リカバリできないのはパスキーのせいじゃない」と言えば大多数のユーザーが納得できるならいいのですが。
パスキーでログインできない時にパスワード再設定処理に回すのもおかしいですし、電話番号求められるのケース分けされてないなと思うのみです。
＞パスワード再設定用の連絡先に電話番号もメアドも設定されていなければ、恐らくその時点で「詰み」です
＞# 状況から察するに、恐らく最初にGoogleアカウントを作成する際に電話番号だけは登録していたのだと思います
試した際にGogleアカウント作りましたが「電話番号」は必須で要求されます。
＞#Googleアカウントの設定で、([セキュリティ]ではなく)[連絡先情報]の方に電話番号が設定されている状態です
その通りでアカウント作成時登録した電話番号はパスワード再設定時の連絡先に使えないとなっています。
＞# ここの値が[セキュリティ]-[再設定用の電話番号]にコピーされる挙動をしたような気がします
コピーされないようでした、パスワードリカバリ用の電話番号として同じ番号でも登録しなければならない様子です。
パスキー設定時に「認証機紛失破損に備え、2FA設定やパスワードリカバリが可能であることを確認ください」と
案内を表示してもらえれば満足します。
＞事前に登録されていない連絡先経由でパスワードを変更できたら、それは一般的にはセキュリティホールです
ですのでパスキー設定時にリカバリ用連絡先の登録を強制するようにして頂きたい。
＞再設定用の電話番号やメールアドレスは、*2FAの設定とは別に*、パスワードリカバリ用に設定するものです
ことGoogleアカウントに限っては、パスキー設定後のスマホ紛失時にもリカバリで必要になることが案内されていないことに疑問を感じています。
パスキーの設定したのに依然パスワードが必要と喧伝されていませんので。
＞本気で理解する気があるのなら、Googleアカウントの設定を確認してください。そのようになっていることは一目瞭然です
パスキーに関連した表記になっていないのが不案内なんです、一目瞭然ではないんです。
別に仕組みを理解できていない訳ではないのです、パスキー設定してスマホ紛失した際の導線が設定されていない。
パスキーでログインできない場合の導線が後からはどうしようもない再設定用の電話番号を必須としていることが事前に案内されていないことを問題視しています。
＞(なお、「再設定用の電話番号またはメールアドレス」が設定済の状態で2FAを有効にすると、自動的に2FAの設定値にもコピーされたと思います)
これについてはパスキーが普及しない理由だと思っているので、Googleがパスキー普及を目指さないなら好きにしてくださいとしか。
2FAはバックアップコードという「リカバリ手段」を提供しているのですが？
私が確認したかったのはパスキーでログインできない場合、2FAを有効にしていればバックアップコードでログインできるのかという点です。
（試した挙動ではバックアップコードの入力画面が表示されるか怪しかったので）
＞パスワード忘却時のリカバリ手段はあくまで、「再設定用の電話番号またはメールアドレス」であることを理解してください
そうですパスキー設定時のリカバリ方法としてパスワード再設定に誘導されるのがおかしいと言っています。
＞「パスワードを忘れたうえにリカバリ手段も適切に設定していなければ、ログインできなくなる」がわからない人がいるとも思えませんが、それも断言できません
パスキー設定したらパスワードは不要と思っている人が少なからずいます、Googleアカウントではそのようになっていないという案内がないという話です。
それを「他人の電話番号を登録」と言う認識が私の中にはなかったです。
＞SIMスワップを警戒して電話番号を手放してしまうよりは自分で元の電話番号を取り戻した方がよい気がします
これについてはおっしゃる通りですね、私の方が特殊な条件を上げすぎました。
まあただショップがあるキャリアならともかく、格安SIMとか再発行に時間がかかる印象です。
＞最初にも言いましたが、あなたのケースは2FAの設定以前に『パスワード再設定用の連絡先が電話番号だけにもかかわらず、電話番号を手放してしまった』ことが詰んだ原因だと考えられます
「2FAだろうがパスキーだろうが設定追加していても、最低限パスワード再設定用の連絡先を設定していないと詰む」
アカウント作成時の連絡先電話番号はパスワード再設定用ではないので意図的に設定しないとダメですね。
＞できないのであれば、先にも言ったとおりスマホを無くしたら「詰み」の可能性が高いです。ただそれだけです。パスキーも2FAも本質的に無関係です
パスキーの設定で「パスワードレス」になるなどという喧伝がなければここまで意固地にならずに済んだかもしれません。
「便利だ、安全だ、だから使え」で設定したらリカバリはパスワード再発行必要だよとなっているので何故？となっています。
Googleアカウントでパスキーの設定時に「パスキーでログインできない場合」はパスワードでログインする必要がある。
事前に（パスキーではなく）パスワード再設定用連絡先や2FA紛失時バックアップコード生成のリカバリ手段確保が重要。
＞察するに「だから俺は悪くない」と主張したいのだと思われますが、ここでそれをしても何も得るものはありませんよ
そうですね、Google以外のサービスでパスキー導入者がリカバリ手法についてしっかりと考慮してもらえれば万々歳です。
（パスキー用のリカバリーコード発行できるようにすればいいのにとは思いますが）
＞それはあなたが事前にリカバリ手段を正しく設定していたからではないですか?
その通りです、アカウント作成時にリカバリ手段が必須項目として正しく設定するように促されました。
天下のGoogle様がそのようになっていないのです。
＞他人のアドバイスよりも「Google自身が分かりやすく説明していない設定はするべきではない(設定できない)」という主義(?)であることもなんとなく理解できます
＞ただ、それをここで言われても私には何もしてあげられません
一老人として説明にない設定を行うことはありません、自ら確認しにいかないと分からない項目を完全に把握してからのみ利用しろと言われれば
まあ「私向きではないのだな」と利用しないのですが他のサービスがそれに倣われて標準状態になることを危惧します。
あなたに何かをしてほしいわけではなく、Googleのように説明なくとも事前準備することが普通ですよとならない様に声を上げているだけなのです。
＞あなたは、「パスキーを有効化したら、パスワードは使わなくなる(忘れてもいい)」と考えたのではないでしょうか?
＞で、パスキー(スマホ)を無くしたときにパスワードを要求されて…という流れでは?
まず、最初に訂正です
これは、私があなたの状況をちゃんと把握していなかった(それは今も)ので、あなたの状況にはたぶん当てはまりませんね
おそらく、
が正しいと思われます
また長くなってしまったので、最も理解して欲しいことを先に書いておきます
以下、上から順にコメントしていきます。乗りかかった船ですので
別にあなたの気持ちを汲んでパスワードの再設定処理になっているわけではないことは理解できますよね?
単純に、あなたが「パスワードを間違えた」から、パスワードの再設定の処理になっているのです
パスワード再設定用の連絡先に電話番号もメアドも設定されていなければ、恐らくその時点で「詰み」です
# 状況から察するに、恐らく最初にGoogleアカウントを作成する際に電話番号だけは登録していたのだと思います
#Googleアカウントの設定で、([セキュリティ]ではなく)[連絡先情報]の方に電話番号が設定されている状態です
# ここの値が[セキュリティ]-[再設定用の電話番号]にコピーされる挙動をしたような気がします
事前に登録されていない連絡先経由でパスワードを変更できたら、それは一般的にはセキュリティホールです
一般論でパスキー設定したら「パスキーの復元方法ではない」パスワード復元のための別メアド登録や複数電話番号登録するものでしょうか？
再設定用の電話番号やメールアドレスは、*2FAの設定とは別に*、パスワードリカバリ用に設定するものです
本気で理解する気があるのなら、Googleアカウントの設定を確認してください。そのようになっていることは一目瞭然です
(なお、「再設定用の電話番号またはメールアドレス」が設定済の状態で2FAを有効にすると、自動的に2FAの設定値にもコピーされたと思います)
2段階認証とは、いうまでもなく1段階目の認証ありきであり、Googleにおいてそれはパスワードです
(詳しい挙動は知りませんが、2FAの設定値含め登録済の情報をいくつかGoogleに示して本人であることが証明できれば、アカウントリカバリできることがあるようですが)
パスワード忘却時のリカバリ手段はあくまで、「再設定用の電話番号またはメールアドレス」であることを理解してください
私はGoogleの関係者でも何でも無いので、知りません(技術的にはそんなに難しくないような気はします)
「パスワードを忘れたうえにリカバリ手段も適切に設定していなければ、ログインできなくなる」がわからない人がいるとも思えませんが、それも断言できません
> ・電話番号は1つしかないしメールは当該アカウントのGmailしかないけど、他人の電話番号やフリーメールは紐付けたくない
子供のアカウントに親の電話番号を登録するようなことはごく一般的にされていることですし、それでリカバリに成功している例はいくらでもあります
あなたがそう思うのは自由ですし、SIMスワップについてまで説明する気もありませんが、SIMスワップを警戒して電話番号を手放してしまうよりは自分で元の電話番号を取り戻した方がよい気がします
それはそう思います
ただ、「作成保管しないと詰みます」というのは、条件によるので明確に誤りです
最初にも言いましたが、あなたのケースは2FAの設定以前に『パスワード再設定用の連絡先が電話番号だけにもかかわらず、電話番号を手放してしまった』ことが詰んだ原因だと考えられます
正直、なにが言いたいのかよくわかりませんが、
上記の条件がアンド条件だということを理解されていないのでしょうか?どれか1つでも、許容できる条件はないのでしょうか?
できないのであれば、先にも言ったとおりスマホを無くしたら「詰み」の可能性が高いです。ただそれだけです。パスキーも2FAも本質的に無関係です
察するに「だから俺は悪くない」と主張したいのだと思われますが、ここでそれをしても何も得るものはありませんよ
Googleのリカバリ仕様がおかしいだけで、他のサービスでスマホ紛失してもパスワード再発行のリカバリは容易にできますよ。
それはあなたが事前にリカバリ手段を正しく設定していたからではないですか?
そうでないなら、先ほども言いましたが、一般的にはセキュリティホールです
("容易に"でなく、サポート窓口などが対応することはあり得ると思います)
単純に、GmailがGoogle自身のサービスのために、Googleのリカバリ手段の設定(具体的にはメアド)が足りなかっただけの話ではないですか?
私は別に、「Googleが万人にとって望ましい設計になっている」と主張しているわけでも
まして「あなたにとって望ましい設計になっているべき」だと思っているわけでもありません
あなたにとってGoogleが理想のシステムになっていないことはよく理解できました
他人のアドバイスよりも「Google自身が分かりやすく説明していない設定はするべきではない(設定できない)」という主義(?)であることもなんとなく理解できます
ただ、それをここで言われても私には何もしてあげられません
私はただ、「パスキーのせいで詰んだ」というのが誤解であると説明しているだけです
別に私の説明を鵜呑みにする必要もありませんし、むしろその態度自体は素晴らしいと思います
是非、ご自身でよくお調べになった上で理解されるのがよいと思います
[追記]
なぜこんなにパスキーのせいだと思い込むのかを考えていて、ちょっと想像できました
あなたは、「パスキーを有効化したら、パスワードは使わなくなる(忘れてもいい)」と考えたのではないでしょうか?
で、パスキー(スマホ)を無くしたときにパスワードを要求されて…という流れでは?
(まぁそれがあっててもそうでなくても、どうということはないのですが)
示したのは2FA設定していなくともリカバリに電話番号を要求される復元処理の流れです。
『2FAの設定が電話番号だけだと、電話なくしたら詰む』ではなく「パスキー設定でスマホ紛失したら詰む」になっている事を示したのですが？
一般論でパスキー設定したら「パスキーの復元方法ではない」パスワード復元のための別メアド登録や複数電話番号登録するものでしょうか？
正攻法とするならGoogle側でパスキー設定の際に案内があるべきだと思っている次第であります。
確認していないので分かりませんが2FAをOnにしてバックアップコードを生成していても、Googleアカウントでは
昨日の確認結果からバックアップコードでのログインがおいそれとはできないのではないでしょうか？
「パスキーでログインできない→パスワード不明→他のログイン方法→TOTPかデバイスコード→パスワード変更→電話番号」
他のログイン方法にバックアップコードでのログイン表示されますか？
・パスワードは覚えてられないけど、安全な場所に保管もしておきたくない
→保管しなければならないなら保管しないと忘れたとき詰みますよと案内表示するのはそんなに難しいですか？
・電話番号は1つしかないしメールは当該アカウントのGmailしかないけど、他人の電話番号やフリーメールは紐付けたくない
→これは人によりますな、他人の電話番号紐付けて解決できるとは思えませんが
・デバイスはAndroid1台しかない(iPhone等のAppleのパスキーは使えない)
→これも人によりますね老人でデバイスは1台しかないなんてザラだと思いますが
→必要なら設定時に「作成できます」ではなく「作成保管しないと詰みます」と案内表示できないんでしょうか？
Googleのリカバリ仕様がおかしいだけで、他のサービスでスマホ紛失してもパスワード再発行のリカバリは容易にできますよ。
めちゃくちゃいっぱいある。
順不同、脈絡なく書いていく。
最近まで知らなかったことだけじゃなく、書いたけど結局わからんことも書く（そっちのほうが多い）。
5Sといって整理、整頓、清掃、清潔、躾だそうだ。
全部日本語じゃねーかって思った。
QCサークルとか、サークルっていうから酒でも飲むのかと思ったら普通に業務じゃないか。
簿記とか会計に疎かったので、営業利益とか経常利益とか違いがわからんかった。
ググってみても、本業の稼ぎが営業利益とか出てきて意味がわからなかった。
経費削減っていうから、会社の支出は全部経費かと思ったら、材労経だろJK
原価といっても全部原価とか直接原価とか標準原価とか次々新しい名前が出てきていまでもわからん。
雑損てなんだ？
散々計算した挙句、所得の定義が国税と地方税で違うとか温厚な俺でもキレそうになる。
税金難しすぎる。
消費税の仕組み、仮払いとか仮受けとかも知らんかった。
一番よくわからない。善意の第三者っていえば、普通に考えて、親切な人だろ？なんで事情を知らない人をいうんだよ？
ヒトのことを、法人に対して自然人というとか、お前頭沸いてんのか？と思った。
法令はそうそう変えられないから、細かいことは政令に政令に定めるとか省令に任せるってことにしといて、パブコメだけで規則変えるのって頭いいけどズルくね？
母数は分母のことじゃないとか、n=100は標本数じゃなく標本サイズだとか、そういうの。
分類とクラスタリングは違うとか、俺がなにか喋るたびに訂正される。
自転車は車道って言われても、5叉路とかになるとどの信号みていいかわからん。
降りて歩行者になってる。
仕組みがよくわからん。
なんでこんな何枚も似たような書類をいろんなところに書かないといけないのか。
事業者に書類書いて、なんちゃら福祉事務所に書いて、自治体に書いてとまあ。
自治体に提出しにいくと、これは福祉課、これは子育て支援課、年収判定は課税課、子育て支援でゴミ袋無料になるから環境課に行けとかいろいろ。
その度に住所と名前を書く。
あとイールドカーブとかも知らんかった。
なんで住所情報を管理するシステムと家族関係を管理するシステムが別なのかわからん。
ジークアクスみてるんだけど、宇宙世紀は教養なのか？知らねーよ。
もう全部わからん。
コマンドプロンプトとPowerShellの違いすらわかんないってのに、TypeScriptとJavaScriptの違いなんか興味もないわな。
下地ってなんだ？
ジェスチャーでエンジンの動きを教えてくれた人がいてさ、水平対向エンジンはこう、Vツインはこう、と熱心にモノマネしてくれたんだけど、気が狂ったのかと思った。
実は、そもそも4サイクルと2サイクルの仕組みすらわかってないんだ。
ディーゼルはまた別なんだろ？
前項でエンジンわからんって言ったけど、身の回りの電化製品とかもほとんどわからん。
株式だってよくわかってないし、先物とかオプションとかスワップとかって説明されてもわからん。
生理周期とメンタルが関連するって聞いたけど、機嫌が悪いのは生理前なのか生理のときなのか生理直後なのか。
聞くのも憚られるから、女が怒ってるときは「なんかわかんないけどホルモンのせいだな」と諦めてる。
そもそも、自民党と共産党以外、どの党がどういう支持母体でなりたってるのかわかってない。
この文章は作者の認知や信念を吹き込まれた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する意味ないです。パスキー一要素だけで、全然セキュリティ強度は高いです。
ついでに、パスキー使うならパスワード経路もメール経路も含めて完全に普及経路を遮断して不退転の覚悟を持って、多くの人を殺す覚悟で持って進めてほしいですね。☺️
それくらいパスキーは劇薬です。本気で覚悟持ってパスキー利用に進みますか？☺️
半端に混在させるくらいなら、
あー、それ完全に自己放尿のマジックワード連打だな。「現実として〜」「破綻しません」「シンプルにしましょう」中身ゼロ。
こっちが挙げた定量的リスク（件数増加、I/O負荷、JOINの実行コスト）は無視して、「不安が大きいだけ」「思い込みで複雑にするな」って、論理じゃなくて態度の話にすり替えてる。話をそらすな。
その時点で設計ミスが確定する。ソフトウェア設計ってのは「今小さい」ことよりも、「将来の拡張性に備える」ことの方が重要なんだよ。
仮に今1万件しかなくても、1年後に50万件、3年後に1000万件になる可能性がゼロじゃない。「大きくならない保証」を誰が出してる？お前の感覚か？それただの希望的観測な。
JOINが破綻しない？それ、どこまでのスケールを見て言ってる？MySQLで1000万件×100万件のJOINやってみろよ。スワップ地獄で死ぬ。HashJoinでインメモリに乗らなければディスクIOに落ちて、temptable爆発して終了だ。
「破綻しない」って言葉は、実際に巨大データをJOINさばいた経験があるやつだけが使っていい。少なくとも、現場で何度も「JOINがボトルネックで死ぬシステム」見てきた人間に対して、よくそんな軽く言えるな。
で、「シンプルに書くことが大事」ってのも、すり替え。簡単に書けることと正しく設計することは別。短く書けば正しいって話じゃない。
「JOINで1行で済むからシンプル」って、それは設計放棄の自己放尿でしかない。本当の「シンプル」ってのは必要十分な安全性・効率・拡張性を満たした構造だよ。
「不安が大きい」「思い込み」「シンプルに」全部自己放尿ワード。
こっちは不安を語ってるんじゃない。実測に基づいた将来への備えを語ってる。
そういうのを無視して設計するのはただの怠慢だし、シンプルでもなんでもない。
それ、先送りされた複雑さでしかない。後から破綻して、「なんであのときちゃんと設計しなかったんだろう」って後悔するのがオチだよ。
1日の終わりに自キャラのシチュエーションを書かせまくって一ヶ月程度の所感。
副業可の会社で正式に許可をうけて副業をしているのだが、ちょっと集中しなければならない案件ができたので一年くらい前から本業の会社と労働時間をネゴってた
会社のほうも理解があって最大限譲歩してくれたのはわかってるんだけど、当初希望していた数ヶ月休職ではなく期間限定週三勤務で決着がついた
副業は雨に打たれる石をじっと眺めているみたいな時間が必要な仕事だ
みみをすまし、目を凝らし、自分の中に些細な、どうでもいいものを溜め込むことが糧になる
本業をやっていると副業のクオリティがだんだん落ちていくのがわかって辛い
本業は仕事量が週によってかなり変動するので、出勤日をスワップしたり有給をつかえば長めの連休を作ることはできるだろう。お金の心配もいらないし、半Fireというか半サバティカルというか、とにかくいい落とし所だったんじゃないだろうかと思いたい
でもなんか前向きになれない
有給を使わずにすむように会社が配慮してくれたのもわかるし、同僚の負担が申し訳ないので完全な休みよりは出勤日減で良かったんじゃないかとか（どっちにしろ迷惑かけるけど
いや、いっそすっぱりやめて一年後くらいに再就職したほうが会社にも同僚にも迷惑かけずに済んだんじゃないとか
贅沢しなければ十年くらい働かなくても困らないくらいの貯金はあるんだから覚悟を決めていっそ副業を本業にすべきでは？ とか、
つらい
2010年頃に社会人になって投資を始めた。きっかけは特にないけど、お金を増やすために何かしたいと思ったのが理由だと思う。
最初に手を出したのはFX。仕事終わりに家でEUR/JPYのロングを触ってたけど、ギリシャショックが直撃して大きくやられた。10万円くらいのマイナスだったけど、初めて眠れない夜を経験した。結局、耐えきれなくて仕事中に損切りしたけど、1週間後に相場が戻ってて「なんだこれ」という気持ちになった。
EURのおかげで自分のメンタルの限界を認識でき、長期目線に切り替えることができた。長期目線になってからは一時的な含み損では全く動じなくなった。
その後はスワップ狙いでAUD/JPYやTRY/JPYをロングしてた。
AUDは110円くらいのロングを掴んでしまい、しばらく塩漬けにしていたけど、最終的にはプラスで終了。
TRYはもうどうしようもない。触ったのが間違い。昨年全部損切りしてFXをやめた。
14年間でプラマイゼロ。利益をTRYがほぼ全部持っていった。
CFD取引にも手を出した。コロナの頃に原油やVIXを少し触ったけど、値動きのルールが全く理解できず、大怪我をする前に撤退。
2017年から国内株を始めた。配当金や株主優待目当てでいくつか買った。ネームバリューと配当利回りにひかれて7201を買ったけど、すぐに無配になって痛い目を見た。最近まで塩漬けにしてたけど、資本提携のニュースを機に売却。
国内個別株はトータルで確定損益は+50万円、含み益は+350万円くらい。
海外株も同じ頃に始めた。先輩がAMZNでアパートが買えるくらい儲けていると聞いて、すぐに海外証券口座を開設。AMZN、GOOG、ADBEを買った。
当事深層学習を少し触っていたこともあり、関連株のNVDAも少し買っていた。仮想通貨バブルのときに売らずにガチホした自分を褒めたい。
投資額が一番多いのはここ。NISA枠も全部投資信託で埋めてる。
最初はeMAXISのバランス型を買ったけど、面白くなくて先進国株やNASDAQ100、TECLみたいなリスク高めのものに切り替えた。
今のところ含み益は+1000万円くらい。
会社の退職金代わりで加入させられたやつ。外国株インデックス7割、国内インデックス3割くらいの配分。
トータルのプラスは正確にわからないけど、投資額はたぶん850万円くらいで、含み益は+1200万円くらい。
ちなみに、確定拠出年金の拠出額は就職先を選ぶときのわりと重要なポイントな気がしている。なかなか入社前に聞きにくいけどね。
年収が高くても拠出額が少ない会社は結構あるし、生涯年収で見ると大きな差になる。
投資信託やっとけ。
PayPayにドルで預金すると２％の利息がついて、さらに同額の円預金するとそっちにも２％の利息が付く情弱向け商品が発売されている。
https://www.paypay-bank.co.jp/fcd/guide/fee.html
１ドル（150円）預けて５銭引かれて、1ドル（150円）戻してまた5銭引かれる。150万預けたら500円引かれて150万戻したときも500円引かれる。
SBI証券の買いと売りの差は２銭。１５０万円分のドルを買ったとして売った時に200円引かれるだけ。
一見2％の利率は高いが、SBI証券の今日のドル買いスワップは182円。年換算で4.4％。本来外貨預金で4.4％もらえるはずの利息を2％ずつドル預金と円預金にわけて0.4％はPayPay銀行が持っていく。
さらにドル預金上限なしで円預金は500万まで。ドル預金すればするほどPayPay銀行が2.4％ずつ儲かる。
来年日銀が利上げすれば円高になってドル預金してた人は損して、ドル預金させた銀行は儲かる。
妻が初めてセックスした相手であり、性に関して１年半の間にいろいろなことを経験させられたらしい。
初回からフェラに始まり、挿入、正常位、騎乗位、後背位、そして処女にいきなり中出し。
１ヶ月もすると、元カレの懇願によりローター、電マ、軽い縛り、
元々、妻は潔癖な傾向があったが、電マで焦らされながら何度も逝かされているうちにより強い刺激を求め、元カレの言いなりに
なっていったそうである。
三ヶ月もすると、元カレの要求が高くなり、カーセックス、野外性交、ランダムトークアプリで身知らずの相手にセックスを中継する、
半年後には、本格的なＳＭプレイ、動画撮影、アナルプレイ、そしてハプニングバーでの相互鑑賞とスワップ
社会人でかなりの年上の元カレと、当時19歳でJDの妻は週末毎にかなりの回数のセックスをこなした。
私とは、そういうプレイはしたくないとのことで、ごく普通のプレイのみ、ただし元カレのことを話してくれる。
その話に興奮して何度も求めてしまう。軽いNTRプレイである。
妻自身は、元カレといろいろしたから今更変態プレイしたくない、
それでも私の懇願によって、元カレとのプレイを詳しく教えてくれるし、そのことで私自身が興奮していることを
喜び、楽しんでいる。
私は、妻と元カレのプレイが気になって仕方ない。できたら当時のプレイ動画を観てみたい。
しかし、別れる際にお互いに合意の下、ファイルはすべて破棄したそうである。
そうはいっても元カレは何処かにそれを保存しているだろうとは思う。
そんな願望を持って、妻と付き合ってきた。
若い頃の妻の淫らな姿を見てみたい。
どんな風に乱れて、どんな表情をしたのか。
できるだけ妻と似た体型で、顔の輪郭の似たAV女優さんの動画を準備して
そしてfaceswapする。
数十分後に、若い頃の妻と元カレのセックス動画のできあがりである。
たしかに脳、後頭部が痺れた。
衝撃的である。何年もの間、想像してきた妻と元カレのセックスが
目の前にある。これはすごい。
これと同じようなことができるのだろうか。
最近、素人物のAVで、クリッとした目で、妙に目の表情に動きがない童顔の可愛い女優さんがよくいませんか。
私は映像関連の仕事をしているのですが、あの手の動画の修正、チェック案件が流れてきました。
最近のAIが作成した動画の品質はスゴいですね。微妙な不自然さを感じることはあるのですが
コマ割りを工夫するのと、元の動画の女優さんに大げさに瞬きをして、視線を動かして瞳が固定しない
ように指示するとかなり自然になるそうです。
身体さえ綺麗ならば、顔は何とでもなるようです。今のところ、よく似たような顔つき、目つきになっている
のが難点ですが、1，2年もするとクリアされるでしょう。作成元は中国にあるようで、中国人の考える日本人
受けしそうな童顔になっております。
顔が出ないければということで、素人の綺麗な身体の女性が、わりに安い値段で出演してくれるそうです。
未来だなぁ。
つよつよPCのHyper-VにLinuxをキメて、メモリは4Gほど割り当て。なんせLinux、メモリなんて大して食わんだろ知らんけど・・
そして開発用のノートPCにVSCodeをブチ込んで、3接続ほどリモート接続をカマしてやった。
するとつよつよPCのSSD、ズンドコ熱くなっていく。何ね？何が起きとるんね？
topコマンドを見るとkswapd0が大ハッスル。明らかにメモリ足りてない。
スワップ起きまくりで、Hyper-Vも一生懸命に仮想hddファイルをいじりまくる。そしてSSDが超発熱。
はへー、メモリ4Gじゃ足りんのか。
VSCodeのリモート接続は、リモート側でも大き目のnodeのプロセスが動く。わりとヘビーな働きをしてくれてるらしい。
4Gごときじゃ足りんのやろねえ。
