Google Developers Japan: Chrome のパスワード保護を強化 - その仕組み

Local blog for Japanese speaking developers

Chrome のパスワード保護を強化 - その仕組み

2020年1月6日月曜日

この記事は Patrick Nepper、Kiran C. Nair、Vasilii Sukhanov、Varun Khaneja による Google Online Security Blog の記事 "Better password protections in Chrome - How it works" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。お知らせします侵害されたパスワードの警告Password Checkup 拡張機能導入しましたこちらGoogle Account に組み込まれpasswords.google.com

Google は、別の企業からユーザー名とパスワードのデータが流出したことを知ると、ハッシュ化と暗号化を行ったデータを、Google しか知らない秘密鍵と合わせてサーバーに保管します。

ウェブサイトにログインすると、Chrome はハッシュ化したユーザー名とパスワードを Chrome しか知らない秘密鍵で暗号化して Google に送ります。この暗号化されたデータからは、Google を含め、誰もユーザー名とパスワードを解読することはできません。

ユーザー名とパスワードが流出データに含まれているかを判断するため、複数のレイヤーの暗号化を利用する private set intersection with blinding と呼ばれる手法を使います。これにより、自分のユーザー名とパスワードを暗号化したものと、すべての流出したユーザー名とパスワードを暗号化したものを比較できます。自分のユーザー名とパスワードや、他のユーザーのユーザ名とパスワードが明かされることはありません。この計算を効率的に行えるように、Chrome はユーザー名の 3 バイトの SHA256 ハッシュプレフィックスを送ることで、データを結合する規模を 40 億レコードから 250 レコードに削減しています。この場合も、ユーザー名の匿名性は維持されています。

ユーザー名とパスワードが侵害されているかどうかは、そのユーザーにしかわかりません。侵害されていた場合、Chrome はその旨を通知します。そのときはパスワードを変更することを強くお勧めします。

Sync and Google ServicesPassword Leak Detection Enabled ポリシー設定リアルタイムフィッシング保護: セーフブラウジングのブロックリストをリアルタイムに確認セーフブラウジングMake searches and browsing betterUrl Keyed Anonymized Data Collection Enabled ポリシー設定予測的フィッシング保護の拡張リリースしましたEiji Kitamura - Developer Relations Team

ラベル

ブログアーカイブ

2020
- 12
- 11
- 10
- 9
- 8
- 7
- 6
- 5
- 4
- 3
- 2
- 1

2019
- 12
- 11
- 10
- 9
- 8
- 7
- 6
- 5
- 4
- 3
- 2
- 1

2018
- 12
- 11
- 10
- 9
- 8
- 7
- 6
- 5
- 4
- 3
- 2
- 1

2017
- 12
- 11
- 10
- 9
- 8
- 7
- 6
- 5
- 4
- 3
- 2
- 1

2016
- 12
- 11
- 10
- 9
- 8
- 7
- 6
- 5
- 4
- 3
- 2
- 1

2015
- 12
- 11
- 10
- 9
- 8
- 7
- 6
- 5
- 4
- 3
- 2

2014
- 12
- 11
- 10
- 9
- 8
- 7
- 6
- 5
- 4
- 3
- 2
- 1

2013
- 12
- 11
- 10
- 9
- 8
- 7
- 6
- 5
- 4
- 3
- 2
- 1

2012
- 12
- 11
- 10
- 9
- 8
- 7
- 6
- 5
- 4
- 3
- 2
- 1

2011
- 12
- 11
- 10
- 9
- 8
- 7
- 6
- 5
- 4
- 3
- 2
- 1

2010
- 12
- 11

Feed

"プロダクトに関するご意見はプロダクトフォーラムにお願いします"

Google
Privacy
Terms