認証への神のアプローチ

1992年にバージニア大学でコンピューターサイエンスをテーマにした簡易形式のコースを修了しました。 単純化されたコースを選んだ理由は、バージニア大学の通常のCSコースには工学学校が必要であり、数学と物理学の準備ができていなかったからです。 簡略化されたコースの美しさは、興味のあるすべての科目にアクセスでき、残りはスキップできることでした。



私のお気に入りのテーマの1つは、少なくとも何よりも覚えていることですが、「アルゴリズム」でした。 私はいつもこれについて尋ねる人々に、この主題がプログラマーとしての私の形成に最も影響を与えたと言います。 正確な理由はわかりませんが、数年前に奇妙な予感があり、何らかの理由でRandy Pausch （ 同じ本の著者）の ページに行きました。 彼が彼のコースのために学生を募集しているのを見つけて驚いた。 完璧な時期でした。バージニア大学、1991年秋、CS461アルゴリズムの分析とコース内の50人の学生。 私もその一人でした。



そして、間違いなくこのコースに感銘を受けました。 パウシュは非常に素晴らしくカリスマ的な教師であり、古い選択の意味を理解しているので、最初に教師を選択する必要があります。 それは現実をとても反映しています。



アルゴリズムはプログラミングの最も重要ではないにしても、最も重要な部分の1つであるため、優れた教師とテーマの組み合わせがうまくいきました。 新しいアルゴリズムを発明したわけではありませんが、既存のアルゴリズムを理解し、さまざまな入力データで実行速度を評価し、タスクに適したアルゴリズムを決定する必要がありました。 これらは私たちのコースの目標でした。



そして、Randy Pauschが教えてくれた最もクールなことの1つは、アルゴリズムを選択する前に次の質問を自問することでした。

神はどのアルゴリズムを選択しますか？

神がリストを並べ替える際に、バブルソート、クイックソート、または人間のようなシェルのソートを選択しなかったことは明らかです。 彼はただちにすべてのオブジェクトを正しい順序に並べました。 ワンステップで。 ランタイムの下限はO（1）です。 特定の時間ではなく、ほんの一歩です。 一瞬で。 結局のところ、あなたは神です。



そのような考えはその時に私の心を吹き飛ばしました。



私は、人々が神の役割を果たす必要があるために、本当のプログラマーになるのではないかといつも疑っていました。 Randy Pauschはこの概念を採用し、それを使用して問題の境界を設定する方法を明確に示し、自分が何をしているのか、なぜそれについて複雑な質問をするのかを自問しました。



そのため、 Discourseの認証ウィンドウを作成したときに、このコースで学習した内容に戻り、1つの質問をしました。

神はこのウィンドウをどのように実装しますか？

もちろん、答えは明らかです。神はこのウィンドウの開発に関与しないでしょう。 なんで？ 彼は神であり、一度申請に登録すると、彼はあなたが誰であるかを常に理解します。



神は私たちの投資家ではないので、明らかな理由で、これは私たちにとって不可能な仕事です。



しかし、認証への神聖なアプローチの実装にどれだけ近づくことができますか？ それは間違いなく高貴で価値のある成果です。











ビル・ゲイツは、なぜすべてのプログラマーが何度も何度もファイルを選択するために同じウィンドウを書く理由を尋ねませんでしたか？ この問題は、認証に起因する場合もあります。 なんで？ 私は長い間、最高の認証ウィンドウは完全に存在しないと言ってきましたが、これが可能なあらゆる状況でネットワークドライバーを使用した認証のアイデアを絶対にサポートします。 したがって、他のサービスを介してリソースを入力する可能性を認識している場合、私たちのチームは完全にあなたと連帯しています。











しかし、今日は最も重要な認証方法であるユーザー名（以下、ログイン）とパスワードに注意を向けたいと思います。 これは、他の方法を実装するまでサイトにアクセスする主な方法です。



2つのフィールド、2つのボタン、およびリンクを持つ認証フォームは、非常にシンプルに見えますよね？ これが標準です。 ユーザーがログインに問題を起こすまで真。 考え直してみましょう。

ユーザーがメールを使用してサインインできるようにします

