Node.jsでの認証。 トレーニングマニュアルと考えられるエラー

かつて、Node.js / Express.jsで認証チュートリアルを探しに行きましたが、残念ながら完全に自分に合ったものを見つけることができませんでした。 不完全なものもあれば、経験の浅い開発者に危害を加える可能性のあるセキュリティバグを含むものもありました。



Devise for Railsと競合できるNode / Expressの信頼性の高い包括的な認証ソリューションを探していることをすぐに言わなければなりません。 しかし、リーダーシップの分野での憂鬱な状況は、私がこの資料を準備することを奨励しました。 ここでは、認証の分野で最も一般的なエラーのいくつかを説明し、それらを回避する方法について説明します。







上記の「経験の浅い開発者」について話しました。 彼らは誰ですか？ たとえば、サーバーサイドJSの渦に投げ込まれた数千人のフロントエンドプログラマーが、マニュアルから実用的な経験を得ようとしています。または、npm installを使用して、手元にあるものをすべてコピーアンドペーストしてすべてをインストールします。 問題の真剣な研究に時間を費やさないのはなぜですか？ 事実、彼らは良い生活からコピーアンドペーストせず、アウトソーシングマネージャーや広告代理店のある種のクリエイティブディレクターによって設定された期限に間に合わせるために邪魔にならないようにしなければなりません。



実際、適切な認証ガイドを探していたときに、ブログを持っているすべてのNodeプログラマーは、「正しく行う」方法、または「方法」に関する独自のチュートリアルを公開していると感じました終わった。」



Node.jsの開発で議論の余地があるのは、包括的で信頼性の高い認証ソリューションの欠如です。 この質問は、主にプログラマーの一種の運動と見なされます。 PassportはExpress.jsの事実上の標準ですが、このソリューションは認証戦略のセットのみを提供します。 Ruby on RailsのPlatformatec DeviseのようなNodeの堅牢なソリューションが必要な場合は、おそらく認証としてサービスを提供するスタートアップAuth0を使用する必要があります。



本格的なDeviseとは異なり、パスポートは中間のソフトウェア層であり、それ自体では認証プロセスのすべての部分をカバーしません。 Node開発者はPassportを使用して、トークンメカニズムとパスワードリセット用の独自のAPIを作成する必要があります。 ユーザー認証のためにルートとエンドポイントを準備する必要があります。 その上には、たとえば、いくつかの一般的なテンプレート言語を使用したインターフェースの作成があります。 そのため、Passport for Express.jsアプリケーションのインストールを支援することを目的としたチュートリアルが多数あります。 それらのほとんどすべてに特定のエラーが含まれています。 いずれも、機能するWebアプリケーションに必要な本格的なソリューションを作成することはできません。



これらのマニュアルの特定の作成者を攻撃するのではなく、自分の認証システムの展開に関連するセキュリティ上の問題を実証するためにエラーを使用します。 あなたがそのようなガイドの著者である場合、この資料を読んだ後、ガイドに変更を加えるかどうかを教えてください。 Node / Expressエコシステムをより安全にし、新しい開発者がアクセスしやすくしましょう。

間違い1：認証情報の保存

クレデンシャルストレージから始めましょう。 資格情報の書き込みと読み取りは、認証管理の分野で非常に一般的なタスクであり、これらの問題を解決する従来の方法は、独自のデータベースを使用することです。 Passportは、「このユーザーはテストに合格しました」または「このユーザーはテストに合格しませんでした」というアプリケーションに単純に伝える中間ソフトウェアであり、ローカルデータベースのパスワードストレージを操作するためにpassport-localモジュールが必要です。 このモジュールは、Passport.js自体と同じ開発者によって作成されています。



チュートリアルでこのうさぎの穴に進む前に、OWASPが用意した優れたパスワードストレージのチートシートを思い出してみましょう。これは、非常にエントロピーなパスワードを一意の「塩」で保存し、一方向の適応ハッシュ関数を使用することです。 ここでは 、この問題に関して意見の相違はありますが、codahale.comのbcryptミームを思い出すことができます。



