アカウント名:
パスワード:
ある程度IT知識がある人向けのスラドでも「二要素認証未対応も一因?」なんて書いちゃうんだね。
ネット銀行の2段階認証を突破 不正送金の巧妙な手口 https://style.nikkei.com/article/DGXMZO56375530U0A300C2000000/ [nikkei.com]
SMSでワンタイムコードを送るタイプであっても、時刻ベースのワンタイムパスワード(TOTP)であっても、フィッシング対策にはなりません。何故ならば、フィッシング詐欺サイトが通信をプロキシして、正規サイトとの間を中継すれば回避できるからです。
「二段階認証しているから大丈夫だ」とドメイン名の確認を怠ると、フィッシング詐欺にかえって騙されやすくなります。フィッシング詐欺対策に必要なのは、とにかくドメイン名の確認です。
なお、楽天は、
https://www.rakuten.co.jp/ [rakuten.co.jp] からロ
情報が古いですね。
二要素認証のうち、SMSやTOTPを用いたものは確かにフィッシングに対し脆弱ですが、FIDO U2FやWebAuthnと呼ばれる認証方法はドメイン名が変わると認証されない仕組みになっているので、フィッシングをほぼ確実に防止することができます。
特にWebAuthnではWebAuthn単体で二要素認証が完結し、パスワードそのものを廃止することも可能です。例えば、USB接続のセキュリティーキー + PINで所有認証 + 知識認証、パソコン内のTPMチップと指紋で所有認証 + 生体認証といった風にWebAuthnのみで二要素がそろう仕組みになっています。
このようにフィッシングをほぼ根絶
フィッシングをほぼ確実に防止することができます。
ちなみにWebAuthnを利用するにあたってハードウェアキーを購入する必要はありません。(個人的にはハードウェアキーが好きですが)
おっしゃることは、ユーザーの使用するデバイスが1台だけで、スマホとPCの併用も無く、機種変更も無いという理想条件ならば正しく、確かにその条件ならばフィッシングは防げます。
しかし、現実はそうじゃないので、ハードウェアキー無しで、フィッシングを防ぐなど不可能です。(ハードウェアキーにWebAuthnのキーを入れて、別端末でログインするときには差し替えるというのであればフィッシングは防げますが)
https://gihyo.jp/dev/column/newyear/2019/webauthn?page=2 [gihyo.jp]> ここで注目してほしいのは,WebAuthnはあくまで認証プロトコルであり,RPとClient,そしてAuthenticatorになるデバイスという経路においてはフィッシングを防げますが,それ以外の部分には関与しないという点です。つまり,インターネットを経由した他デバイスからの認証を実装する場合や,認証後の認可フローを検討する場合は,ユースケースに応じた対策が必要になります。
WebAuthnのキーは、端末のTEEやTPMに保存されるので、端末依存です。別の端末からログインする場合には、現実的な実装がされているサイトであれば、結局中継型フィッシングを防げないのです。https://gihyo.jp/assets/images/dev/column/newyear/2019/webauthn/thumb/... [gihyo.jp]
偽サイトを本物と信じてPCからログイン操作をして、スマホのWebAuthnでそのログインを認可してしまえば、悪意のある第三者がログインできてしまうわけです。つまりは、スマホでWebAuthn登録していた人が、PCでショッピングする際には、結局、ユーザーが「ドメイン名」を目視確認するという作業が必要になるわけで、それをしなかったら中継型フィッシングを防げないのは同じことなのです。
そもそも、WebAuthnで確実にフィッシングを防げる端末1台だけ使用という非現実的な前提なのならば、そもそもCookieのログイントークンを無期限にしてパスワードを廃止すればフィッシング詐欺は100%防げます。では、何故そうならずパスワード等があるのかというと、新しいデバイスでログインするために必要だからです。端末にキーを入れたWebAuthnではその代替とはならず、マルチデバイスでのログインからフィッシングを排除することはできません。
マルチデバイスで不便or危険なWebAuthnは、なかなか普及しないでしょう。
ハードウェアキーを使用しない場合、WebAuthnが端末依存になるのはその通りですが、大抵のサイトは複数のデバイスを認証用に登録可能なのでログインに使用する端末すべてを登録すれば済みますね。
デバイスの登録時にはTOTPなどの脆弱な方法を使用する必要がありますが、デバイスを登録する頻度はサイトにログインする頻度よりかなり少ないことが想定されるので、その場合でもフィッシングのリスクを大幅に削減できます。
gihyo.jpのリンク先で提示されているフィッシングのシナリオについても、根本的な問題はサイト側が「現実的な実装」という名のもとにWebAu
gihyo.jpのリンク先で提示されているフィッシングのシナリオについても、根本的な問題はサイト側が「現実的な実装」という名のもとにWebAuthnの仕組みに反した脆弱な実装を行っているのが問題であり、サイト側が故意に穴をあけているのにそれをふさげというのは無茶な話です。
WebAuthnの標準的な実装がどんなものかはわからないのですが、もしその実装が困難で「現実的な実装」しか実際にはできないのであれば、、WebAuthの標準実装は誰も使ってくれずに、結局フィッシングは防げないような気が。
Appleが今年のWWDCで発表したPasskeysってのが、秘密鍵をiCloudキーチェーンに保管するって仕組みじゃないかな。
認証できるのが1台のデバイスだけというのは、確かにより安全なんだけど、そのデバイスに依存すると、そのデバイスが壊れたときや交換するときに面倒なんだよね。全部のサービスで新しいデバイスを使って設定をやり直さなくちゃいけない。安全でも面倒すぎると結局普及しないからね。
2段階認証のワンタイムパスワード生成器が壊れたらリカバリ方法がないという恐ろしいサービスもあるんだよね。(もちろんすぐ2段階認証を無効にした)
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
にわかな奴ほど語りたがる -- あるハッカー
2要素認証はフィッシングに効果無いんですが (スコア:4, 興味深い)
ある程度IT知識がある人向けのスラドでも「二要素認証未対応も一因?」なんて書いちゃうんだね。
ネット銀行の2段階認証を突破 不正送金の巧妙な手口
https://style.nikkei.com/article/DGXMZO56375530U0A300C2000000/ [nikkei.com]
SMSでワンタイムコードを送るタイプであっても、時刻ベースのワンタイムパスワード(TOTP)であっても、フィッシング対策にはなりません。
何故ならば、フィッシング詐欺サイトが通信をプロキシして、正規サイトとの間を中継すれば回避できるからです。
「二段階認証しているから大丈夫だ」とドメイン名の確認を怠ると、フィッシング詐欺にかえって騙されやすくなります。
フィッシング詐欺対策に必要なのは、とにかくドメイン名の確認です。
なお、楽天は、
https://www.rakuten.co.jp/ [rakuten.co.jp] からロ
複数ある認証手段を一括りにするなかれ (スコア:0)
情報が古いですね。
二要素認証のうち、SMSやTOTPを用いたものは確かにフィッシングに対し脆弱ですが、FIDO U2FやWebAuthnと呼ばれる認証方法はドメイン名が変わると認証されない仕組みになっているので、フィッシングをほぼ確実に防止することができます。
特にWebAuthnではWebAuthn単体で二要素認証が完結し、パスワードそのものを廃止することも可能です。
例えば、USB接続のセキュリティーキー + PINで所有認証 + 知識認証、パソコン内のTPMチップと指紋で所有認証 + 生体認証といった風にWebAuthnのみで二要素がそろう仕組みになっています。
このようにフィッシングをほぼ根絶
WebAuthnでフィッシングを防げるというのは「非現実的」 (スコア:0)
フィッシングをほぼ確実に防止することができます。
ちなみにWebAuthnを利用するにあたってハードウェアキーを購入する必要はありません。(個人的にはハードウェアキーが好きですが)
おっしゃることは、ユーザーの使用するデバイスが1台だけで、スマホとPCの併用も無く、機種変更も無いという理想条件ならば正しく、確かにその条件ならばフィッシングは防げます。
しかし、現実はそうじゃないので、ハードウェアキー無しで、フィッシングを防ぐなど不可能です。
(ハードウェアキーにWebAuthnのキーを入れて、別端末でログインするときには差し替えるというのであればフィッシングは防げますが)
https://gihyo.jp/dev/column/newyear/2019/webauthn?page=2 [gihyo.jp]
> ここで注目してほしいのは,WebAuthnはあくまで認証プロトコルであり,RPとClient,そしてAuthenticatorになるデバイスという経路においてはフィッシングを防げますが,それ以外の部分には関与しないという点です。つまり,インターネットを経由した他デバイスからの認証を実装する場合や,認証後の認可フローを検討する場合は,ユースケースに応じた対策が必要になります。
WebAuthnのキーは、端末のTEEやTPMに保存されるので、端末依存です。
別の端末からログインする場合には、現実的な実装がされているサイトであれば、結局中継型フィッシングを防げないのです。
https://gihyo.jp/assets/images/dev/column/newyear/2019/webauthn/thumb/... [gihyo.jp]
偽サイトを本物と信じてPCからログイン操作をして、スマホのWebAuthnでそのログインを認可してしまえば、悪意のある第三者がログインできてしまうわけです。
つまりは、スマホでWebAuthn登録していた人が、PCでショッピングする際には、結局、ユーザーが「ドメイン名」を目視確認するという作業が必要になるわけで、それをしなかったら中継型フィッシングを防げないのは同じことなのです。
そもそも、WebAuthnで確実にフィッシングを防げる端末1台だけ使用という非現実的な前提なのならば、そもそもCookieのログイントークンを無期限にしてパスワードを廃止すればフィッシング詐欺は100%防げます。
では、何故そうならずパスワード等があるのかというと、新しいデバイスでログインするために必要だからです。
端末にキーを入れたWebAuthnではその代替とはならず、マルチデバイスでのログインからフィッシングを排除することはできません。
マルチデバイスで不便or危険なWebAuthnは、なかなか普及しないでしょう。
Re: (スコア:0)
ハードウェアキーを使用しない場合、WebAuthnが端末依存になるのはその通りですが、大抵のサイトは複数のデバイスを認証用に登録可能なのでログインに使用する端末すべてを登録すれば済みますね。
デバイスの登録時にはTOTPなどの脆弱な方法を使用する必要がありますが、デバイスを登録する頻度はサイトにログインする頻度よりかなり少ないことが想定されるので、その場合でもフィッシングのリスクを大幅に削減できます。
gihyo.jpのリンク先で提示されているフィッシングのシナリオについても、根本的な問題はサイト側が「現実的な実装」という名のもとにWebAu
Re: (スコア:0)
gihyo.jpのリンク先で提示されているフィッシングのシナリオについても、根本的な問題はサイト側が「現実的な実装」という名のもとにWebAuthnの仕組みに反した脆弱な実装を行っているのが問題であり、サイト側が故意に穴をあけているのにそれをふさげというのは無茶な話です。
WebAuthnの標準的な実装がどんなものかはわからないのですが、もしその実装が困難で「現実的な実装」しか実際にはできないのであれば、、WebAuthの標準実装は誰も使ってくれずに、結局フィッシングは防げないような気が。
Re: (スコア:0)
Appleが今年のWWDCで発表したPasskeysってのが、秘密鍵をiCloudキーチェーンに保管するって仕組みじゃないかな。
認証できるのが1台のデバイスだけというのは、確かにより安全なんだけど、
そのデバイスに依存すると、そのデバイスが壊れたときや交換するときに面倒なんだよね。
全部のサービスで新しいデバイスを使って設定をやり直さなくちゃいけない。
安全でも面倒すぎると結局普及しないからね。
2段階認証のワンタイムパスワード生成器が壊れたらリカバリ方法がないという恐ろしいサービスもあるんだよね。
(もちろんすぐ2段階認証を無効にした)