私がこのサービスをサイトに入る方法として本当に気に入っていたという事実にもかかわらず、重大なOpenIDエラーは、ユーザーがURLを識別子として使用できると仮定したことでした。 これは奇妙で間違った決定であり、長い目で見ればOpenIDが将来の標準にならない理由となりました。



ログイン時のユーザーIDはメールのみです。 シンプルで明確。 パスワードを忘れるとどうなりますか？ メールを使用して復元しますか？ 彼女はあなたの識別子です。 一部の人はそれを認証する唯一の方法にすることさえ提案します。











もちろん、一意のユーザー名を持つことは良いことですが、常にユーザーがサイトに入る方法を電子メールまたは一意の名前を使用して選択できるようにします。 これは、100％の確率で、ユーザーがパスワードを忘れた場合、パスワードをリセットまたは復元するために、いずれにしてもメールを使用する必要があると言えるからです。 メールとパスワードは、常に一緒に使用される関連性の高い概念です。 いつも！



（そして、自分のメールを一意の識別子として使用することを許可していないサービスで、fuを表明したいと思います。私はあなたをフォローしています。）

メールのあるアカウントが存在しない場合、ユーザーに通知します。

さて、今では、メールはほとんどの人にとって事実上の識別基準であり、これは論理的かつ必要な事態であることがわかっています。 しかし、あなたのサイトで私の多くのメールのどれを使うべきですか？



これにより、他のユーザーがパスワード回復の形式でメールを入力するときに、他のユーザーの個人データを表示するかどうかについての談話に関する多くの議論が生じました。 多くのサイトでは、パスワード回復フォームにメールを入力すると、次のメッセージが表示されます。

このアドレスのアカウントが存在する場合、パスワードをリセットする手順が電子メールで送信されています。

この問題のキーワードはifです。これは、リソースのユーザーの個人データを開示する可能性を完全に排除します 。



談話を開発する際にこれらのことを真剣に考えているため、外部へのメールデータの開示にさらされることはありません。 しかし、多くのユーザーがメールを推測しようとすると、「今回はどのような種類のメールを入力しますか？」という通知を受け取りました。











そのため、サービスに存在しない通知メールに表示することが決定されました。 このソリューションは、完全に安全でユーザーフレンドリーです。 必要に応じて、サービスの設定でメールを使用したこのような操作を禁止できます。

ユーザーがいつでもログインフォームと登録フォームを切り替えられるようにする

多くのサイトでは、ログインボタンと登録が隣り合わせに表示されます。 これは私を困惑させました。認証プロセスと登録プロセスがまったく異なるからです。



まあ、ユーザーの観点から、これは完全に真実ではないかもしれません。 有名な雑誌The Vergeのサイトにあるログインフォームは、ログインフォームと登録フォームがどれだけ近いかを示しています。











これらのプロセス間に特定の類似性が存在することを認識しているため、スイッチを介して実装することで両方のフォームを同時に利用できるようにしました。











これらのフォームは両方ともポップアップウィンドウを介して実装され、画面から簡単に削除したり、ログインまたは登録ボタンを押して再び表示したりできます。

簡単な言葉を選ぶ

これは大きな言語の問題です。 同じことを意味する言葉がたくさんあります。

• サインイン
• ログイン
• サインアップ
• 登録する
• [サイト]に参加
• アカウントの作成（アカウントの作成またはアカウントの作成）
• 始めましょう
• 購読（ただし、ほとんどの場合、有料の購読を意味します）

これらの言葉のどれが最も適切ですか？ ユーザーデータとその（ユーザー）動作の調査結果も誤って解釈され、さらにエラーが発生する可能性があります。



私は簡潔さと簡潔さが好きなので、できるだけ短い言葉を使用することを好みます。 しかし、これらのことは非常に頻繁に状況とユーザーの好みに依存します 。











ログインは最も一般的で直感的にタスクに適していますが、ログインはコンピュータシステムに固有の歴史的に発展した特定の意味を持っているため、この言葉も価値があります。

数年前、私はアメリカとイギリスで最も人気のあるサイトについて、どの言葉が使われているかについて調査しました。 サインインの使用量が普及しており、常に増加していることに気付きました。 そして、これは人気のあるサイトで特に顕著です。