私は、必要なものを探して、新しいユーザーExpress.jsとPassportのパスを繰り返し、最初にpassport-local自体の例を調べました。 Express 4.0のアプリケーションテンプレートがあり、これをコピーして自分のニーズに合わせて拡張できました。 ただし、このコードをコピーしただけでは、多くの有用なものは得られませんでした。 たとえば、データベースサポートサブシステムはありませんでした。 この例では、特定のアカウントセットを単純に使用しました。



一見、すべてが正常なようです。 通常のイントラネットアプリケーションです。 これを使用する開発者は非常に忙しく、何かを真剣に改善する時間はありません。 例のパスワードがハッシュされていないことは問題ではありません。 これらは、検証ロジックコードのすぐ横にプレーンテキストで保存されます。 また、資格情報ストレージはここでは考慮されていません。 素晴らしい認証システム。



別のパスポートローカルチュートリアルを探しましょう。 たとえば、Node Heroチュートリアルシリーズの一部であるRisingStackからこの資料に出会いました。 しかし、この出版物はまったく役に立ちませんでした。 彼女はGitHubでサンプルアプリケーションも提供しましたが、公式ガイドと同じ問題がありました。 ただし、8月8日にRisingStackがデモアプリケーションでbcryptを使用するようになったことに注意してください。



次に、Googleからの別の結果があります。これは、 express js passport-local tutorial



リクエストに応じて発行されます。 このマニュアルは2015年に作成されました。 Mongoose ODMを使用し、データベースから資格情報を読み取ります。 統合テストを含むすべてのものがあり、もちろん、使用できる別のテンプレートもあります。 ただし、Mongoose ODMは、以前のマニュアルのように、今回はMongoDBインスタンスでのみ、 Stringデータ型を使用してパスワードをプレーンテキストで保存します。 そして、MongoDBインスタンスは通常非常によく保護されていることを誰もが知っています。



学習ガイドの偏った選択について私を非難することができます。偏った選択がGoogleの検索結果の最初のページからリンクをクリックすることを意味する場合、あなたは正しいでしょう。



ここで、検索結果ページの一番上から資料を取得します。これは、TutsPlusのパスポートローカルガイドです。 このチュートリアルの方が優れていprocess.nextTick



。パスワードをハッシュするために労働率10のbcryptを使用し、 process.nextTick



を使用しprocess.nextTick



同期ハッシュチェックを遅くしprocess.nextTick



。



Googleの一番上の結果は、 scotch.ioのマニュアルです 。これも、8という低い労働率のbcryptを使用しています。8と10はどちらも少数ですが、8は非常に小さいです。 最近のbcryptライブラリのほとんどは12を使用しています。最初のbcrypt仕様がリリースされた直後、 18年前の管理アカウントでは8の労力係数が適切でした。



機密データの保存についても言及していませんが、これらのガイドはいずれもパスワードリセットメカニズムの実装を示していません。 多くの落とし穴がある認証システムのこの最も重要な部分は、開発者の演習として残されました。

間違い2：パスワードリセットシステム

同様のセキュリティ問題はパスワードのリセットです。 検索結果の上部にあるマニュアルには、Passportを使用してこれを行う方法については何も記載されていません。 調べるには、何か他のものを探す必要があります。



パスワードリセットのケースを台無しにする方法は数千あります。 この問題を解決する際に私が偶然目にした最も一般的なエラーは次のとおりです。

