パスワードの進化：現代の認証ガイド

すべては簡単に始まりました。2つの文字セット（ユーザー名とパスワード）があり、両方を知っている人がログインできます。 複雑なことは何もありません。

ただし、機能するエコシステムも単純でした。たとえば、 MITのタイムシェアリングシステムは 、パスワードを使用する最初のコンピューターシステムと考えられています。



しかし、この状況は前世紀の60年代に発展し、それ以来多くの水が流れました。 過去数十年まで、限られた数の接続で非常に少数のアカウントしか持っていなかったため、脅威の範囲はかなり狭くなりました。 あなたに危害を加えることができるのは、近くにいた人だけです。つまり、システムに直接物理的にアクセスできる人です。 時間が経つにつれて、電話を介して接続できるリモートユーザーも加わり、脅威の範囲が拡大しました。 その後、何が起こったのか、ご存じのとおりです。特に近年、関係、アカウント、侵入者、データリークが増加しています。 キャラクターの単純な調整を伴う初期のスキームは、もはやそのような素晴らしいアイデアとは思えません。

数か月前、私は再利用可能なパスワードについて書き、資格情報を投入し、サービスデータベースにさらに10億のエントリが追加されたことを確認しました 。 状況は次のとおりです。数十億のアクセスの詳細があり、悪意のあるユーザーがそれらを使用して好きなサイトをハッキングするのを待ちます。 これは非常に興味深い質問です。そのような状況で自分自身を守る方法は？ つまり、あなたはオンラインシステムを浮かんでいるようにしようとしており、ある種の外部は一部のユーザーのアカウントからの作業データを持っています-どのようにして彼がシステムに入るのを禁止できますか？ 60年代のキャラクターを単純に並べただけでは十分ではありません。

しかし、認証の進化は、資格情報をスローするためのベースの無限の拡張に要約されていません-ログインプロセスは他の多くの点で変更されています。 場合によっては、これにより、すべてが逆さまになり、かつて資本と考えられていたアカウントの作成と管理に関するこれらの真実は今では無関係になります。 それでも、一部の組織が今日の現代の脅威に時代遅れのスキームをどのように適用しているかを見ることができます。 この投稿は、この矛盾を分析し、現代のシステムのこの重要な部分を実際に設計する方法を説明することを目的としています。 いつかそれが、「私たちはセキュリティのためにこの愚かさをする」と言う会社を幸福な人々が送るリソースになることを願っています。

政府（およびスマートIT企業）の意見を聞く

他のソースへのリンクから始めます。最近、このトピックに関する多くの優れた資料がWebに掲載されたので、それらを参照します。 私はそれを一度にまとめて1つのポイントを明確にします：後で与えられる推奨事項のほとんどは、問題に関する個人的な見解だけでなく、国立標準技術研究所などの組織からの直接の引用であり、またはNIST）。 実際、先月発表された彼らの作品「 デジタルアイデンティティガイドライン」は 、おそらくこの記事を取り上げるきっかけとなったと考えられます。興味深いことがたくさんありました。

英国政府の国立サイバーセキュリティセンターも、私が使用するすばらしいリソースです。 彼らは定期的にセキュリティのトピックに関する非常に有益な記事を発行し、IT分野で本当に「考えている」政府機関の珍しい例を紹介しています。

また、ID保護チームによるMicrosoftのパスワードガイダンスの調査も参照します 。 最初のページでは、Microsoftは「アカウントハイジャックにおけるパスワードの役割を理解するユニークな立場にある」と述べています。なぜなら、毎日1,000万件の攻撃に耐えるからです。 これは、オンラインアカウントをセキュリティで保護する方法を明確に検討した人々によってまとめられた非常に実用的なガイドです。

他にも興味深い資料がありますので、コメントで発見を共有していただければ幸いです。 ここでは、いくつかのソースのみをリストしました。さらに下のテキストでは、他の多くのソースへの参照を見つけることができます。 さあ、始めましょう！

認証プロセスは、2つの状態間の切り替えに限定されるべきではありません

最初に、より哲学的な観点から認証プロセスを見てみましょう。システムにログインするまで、そのコンポーネントのいずれにもアクセスできません。次に、自分の権利で書かれたすべてにアクセスしてアクセスします。 グレーゾーンはありません-この方法でもそれでも。