一般的なブラウザのパスワードマネージャーと連携する

作成する認証の各形式は、次のような一般的なブラウザのパスワードマネージャーと互換性があり、機能する必要があります。

• インターネットエクスプローラー
• クロム
• Firefox
• サファリ

これは必要最小限です。 ブラウザーの1つで次に認証を試行すると、ユーザーIDとパスワードのフィールドが入力されます。











ユーザーはブラウザに組み込まれたこれらのものに依存しており、認証の実装ではこの事実を尊重し、それを考慮して実装する必要があります。 たとえば、HTMLコードでは、パスワードフィールドに次の属性が必要です。type= passwordと、このフィールドをパスワードフィールドとして識別する名前。



LastPassなど、サードパーティのパスワードマネージャーも多数ありますが、ほとんどの場合、人気のあるブラウザーの組み込みマネージャーと連携することに集中する価値があります。 フォームがそれらで機能する場合、サードパーティのマネージャーで機能する可能性が最も高くなります。

最も一般的なユーザーエラーを処理する

ユーザーはCaps Lockでパスワードを入力しますか？ 彼にそれについて警告してください。











彼はname@gmail.comの代わりにname@gmail.coを使用してメールを入力しましたか？ あるいは、name @ hotmail.comの代わりにname@hotmail.cmを書いたのでしょうか？ また、これらのエラーを修正し、これについてユーザーに警告する必要があります。



（ パスワードスヌーピング機能の大ファンでもあります。ユーザーはパスワードを正しく入力したかどうかを確認できます。InternetExplorerのみがSafariでこの機能をサポートしているようですが、他の人もサポートする必要があります。）

ユーザーが正しいパスワードを選択できるようにする

password123、Iloveyouなどのように 、発音が難しくなく困難ではないパスワードを選択する正しい方法を教える多くの方法があります。



入力中にパスワードの強度を測定する簡単な方法があります。 そして、それを使用することをお勧めします。

これは良い考えですが、一部のサイトでは邪魔に見えます。 パスワードの強度の基準はサービス自体によって決定されるため、これを実装することも望まれています。 あるサイトでは、パスワードは信頼できますが、別のサイトでは、しきい値を入力することさえ許可されません。











したがって、 談話では、別の方法で行うことにしました。 パスワードの最小の長さを8文字にし、そのハッシュによって世界で最も人気のある10,000個のパスワードに含まれるかどうか決定しました 。

キーボードを忘れないでください

キーボードを使用してサイトとやり取りするユーザーは死にかけていますが、まだ生きている人にとっては、キーボードを使用してフォームの要素をナビゲートできるようにすることは価値があります。











そして、意図したとおりに動作することを確認してください。

試行回数をすべての可能なアクションに制限します

サイトで可能なアクションを実行しようとするユーザーの試行回数を制限する必要があります。 これは特に認証フォームに当てはまります。



誰かがパスワードを忘れて、サイトへの入力またはパスワードのリセットを3回試みた場合、これは正常です。 しかし、誰かがこれを1000回行った場合、これはかなり奇妙です。 私はこれが人ではないことを提案するためにベンチャーします。











アカウントを一時的にブロックしたり、複数回ログインに失敗した場合にキャプチャを表示するなど、面白いことを行うことができます。 しかし、そのようなものに夢中になりすぎないでください。



同じIPアドレスからパスワードを入力または回復するために、標準の一時停止を適度に間隔を空けて使用することをお勧めします。 そして、私たちのサイトでやった。

言及し忘れたもの

私は、 談話の理想的なフォームを開発する際に経験したことをすべて思い出そうとしましたが、何かを忘れたり、十分な詳細を伝えなかったと確信しています。 私たちの談話プロジェクトは100％オープンであり、常に進化しています。 いつでも実装を確認してテストできます。



認証ウィンドウには、2つのフィールド、リンク、2つのボタンがある単純なフォームが含まれています。 それでも、上記のすべてを読んだ後、この単純さが欺かれていることに同意すると思います。 最善の解決策は、認証フォームをゼロから設計するのではなく、可能な限りサードパーティの認証ソースに依存することです。



この記事は翻訳です。 このリンクで元の記事を見つけることができます。