1. 予測可能なトークン 。 現在の時刻に基づいたトークンが良い例です。 貧弱な擬似乱数ジェネレータに基づいて構築されたトークンは、見た目は良くても問題を解決しません。
   
   
   
   
2. 不正なデータウェアハウス 。 暗号化されていないパスワードリセットトークンをデータベースに保存すると、解読された場合、これらのトークンはプレーンテキストで保存されたパスワードと同等になります。 暗号的に堅牢な擬似乱数ジェネレータを使用して長いトークンを作成すると、ブルートフォースを使用してパスワードリセットトークンに対するリモート攻撃を防ぐことができますが、ローカル攻撃からは保護されません。 パスワードリセット用のトークンは資格情報として取得し、それに応じて処理する必要があります。
   
   
   
   
3. 期限切れにならないトークン 。 トークンの有効期限が切れていない場合、攻撃者は一時的なパスワードリセットウィンドウを使用する時間があります。
   
   
   
   
4. 追加のチェックの欠如 。 パスワードをリセットする際の追加の質問は、事実上のデータ検証標準です。 もちろん、これは開発者が適切な質問を選択した場合にのみ期待どおりに機能します。 そのような質問にはそれぞれ問題があります。 ここでは、パスワードの回復に電子メールを使用することに言及する価値がありますが、これについての推論は不必要な再保険のように思えるかもしれません。 あなたのメールアドレスはあなたが知っているものではなく、あなたが持っているものです。 さまざまな認証要素を組み合わせています。 その結果、メールアドレスは、パスワードリセットトークンを送信するだけのアカウントのキーになります。
   
   

このすべてに出会ったことがない場合は、OWASPパスワードリセットのチートシートをご覧ください。 ここで、一般的な問題について説明したので、詳細に進み、Nodeエコシステムが提供するものを見てみましょう。



しばらくnpmに切り替えて、誰かがライブラリを作成してパスワードをリセットするかどうかを確認します。 たとえば、ここには、一般的に優れたサブスタック発行者の5年前のパッケージがあります 。 Nodeの開発速度を考えると、このパッケージは恐竜に似ており、 Math.random()



みたい場合、 Math.random()



関数はV8で予測可能であるため、トークンの作成には使用しないでください 。 さらに、このパッケージではPassportを使用しないため、さらに先に進みます。



ここでもStack Overflowはあまり役に立ちませんでした。 結局のところ、Stormpathの開発者は、少なくとも何らかの形でこのトピックに関連する投稿でIaaSスタートアップについて書くのが大好きです。 また、 ドキュメントはどこにでも表示され、パスワードをリセットするための資料があるブログを宣伝しています。 ただし、このすべてを読むことは時間の無駄です。 Stormpath-2017年8月17日に非稼働のプロジェクトが終了します 。



では、Google検索に戻ります。 実際、私たちにとって関心のあるトピックは単一の資料で開示されているようです。 express passport password reset



最初に見つかった結果を見てみましょう。 ここでも、労働集約度が5であり、現代の状況で必要なものよりもはるかに少ない旧友の暗号に出会います。



ただし、このガイドは、 crypto.randomBytes



を使用して、使用されなかった場合に期限切れになる真にランダムなトークンを作成するため、他のガイドと比較するとかなり全体的に見えます。 ただし、この深刻なガイドでは、パスワードをリセットする際の上記のエラーリストのポイント2および4は考慮されていません。 トークンは安全に保存されません-資格情報の保存に関連する認証マニュアルの最初のエラーを思い出します。



良いことは、そのようなシステムから盗まれたトークンの有効期間が限られていることです。 ただし、攻撃者がBSONインジェクションを介してデータベース内のユーザーオブジェクトにアクセスできる場合、または不適切なDBMS設定のためにMongoが自由にアクセスできる場合、これらのトークンの操作は非常に楽しいです。 攻撃者は、各ユーザーのパスワードリセットプロセスを開始し、データベースから暗号化されていないトークンを読み取り、ユーザーアカウントの独自のパスワードを作成するだけで、複数のビデオカードを備えた強力なコンピューターを使用して、bcryptハッシュに対するリソース集中型の辞書攻撃を行うことができます。

間違い3：APIトークン