情報セキュリティセクターで最近観察されている注目すべき傾向の1つは、脅威レベルと信頼レベルの区別です。つまり、潜在的なリスク（ログインなど）に関連するいくつかのシナリオで、ユーザーへの信頼、そしていくつか-少ない。 例：一定のログイン試行回数を許可する代わりに、5回（何らかの理由でその回数が常に奇数であることに気づきましたか？） したがって、ユーザーの信頼レベルが低下していることを示し、システムが自動化された攻撃を受けないようにするための追加措置を講じざるを得ません。 これはボットにとって深刻な障害であり、ユーザーにとってはやや不便です。さらに、必要に応じて、さらにいくつかの失敗した試行後にアカウントをブロックすることができます。

思考を続けると、ログインに成功したらすぐにユーザーにすべての機能へのアクセスを許可する価値がありますか？ 初めてパスワードを正しく入力せず、以前に使用したことのないブラウザや他の国から来たと仮定します。この場合、すべてに無制限にアクセスする必要がありますか？ または、最も基本的な機能に限定して、指定されたアドレスがユーザーに属していることを証明する必要があります。

これらの簡単な例の助けを借りて、ほとんどのサービスでまだ普及している従来のバイナリシステムよりも賢く行動できると読者に思わせようとします。 このトピックは、テキストで引き続き開発されます。

長くなればなるほど（通常）

それでは、技術的なコンポーネントを掘り下げて、簡単なものから始めましょう。以下に示すものは、パスワードを作成するための最良のポリシーではありません。



ポップアップウィンドウの最初の文（「パスワードは8〜10文字にする必要があります」）は、おそらく、パスワードを作成するための誤ったアンチパターンの中で最も一般的なものです。 これはパスワードマネージャーを殺し（後で詳しく説明します）、パスフレーズを殺し、その結果、ユーザビリティを殺します。 使いやすさについて言えば、昨年の記事で最も基本的なことをどのように間違えたかについてのスクリーンショットを撮りました。同様のポリシーのおかげで、実際に私のアカウントへのアクセスがブロックされました。

上記の問題に加えて、長さの制限が低いと、多くの場合、パスワードストレージの編成が不十分であると疑われるようになります。 暗号化ハッシュの後、保存されたすべてのパスワードは同じ固定長になります。そのため、このような任意の制限は、パスワードがプレーンテキストで保存され、列が10文字しか収容できないことを意味します。 もちろん、理由は異なるかもしれませんが、あなたは理解しているように、そのような仮定は根拠がありません。

設定する長さの制限は何ですか？ ある境界を超えると他の問題が発生するため、「何もない」というのは間違った答えです。 たとえば、サイズが4メガバイトを超える場合、 ASP.NETの既定の要求サイズを満たしません 。 これについてNISTが述べていることは次のとおりです。

検証者は、加入者の選択で最大64文字の秘密コードの入力を許可する必要があります。

パスワードの長さを64文字に制限したサイトに登録している普通の人ではありませんが、「セキュリティに関してどんな種類のくだらないことなのか、パスワードを64文字より長くすることさえできませんでした」と言うでしょう。 ただし、念のために、100文字の制限を設定できます。 または、NISTの概念を取り入れて、最大256文字を設定します。違いは何ですか、ハッシュの後もすべて同じで、すべてが揃えられます。

NISTは別の重要なポイントを指しますが、そうではありませんが、表面上のポイントです。

秘密コードの切り捨ては許可されていません。

実際、これらは最も基本的なものです。短い長さを指定せず、ユーザーが提案したパスワードの終了文字を切り捨てないでください。 最悪の場合、そのような慣行の正当性を主張する企業は、「これは不可能であり、遺伝に問題があることを知っています。緊急修正のためにリストに載せます」と付け加える必要があります。

すべての文字は特別です（ただしオプション）

特殊文字の使用に関する2つの側面を検討します。 私はこれから始めます：



