Mozilla、拡張機能開発者に二段階認証の有効化を義務付けへ 15
ストーリー by headless
義務 部門より
義務 部門より
Mozillaは9日、2020年初めからaddons.mozilla.org(AMO)で拡張機能開発者に二段階認証(2FA)の有効化を義務付けることを発表した(Mozilla Add-ons Blogの記事、 gHacksの記事)。
2FA義務付けは開発者アカウントの乗っ取りを防ぐのが目的で、AMOのアップロードAPIを使用した送信については2FA義務付けの対象外になる。義務付けの開始前にアドオンチームはFirefox Accountsチームと協力して2FAのセットアップとログインがなるべく円滑にできるよう調整を行う。義務付け開始後は、開発者がアドオンを変更しようとする際に2FAの有効化が要求されるとのこと。なお、義務付けとは別に2FAの有効化は強く推奨されている。
2FAの有効化が完了したら、忘れずにリカバリーコードをダウンロードして印刷し、安全な場所に保存しておくことが推奨されている。2FAデバイスが利用できなくなり、コードを紛失した場合はアカウントに二度とアクセスできなくなる可能性があるとのことだ。
2FA義務付けは開発者アカウントの乗っ取りを防ぐのが目的で、AMOのアップロードAPIを使用した送信については2FA義務付けの対象外になる。義務付けの開始前にアドオンチームはFirefox Accountsチームと協力して2FAのセットアップとログインがなるべく円滑にできるよう調整を行う。義務付け開始後は、開発者がアドオンを変更しようとする際に2FAの有効化が要求されるとのこと。なお、義務付けとは別に2FAの有効化は強く推奨されている。
2FAの有効化が完了したら、忘れずにリカバリーコードをダウンロードして印刷し、安全な場所に保存しておくことが推奨されている。2FAデバイスが利用できなくなり、コードを紛失した場合はアカウントに二度とアクセスできなくなる可能性があるとのことだ。
二段階認証の義務付けと称した個人情報収集 (スコア:1)
まじうざい
希望者だけにしとけ
# 銀行に登録してる電話番号を変更しにWebサイトいったらSMSによる二段階認証求められたAC
# どないせえっていうんだ？
# 仕方なく窓口行ったわ
Re: (スコア:0)
Lモードがぽしゃったのだから仕方ない。
二段階認証なのか二要素認証(2FA)なのか (スコア:0)
二段階認証の略語として2FA (Two-factor Authentication)を使うのはちょっと。
この２つの違いってあまり認識されていないのかな (参考) [togetter.com]
さすがに、Mozilla のページでは二段階認証に対して2FAという略語は使っていませんが。
Re:二段階認証なのか二要素認証(2FA)なのか (スコア:1)
確かにストーリーの書き方に違和感はありますが、そもそもMozillaが2つを区別していませんね。
ソースとなっているMozilla Add-ons Blogの記事では"two-factor authentication"（2要素認証）と書かれていますが、記事内リンク先のサポートページ [mozilla.org]では"two-step authentication"（2段階認証）と書かれています。
Re: (スコア:0)
まあ、そうですね。
ただ、それぞれのページはどちからの用語しか使っていないこと、また今回の方式だと
二要素認証・二段階認証どちらも正しいので、Mozilla側の認識は間違ってはいないと思います。
しかし、二段階認証に対する略語として2FAを使うのは明らかに誤りです。
Re: (スコア:0)
そうなのか。
二要素無くても二段階あれば「二段階認証」と言ってゴリ押せるという認識が無かったわ正直。
いちいちスマホ操作するのが面倒なので (スコア:0)
https://github.com/winauth/winauth/releases [github.com] を使ってます。
二段階認証よりサーバが付与したランダムパスワードのほうがいい (スコア:0)
二段階認証が必要になる最大の原因は、
ログインID メールアドレス
パスワード ユーザーが指定した文字列
となってしまうこと
多くのユーザーが、よくあるパスワードや、他のサイトと共通のパスワードを使ってる
なのでリスト攻撃やら、他から漏れたアカウント情報でログインが簡単に成り立つ
ログインID メールアドレス
パスワード１ ユーザーが指定した文字列
パスワード２ サーバが付与したランダム文字列
みたいに、サーバ指定文字を入れればいい
Re: (スコア:0)
二段階認証と二要素認証は、横方向に認証方式が広がる＝スケールアウトしてるから安全。
パスワードをふやす＝スケールアップなのは縦に複雑になっただけでセキュリティは上がってない。
フィッシングやられたら一発アウト。
やりなおし。
Re:二段階認証よりサーバが付与したランダムパスワードのほうがいい (スコア:3, 参考になる)
サーバが付与したランダムパスワードを使うのは二段階認証の実装のひとつといってよいでしょう。Firefoxアカウントの二段階認証はTOTP対応アプリによるランダムPIN入力のようですから、専用アプリを必要としない点でサーバが付与したランダム文字列は便利ですが、対象が拡張機能開発者ということを考えると特に優位点は思い当たりませんでした。
なお、二段階認証あるいは二要素認証はリスト型攻撃に有効な対策であり、どちらにしろプロキシ型のフィッシング詐欺は防げません。ちょうど昨日も新聞記事になっていましたね。
ネットバンクの不正送金被害が急増 「フィッシング」組み合わせた新しい手口目立つ - 毎日新聞 [mainichi.jp]
Re: (スコア:0)
勝手に補足しておくと、よくあるスマホアプリを使ったMFAは
> パスワード２ サーバが付与したランダム文字列
に時刻を加えてハッシュを取って生成した数列を認証に使っている(RFC6238)。
これの利点は以下の通り。
・入力が簡単になること
・フィッシングに引っかかっても「サーバが付与したランダム文字列」そのものが推測不可能になること
・したがってリプレイ攻撃に対して強いこと
OTPは万能ではない (スコア:0)
> パスワードをふやす＝スケールアップなのは縦に複雑になっただけでセキュリティは上がってない。
リスト型攻撃やブルートフォース攻撃を防げるので、「セキュリティは上がってない」は大嘘。
そもそも、攻撃の大半はリスト型で、フィッシングを遥かに上回るリスクです。
> フィッシングやられたら一発アウト。
それは、OTPも同じ。
スマホアプリのタイムベースのワンタイムパスワード生成（Google 認証システム)は、
シークレットキーと時刻を基にワンタイムパスワードを生成する仕組みであって、
そのもととなるシークレットキーはスマホのアプリ領域に保存されてます。
root化すればシークレット
Re: (スコア:0)
言ってることは正しいが一点だけ間違ってる
フィッシングに引っかかったらアウトなのは二段階認証も同じ
システムとして対策することはもっと賞賛されるべき (スコア:0)
今年8月にRubyの著名なgemが侵害を受けた ( https://github.com/rest-client/rest-client/issues/713 [github.com] )し、
それ以前にも各種ライブラリを侵害されるという事案が起きている。
ブラウザの拡張機能の場合対象のサイトによっては致命的 (e.g. ネットバンクの認証情報とか) な被害を受けうる訳だし、
2FAは正直開発者に面倒だとしても、どこかに穴があれば同じ原因で侵害がくり返されかねないわけで、AMO全体の対策として
実施した点は評価できると思う。
mozilla down (スコア:0)
最近FirefoxもThunderbirdも起動しなくなった
両方ともVer.68.3.0に更新したからか？