APIトークンも資格情報です。 パスワードやパスワードリセットトークンと同じくらい重要です。 ほとんどすべての開発者はこれを知っており、AWSキー、Twitterアクセス​​コード、およびその他の類似のものを非常に安全に保存しようとしますが、多くの場合、これは作成するプログラムには適用されません。



JSON Web Tokens （JWT）システムを使用して、APIアクセス資格情報を作成します。 ブラックリストに追加でき、リクエストする必要があるステートレストークンを使用することは、近年使用されている古いAPIキー/シークレットテンプレートよりも優れています。 おそらく、初心者のNode.js開発者がJWTについて聞いたことがあるか、passport-jwtパッケージを見て、プロジェクトにJWT戦略を実装することにしたのかもしれません。 いずれにせよ、JWTはNode.jsの影響範囲に誰もが陥りそうな場所です。 （由緒あるThomas PtashekはJWTが悪いと述べていますが、だれかが彼を聞くとは思いません）。



Googleでexpress js jwt



を検索し、検索結果の最初の資料であるJWTを使用したユーザー認証に関するSony express js jwt



ましょう。 残念ながら、Passportは使用されていないため、この資料は何の助けにもなりませんが、確認中に資格情報の保存に関するエラーに注意してください。

1. JWTキーは GitHubリポジトリにプレーンテキストとして保存されます。
   
   
   
   
2. 対称暗号は、パスワードの保存に使用されます。 これは、誰かが暗号化キーを所有し、すべてのパスワードを解読できることを意味します。 さらに、暗号化キーとJWT秘密キーの間に不適切な関係があります。
   
   
   
   
3. ここでは、パスワードストアのデータを暗号化するために、AES-256-CTRアルゴリズムが使用されます。 AESはまったく使用しないでください。このオプションは何も変更しません。 このアルゴリズムが選ばれた理由はわかりませんが、これだけが暗号化されたデータを脆弱にします 。
   
   

ええ... Googleに戻って、さらにチュートリアルを探しましょう。 scotch.ioリソースは、パスポートローカルマニュアルで、パスワードの保存に関してすばらしい仕事をし 、独自のアイデアを単に無視し 、パスワードをプレーンテキストで新しい例に保存します。



ただし、このガイドにチャンスを与えることにしましたが、ファンをコピーして貼り付けることはお勧めできません。 これは、JWTでMongoose ユーザーオブジェクトをシリアル化するという興味深い機能が原因です。



このガイドのリポジトリを複製し、指示に従ってアプリケーションをデプロイして実行します。 MongooseからDeprecationWarning



をいくつか実行した後、 http://localhost:8080/setup



アクセスしてユーザーを作成できます。 次に、資格情報「Nick Cerminara」と「password」を/api/authenticate



に送信すると、トークンを受け取り、Postmanで表示します。





scotch.ioマニュアルに記載されているプログラムから取得したJWTトークン



JWTトークンは署名されていますが、暗号化されていないことに注意してください。 これは、2点間の大きなバイナリデータがBase64エンコードオブジェクトであることを意味します。 私たちはすぐにそれをデコードし、興味深い何かが私たちの前に開きます。





プレーンテキストパスワードよりも優れている可能性があるもの



トークンを持っている人は、期限切れのものであっても、ユーザーパスワードを持ち、同時にMongooseモデルに保存されている他のすべてのものを持っています。 トークンがHTTP経由で送信される場合、通常のスニファーを使用してトークンを捕捉できます。



別のガイドはどうですか？ 初心者向けに設計されており、Express、Passport、およびJWTを使用した認証専用です。 情報漏えいに関連する同じ脆弱性があります。 SlatePeakのスタートアップによって作成された次のガイドは、同じシリアル化を行います。 この時点で、検索を停止しました。

4番目のエラー：認証の試行回数を制限する

レビューしたマニュアルのいずれにも、認証の試行回数を制限したり、アカウントをブロックしたりすることについて言及していませんでした。