通常、パスワードの一部の文字は許可されていません。 このルールは、起こりうる攻撃から保護するために導入されました。 たとえば、XSS攻撃では山括弧を使用でき、SQLコードを注入するときにはアポストロフィを使用できます。 しかし、そのような議論は、サイトのセキュリティプロファイルに重大な欠陥があることを示しています。 まず、クロスサイトスクリプティングの脅威により、インターフェースにパスワードを表示しないでください。 第二に、パスワードをハッシュせずにデータベースに送信しないでください。その後、英数字のみが残ります。 そしてもちろん、インターフェースにパスワードを表示し、それらをプレーンテキストとしてデータベースに保存することでこれらのルールを破ったとしても、出力およびパラメーター化中にエンコードが残っています。

NISTはこれを非常に明確に表現しています-これをしないでください：

秘密コードは、スペースを含めて、印刷されたASCII文字[RFC 20]の使用を許可する必要があります。 Unicode文字[ISO / ISC 10646]も受け入れられなければなりません 。

Unicode文字に関する予約に注意する価値があります。開発者が言語の観点から非常に受け入れられる文字に禁止を課した先例がありました。単に「通常の」文字を超えたからです。 一方、もちろん、次のようなパスワードもあります。



ええ、もし誰かが本当に顔文字で書き留められたFrozenからの手紙と忘れ物の最初のカップルを置きたいなら、どうぞ！

私が触れたかったもう1つの側面は、NISTでも言及されています。

検証者は、シークレットコードを作成するための追加の規則を導入しないでください（たとえば、異なるタイプの文字の使用を要求したり、連続する同一の文字の導入を禁止したりする） 。

待って、どう？ つまり、パスワードに大文字、小文字、数字、記号を含める必要はありませんか？！ これは、一般に受け入れられているアプローチとはまったく反対であり、座って、すべてが論理的に考えられ、正しいことを理解する必要があります。 実例として、私は最近、システムでパスワードを「良い」または「悪い」と評価すると、人々が間違った決定を下すようになることについて書いた。 基本的なメッセージはこれでした：純粋に数学的なアプローチは、私たちが良いパスワードを思い付くのを助けません。 このような要件により、「Password！」などのパスワードが許可され、パスフレーズに大文字が含まれていないという理由だけでパスフレーズが切断されます。

上記のドキュメントで、MicrosoftはNISTからの推奨事項をエコーし​​ます。

パスワード要件を拒否します。

パスワードの複雑さの要件がある場合、状況は通常次のように展開します。人々は最初にプリミティブを入力しようとし、次に必要なコンポーネントが最小限になるまで文字を修正します。 マイクロソフトはこの問題を次のように明らかにしています。

ほとんどの場合、人々は同じパターンを使用します（最初の文字は大文字、特殊文字、または末尾の2つの数字です）。 サイバー詐欺師はこれを知っているため、辞書を検索すると、標準スキームに従って行われたすべての置換が含まれます（「s」の代わりに「$」、「a」の代わりに「@」、「l」の代わりに「1」など） 。

その結果、パスワードは依然として不良である可能性が高く、ほとんどの場合、ユーザーは以前にそのパスワードを使用したことがあります。 これらの手段によって達成できるのは、結果なしでユーザーの神経を軽くたたくことです。

ヒント まさか！

私の個人的な観察によると、今のヒントは以前ほど人気が​​あったとはほど遠い。 このアイデアは「聞いて、人々は常にパスワードを忘れて、忘れないようにしましょう！」から始まりました。そして、アカウントを作成するときに、ユーザーはパスワードだけでなくヒントも入力する機会を得ました。 問題は、このヒントが権限のないユーザーに表示されることです。この段階でのみ必要です。 別の問題は、この情報がユーザーによって入力されることであり、したがって、ほとんどの場合、完全な恐怖があります。

アドビはデータベースにパスワードのヒントを保管しました。これは2013年に公開されました。 すべてがどれほど悪いかを実証するために、このデータベースを見て、個々のサンプルを共有することにしました。

• 私の名前
• アドビ
• いつものように
• パスワード
• 電子メール

それらはすべてプレーンテキストで保存されているため、システムがハッキングされたときに何が起こったのか想像できます。 NISTがこれを悪い考えだと考える理由は明らかです。

秘密のコード検証者は、サブスクライバーがログインしようとしたときに、許可されていない人が利用できる「ヒント」を残すことを許可しないでください。

先ほど言ったように、今ではオンラインシステムにヒントはほとんど表示されませんが、このようなことを考えた場合に備えて、考えないでください。

パスワードマネージャーが大好き

私は長い間、パスワードマネージャー自身の価値について言ってきました。2011年の初めから、 信頼できるパスワードは覚えていないものだけだと記事に書いたときからです 。 アイデアはシンプルで、いくつかの点で文字通り説明できます。

1. パスワードは「強力」でなければならないこと、つまり、徹底的な検索で推測または計算することが困難でなければならないことを知っています。 言い換えれば、より多くのキャラクターとよりランダムに選択されるほど、より良いです。
2. 1つのパスワードを複数回使用することは不可能であることがわかっています。1つのサービスがハッキングされると、他のリソースのユーザーアカウントが危険にさらされます。 前述した登録データのスタッフィングの問題は、まさにこれです。
3. 人々は、自分の記憶だけに頼って、各サービスの強力でユニークなパスワードを発明して記憶することはできません。

パスワードマネージャーを使用すると、すべてを1か所で収集することを意味することに異議を唱える人がいるでしょう。彼が正しいのです。誰かがこの場所に侵入すると、大きなトラブルが発生します。 しかし、これは個々のサービスのハッキングとその後のアカウントデータの漏洩の場合と比較して、非常にまれな現象です。 さらに、私が最近言ったように、 パスワードマネージャーは完璧である必要はありません 。

しかし、この投稿は、ユーザーが適切なパスワードを作成するためのガイドとして書かれたものではなく、サービスを作成する人を対象としています。 したがって、あなたが個人的にパスワードマネージャーと関係があるとしても、これはやる価値がありません。



こんにちは パスワードマネージャーの使用はお勧めしません。デバイスがハッキングされる可能性があります。

このような近視は一般的であり、これらのツイートをすぐに見つけることができます。 彼らは通常、上記で触れた3つのポイントを考慮せず、実際に次のようなことを言います。「ねえ、覚えやすいパスワードを作成してください。もちろん、それらは脆弱で、アカウントからアカウントに繰り返します。しかし、それは安全のために必要です。」

NCSCはこの問題について明確に述べています。 パスワードガイダンス：アプローチを簡素化するためのインフォグラフィックには、次のスニペットがあります。



ユーザーがパスワードを安全に保存する機能を作成する

言い換えれば、パスワードマネージャーを壊さないでください。また、指定されたツイートのようなステートメントを作成しないでください。 しかし、NCSCはさらに前進し、組織が従業員にパスワードを作成し、セキュリティを危険にさらすことなくそれらを管理する能力を与えることを明確に期待して、次の推奨事項を提供します。

また、保護しようとする情報の機密性と一致する保護レベルの適切なパスワードストレージ機器を提供する必要があります。 これらのストレージは、マテリアル（金庫など）またはテクニカル（パスワード管理用の特別なプログラムなど）のいずれか、または両方の側面を組み合わせることができます。 組織がユーザーがパスワードを制御できるように承認されたメカニズムを提供することが不可欠です。これにより、大量のパスワードを処理するために信頼できない「隠された」方法に頼る必要がなくなります。

現在作業している環境について考えてください。 パスワードの強度の基準はありますか？ 毎年のトレーニングがありますか、それともユニークで複雑なパスワードの作成を促すポスターが壁に貼られていますか？ もちろん、パスワードに関連する何らかの制御とコーチングは間違いなく存在しますが、目標を達成するのに役立つ「承認されたメカニズム」を提供していますか？ ほとんどの場合そうではありません。さまざまな組織でトレーニングを実施するときによくこの質問をするので、このような自信を持って言います。 このようなミスマッチを見なければならない頻度は驚くべきことです。

パスワードを挿入させます

パスワードマネージャーの使用は、パスワードを入力フィールドに挿入する機能と密接に関連しています。 フィールドに自動的に入力するパスワードマネージャーは多数ありますが、挿入を使用する必要がある場合や、サービスブロックが手動ではなくパスワードを入力しようとする場合があります（これはJavaScriptを使用して簡単に確認できます）。 結果は次のとおりです。