認証の試行回数を制限することなく、攻撃者は、例えばBurp Intruderを使用して、弱いパスワードを持つアカウントにアクセスすることを望んで、オンライン辞書攻撃を実行できます。 アカウントロックアウトは、次回ログインするときに追加情報を入力する必要があるため、この問題の解決にも役立ちます。



認証の試行回数を制限すると、サービスの可用性が向上することに注意してください。 そのため、bcryptを使用すると、プロセッサに深刻な負荷がかかります。 制限なしに、bcryptが呼び出される関数は、特に高い労働集約的な要因を使用する場合、アプリケーションレベルでサービス拒否のベクトルになります。 その結果、ユーザー登録またはパスワード検証を使用してシステムに入るための多くの要求を処理すると、サーバーに高い負荷がかかります。



このトピックに関する適切なチュートリアルはありませんが、 express-rate-limit 、 express-limiter 、 express-bruteなど、クエリの数を制限する多くのヘルパーライブラリがあります。 これらのモジュールのセキュリティレベルについて話すことはできませんし、勉強すらしませんでした。 一般に、実稼働システムでリバースプロキシを使用し、リクエスト数の制限の処理をnginxまたはその他のロードバランサーに渡すことをお勧めします。

結論：認証は簡単な作業ではありません

ほとんどの場合、トレーニングマニュアルの作成者は、「これは基本の説明です！ 誰も本番環境でこれを使用しないと確信しています！」 しかし、これらの言葉が真実ではないことを指摘せざるを得ません。 これは、トレーニングマニュアルにコードが含まれている場合に特に当てはまります。 人々は、マニュアルを読む人よりもはるかに多くの経験を持っているマニュアルの著者の言葉を信じています。



あなたが初心者なら、チュートリアルを信用しないでください。 そのような資料からコードをコピーして貼り付けると、確実にあなた、あなたの会社、そしてあなたの顧客がNode.js認証の分野の問題につながります。 信頼性が高く、すぐに使用できる本番の包括的な認証ライブラリが本当に必要な場合は、使用に便利なもの、より安定しており、時間の経過とともにテストされるものを見てください。 たとえば、Rails / Deviseの束で。



Node.jsエコシステムは、そのアクセシビリティにもかかわらず、実際の問題を解決するためにWebアプリケーションを緊急に作成する必要があるJS開発者にとって多くの危険をもたらします。 あなたの体験がフロントエンドに限定されていて、JavaScript以外の知識がない場合は、同様のソリューションをゼロからプログラミングして足を撃たない方法をすぐに学ぶよりも、Rubyを使い、巨人の肩に立つ方が簡単だと個人的に確信していますノード。



チュートリアルの作成者である場合は、特にテンプレートコードを更新してください。 このコードは実稼働に入ります。



信頼できるNode.js開発者であれば、私の話で、Passportベースの認証システムで何をすべきでないかについて、何か役に立つものを見つけていただければ幸いです。 確かに、あなたがすでにそのようなシステムを持っているなら、その中の何かが間違って行われています。 私の資料がすべての可能な認証エラーをカバーしていると言っているのではありません。 Expressアプリケーションの認証システムの作成は、特定のプロジェクトのすべての微妙な点を理解している開発者のタスクです。 その結果、彼は高品質で信頼できる何かを手に入れるべきです。 Node.jsでWebアプリケーションのセキュリティ問題について議論したい場合は、Twitterでメッセージを送ってください 。

この出版物の著者は、8月7日にRisingStackの代表者から連絡があったと報告しています。 彼らは、彼らのトレーニングマニュアルがパスワードを平文で保存しないと報告しました。 現在、コードとマニュアルでは、bcryptを使用しています。



さらに、彼は自分の素材に関するフィードバックに触発されてこのドキュメントを作成しました。 このドキュメントでは、Node.jsの認証分野から最高のものを収集するつもりです。



親愛なる読者！ Node.jsに基づいたWebアプリケーションでの認証システムの組織についてはどう思いますか？