2014年に、パスワードフィールドに貼り付けが許可されていない場合に発生する「コブラ効果」について書きました。 この用語の意味については、参考文献で詳しく説明していますが、簡単に要約すると、問題を解決しようとしても問題が悪化するだけで、コブラ効果が現れます。 サイトがセキュリティを確保するためにパスワードを挿入する機能をブロックすると、一部のユーザーは入力が簡単になるほど原始的になるまでパスワードを単純化する必要があります。

NCSCはここでも私をサポートしています：



彼らはこのアンチパターンに特別な用語-SPP（パスワードの貼り付けの停止、「パスワードの挿入の停止」）を導入し、パスワードの貼り付けに関連するリスクについての一般的な神話を覆しました。 彼らは、コブラの効果について述べた私の記事にも言及しています-イギリス政府からそのような保護を受けるのは素晴らしいことです！

NISTは、次の声明から明らかなように、NCSCの役職に加わりました。

検証者は、シークレットコードを入力するときに、承認を受けている人が挿入機能を使用できるようにする必要があります。 これにより、パスワードマネージャーの使用が容易になります。パスワードマネージャーは広く普及しており、多くの場合、ユーザーがより複雑なシークレットコードを作成することを奨励しています。

大西洋の両側の人々は、パスワードマネージャーの使用を満場一致でサポートし、それらをブロックするための積極的なアクションに反対しています。

定期的にパスワードを変更する必要はありません

民間企業での以前の仕事で、現在のパスワードをどれだけ使用しているかを簡単に計算する方法を思いつきました。パスワードに含まれる数字を取得し、会社がパスワードを置き換える必要がある四半期に1回増加し、それを4で割っただけです。 したがって、私は単一のパスワードをほぼ6年間延長し、そのたびにその中の数文字しか変更しませんでした。 職場で定期的にパスワードを変更することも慣習である場合、おそらく同じことを行うでしょう。不便な技術的要件に遭遇したとき、それは簡単で自然な方法です。

このアプローチの理論的根拠を分析しましょう：定期的にパスワードを更新することを支持する議論は、パスワードが間違った手に落ちた場合、強制置換後に無関係になるため、詐欺師はそれを使用できないことを意味します。 ここでの問題は、私の例では、ハッカーが最大3か月の時間を費やしたことです。



あなたがそう思うなら、ハッカーは通常、黙って待つことなく、すぐにアカウントを操作し、それらから利益を得ようとします。 Lifeboatチームは 、昨年のデータ漏洩の結果を滑らかにする試みでこれを考慮しなかったため 、推論のチェーンが間違っていることが判明しました。

1月に起こったことの後、ハッカーが計画を実行する時間がほとんどないことをハッカーが知らないように、すべてのパスワードを静かに置き換えることが最善の措置であると判断しました。

上記のツイートで述べたように、NCSCは今日、パスワードの強制置換は情報セキュリティのアンチパターンであるという見解を共有しています。 パスワード管理ガイドでは、このプラクティスについて次のように述べています 。

ハッキングされたパスワードは通常すぐに使用されるため、[彼女]は実際のメリットをもたらしません。

彼らはこのアイデアをインフォグラフィックに持ち込みます：



古いパスワードが侵害された兆候や疑いがある場合にのみ、ユーザーにパスワードを変更するように依頼してください。

マイクロソフトは同じことを言っています：

パスワードの有効期限ポリシーは、ユーザーが互いに密接に関連する連続した数字と単語から高度に予測可能なパスワードを作成することを奨励するため、害よりも害があります（その結果、後続の各パスワードは前のものから簡単に推測されます）。 ほとんどの場合、サイバー詐欺師はアクセスするとすぐにその詳細を使用するため、リスクを減らすことに関しては、パスワードの変更も大きな役割を果たしません。

もちろん、彼らの言葉は「ユーザーにパスワードを強制的に変更させないでください。あなたにそれ以上のことは必要ありません」と理解すべきではありません。 むしろ、これは、パスワード管理に対してより広く、より高度なアプローチが必要であることを示しています。 たとえば、NCSCは次のような推奨事項も提供します。

1. すべての承認事例を追跡して、異常な動作を検出します。
2. ログインが成功したか失敗したかにかかわらず、ログイン試行の詳細をユーザーに伝えます。 順番に、これらの試みのいずれかがそれらからのものではない場合、ユーザーはあなたに通知する必要があります。

そして、次のセクションにスムーズに進みます。

異常な動作をユーザーに報告する

これは、認証プロセスへの「高度な」アプローチの重要な側面であり、すでに実際に動作しているのを見たことがある可能性があります。 最近、新しいLenovo Yoga 910でYammerアカウントにログインしました。それまでは、このマシンでサービスを使用していませんでした。 少し後にそのようなアラートを受け取りました：



後で、同じマシンのブラウザーからDropboxにアクセスすると、すぐにメッセージが届きました：



もちろん、これらの手紙はシステムへのログインを妨げませんでした。もちろん、私の代わりに、攻撃者が被害者のアクセス詳細を入手した可能性があります。 しかし、彼らはすぐに事件を私に通知しました、そして、それは非常に価値があります-この情報に導かれて、必要ならば、私のアカウントに侵入した人を追放することができました。 Dropboxは、過去5年間に承認したすべてのデバイスを表示し、承認を取り消す機会を提供しました。



この方法でアカウントの動作を追跡する機能は非常に便利です。 たとえば、Facebookアカウントに現在ログインしているデバイスを確認できます。



DropboxおよびYammerの場合と同様に、リストから任意のデバイスでログアウトするオプションも提供します。 これは、正当な所有者が誰かがアカウントへの不正アクセスを取得した状況で、少なくともある程度アカウントの制御を取り戻すことができることを意味します。 現代のサービスの多くがこの機会を提供しています。 これの良い例はGithubです。これは、IPアドレスや、セキュリティの観点から重要な特定のイベント（2要素識別の要求や公開キーの作成など）など、さらに詳細な情報を提供します。

別の可能なシナリオを次に示します。



パスワードが正しく入力されたときにログイン試行が通知されるようにしたいのですが、二要素認証はパスしませんでした。 これは、パスワードが間違った手に渡ったことを明確に示しています。

これも非常に合理的であり、イニシアチブを取り、ユーザーに警告する価値があるさまざまなシナリオを考えると、最小限の労力でどれだけできるかを理解し始めます。

侵害されたパスワードをロックする

登録データとそれらに関連するすべてのデータの詰め込みに戻りましょう。 パスワードがどこかで強調表示されている場合、それらはもはや使用できないという意味で、「汚れている」と見なされる必要があります。 決して。 パブリックドメインになった今、膨大な数の人々がこれらの詳細に関する情報を持っているため、それらを使用する人のリスクが大幅に増加しています。 想像してみてください。実際のデータの漏洩から取得した10億ペアの電子メールアドレスとパスワードへのアクセスは、 登録データのスローに関する投稿で広めました 。



NISTはこの問題について次のように述べています。

秘密コードの作成または変更のリクエストを処理する場合、検証者は、広く普及している、予測可能な、または侵害されていると考えられるコードのリストで提案されたコードを検証する必要があります。 そのようなリストには、とりわけ、データベース漏洩資料からコンパイルされたエンクロージャーからのパスワードが含まれる場合があります。

簡単に言えば、誰かがアカウントを作成したり、パスワードを変更したりするときは、このパスワードがデータ漏洩に見られるものに含まれないようにする必要があります。 , , , , — , , . , «, ». , CloudPets , , - bcrypt , «cloudpets». , — !

, . , , , — , , NIST . , , , (, ) — , .



1% Dropbox ( )

, — . : , , , ? , , ? , , , , ? , Cloudpet, ?



, , . , Password Storage Cheat Sheet OWASP . , Dropbox — , .

, . , , , , , .

上記の要約

, IT-: , . , , , . , , , , , ( ), , , , .

そして、もう1つあります。理論的には、これらのガイドラインはすべて良いことですが、実践するのは少し難しい場合があります。このトピックは、今週リリースされる次の投稿で開発します。そこで、サイト所有者が加入者の安全を確保するのに役立つ、興味深い新しいことをお話しします。私は数週間それに取り組み、多くのエネルギーを費やし、結果を無料であなたと共有するつもりですので、すぐに私のサイトで確認してください。また、パブリックドメインに投稿したらすぐに、リソースへのリンクを追加して、この投稿を更新する予定です。お楽しみに！