こんにちは、Habr！ 私の名前はAkhmadeev Rinatです。私はSrです。 PHP開発者。
私はあなたにレポートの概要を提示します Bruteforceを倒し、Virgil Security with HighLoad ++ 2018の Alexey Ermishkinのハッカーを何も残さない方法 。
レポートに行ったとき、私は悲観的でした。 しかし、以来 Virgil Securityなので、私はまだ行くことにしました。 最初はレポートが本当にキャプテンのように見え、興味を失い始めましたが、結局は、通常のソルトハッシュ以外のいくつかの新しいパスワード保護アプローチを見つけました。
このレポートでは、ハッシュをFacebookのパスワードOnion、Sphinx、Pythiaなどのより現代的なアプローチからハッシュから保護する方法について説明しています。 最後に、新しいSimple Password-Hardened Encryption Services（PHE）がレビューされます。
報告書がとても気に入ったので、大要を作成しました。 皆さんに慣れておくようお勧めします。
Alexey Ermishkinはコメントでスライドとビデオレポートを共有しました。
アブストラクト
エントリー
みなさんこんにちは、おはようございます！ Highload Conferenceでお会いできてうれしいです。 私の名前はAlexey Ermishkinです。私はVirgil Securityで働いています。
私たちは、個々の開発者とビジネスの両方のために、さまざまな暗号化製品の開発に取り組んでいます。 エンドツーエンドのソリューションに焦点を当てています。これは、データ転送、認証などのアクションを実行するためにサービスを信頼する必要がない場合です。 SDKはオープンであり、すべてのユーザーがアクセスできます。
パスワードは、どこかにアクセスする方法として、認証ツールとして長い間使用されてきました。 それはコンピューターが登場するずっと前のことです。 しかし、コンピューターの出現、ITシステムの出現により、人々はパスワードを使用する習慣を放棄していません。 開発者にとってこれは非常に大きな問題になりました。システムを便利で高速かつ安全にする方法の問題に出くわしたからです。 多くの場合、これらの側面のうちのいくつかがうまく機能しようとすると、3番目の側面はうまく機能しません。 システムの生産性と安全性を高めると、不便になる可能性があります。
それでは、今日は何について話しますか？
オフライン攻撃に対する保護について説明します。 パスワードがデータベースに入ると、ユーザーはパスワードを制御しません。 データベースがハッキングされた場合、どこかでリークし、その後ハッカーはそれを使って何でもできます。 何らかの方法でパスワードを保護していても、パスワードの整理を開始でき、このために他の人とやり取りする必要はありません。彼らはすでにこのためのすべてを持っています。 また、ユーザーは弱いパスワードの使用をやめません。 パスワードポリシーはもちろん便利ですが、常に便利であるとは限りません。 入力する人でも強力なパスワードのように思える場合でも、ポリシーでは文字や数字を追加する必要があると言われていますが、彼らにとっては便利ではありません。 また、問題はユーザーが入力したものとデータベースにあるものとを比較する必要があることも明らかです。 安全な方法でそれを行う方法は？ まあ、会社の中には完全に友好的ではなく、彼らから身を守りたい人もいることを忘れないでください。
ハッシュ
原則として、パスワードがそんなに痛い主題であるのはなぜですか、なぜそれをより慎重に扱う価値があるのですか？ 問題は、パスワードのエントロピーが小さいことです。 エントロピーとは何ですか？ これは、データに含まれる情報量です。 たとえば、Highloadワードでは8文字は8バイトですが、エントロピーを計算すると、ワード全体のように64ビットではなく、30ビット未満になります。 今日、彼らはパスワードを破ることについて話しているとき、彼らは、そのような時間で、またはそれほど多くのビット以上で、エントロピーでパスワードをクラックすることが可能であると言います。 つまり パスワードの数も考慮されません。
ユーザーはどのようにパスワードセキュリティを始めましたか？ 最初に思いついたのは、単方向の暗号化ハッシュを使用することでした。
彼らの注目すべき特徴は、引き返すことができないことです。 つまり このハッシュに情報を転送し、出力で値を受け取った場合、この値からこの情報を取得することはできません。 しかし、残念ながら、それらは非常に迅速に計算されます。 たとえば、4枚のNVidiaグラフィックカードの最新のクラスターは、1秒間に数十億個のパスワードを処理できます。 つまり パスワードのエントロピーが40ビット未満の場合、4枚のビデオカードのクラスターが1分以内に取得します。
レインボーテーブル
さらに、各トリッキーハッシュには独自のレインボーテーブルがあります 。 この表は何で、どのように作られていますか？
つまり ハードドライブに収まる最も人気のあるパスワードと文字の組み合わせを使用し、それらのハッシュを考慮して、数テラバイトのストレージに追加します。 ある種のハッシュがある場合、それを計算することはできませんが、これらのテーブルから非常に高速に見つけ、以前に計算されたパスワードと比較します。 つまり テーブルの利点は非常に高速に動作することですが、テーブルを保存するには多くのスペースが必要です。 それにもかかわらず、インターネット上で最も人気のあるハッシュのテーブルがあり、それらをダウンロードしたり、購入することさえできます。
概要の作者のメモ： ウィキペディアは話者に同意しません：「レインボーテーブルは、テーブル内の検索時間と占有メモリ間の合理的な妥協のメカニズムを使用して暗号ハッシュ関数を逆にするための検索テーブルの特別なバージョンです。」 つまり ディスクに収まる最も一般的なパスワードのハッシュは保存されませんが、一部のパスワードのハッシュのみが残り、残りは存在するものに基づいて計算されます。テーブルにはレコードごとに複数のパスワードがあります。
塩
しかし、再び、各虹のテーブルには独自の塩があります。 塩とは？ これはランダムなバイトのセットであり、パスワードに追加されます。 ハッシュの近くのテーブルに保存され、レインボーテーブルから保護します。
つまり 塩漬けハッシュを使用してベースを使用するユーザーは、これらのハッシュを計算する必要があります。 しかし問題は、これらのハッシュが非常に迅速に計算され、塩がここではあまり役に立たないことです。
検索を遅くする方法は？
これからの自然な方法は、何らかの方法でハッシュのソートを遅くすることです。 これをどのように行うことができますか？
最も単純なアプローチは、たとえばsha256などのある種のハッシュ関数を使用して、反復的に計算することです。 ハッシュを計算し、このハッシュから再度ハッシュを計算するなど。 これを何千回、何百万回も行うことができます。 問題は、そのような実装を自分で記述すると、パスワード推測に専門的に関与している人々の実装よりも遅くなる可能性が高いことです。
したがって、暗号作成者は、パスワード検索の速度を落とすように特別に設計されたいくつかの機能を思い付きました-彼らは大量のメモリとすべての可能な最新のプロセッサ命令を使用しています。 このような機能で保護されたパスワードが攻撃者の手に渡ると、攻撃者は非常に強力なハードウェアを使用する必要があります。
たとえば、最新のArgon2関数は次のように機能します。図では、ハッシュが実行されるさまざまなメモリブロックがたくさんあることがわかります。 彼はこれをさまざまな方法で往復させ、メモリは非常に集中的に使用され、メモリ全体が使用されます。 そのような機能を最適化するのはかなり困難です（検索速度）。
しかし、これらのアプローチには欠点もあります。 これらの機能は特別に遅くなりますが、攻撃者にとってだけでなく特別に遅くなり、あなたにとっても特別に遅くなります。 彼らはあなたの鉄をロードします。 これらの機能はカスタマイズ可能です。 1つのパスワードのハッシュを計算するために使用されるメモリの量（最大数ギガバイト）、このメモリのパス数を選択できます。 これらのパラメーターを非常に真剣に巻くと、自分のハードウェアが苦しみ、システムに多くの人がログインしている場合は、パスワード保護と単純なパスワードのために非常に多くのリソースを割り当てる必要があります。 。
FacebookのパスワードOnion
人々はこれについて考え、質問をしました：バックエンドをロードせずに、自分のサーバーをロードせずに同じプロパティを達成することは可能ですか？
これの先駆者の1人はFacebookでした。 これらの行は、Facebookの歴史的な段階、パスワードの保護方法、最初は単なるパスワードでしたが、長い間クラックされていた古いmd5関数を取得し、そこに塩を追加してハッシュsha1を取得し、その後発生しました興味深いことに、彼らはhmac関数（これはキーを持つハッシュです）の計算をリモートサービスにもたらしました。
どのように機能しますか？ バックエンドがあり、リモートサービスがあります。 このサービスにはある種の秘密鍵があります。 人がバックエンドに入り、パスワードを入力します。 このパスワードは、データベース内のソルトと混合され、ハッシュを介して実行され、サービスに送信されます。 サービスは秘密鍵を取得し、hmac関数を計算して、すべてを送り返します。 バックエンドでは、ベースに配置されます。
それは何を与えますか？ Facebookにユーザーデータベースがある場合、リモートシークレットキーがないため、パスワードを並べ替える価値はありません。 しかし、Facebookのアプローチの問題は、リモートのプライベートキーに何かが発生すると、大きなトラブルに陥ることです。 ハッシュを使用し、hmacを使用するため、これで何もできません。 ユーザーが何にも気付かないように、この状況を何らかの形で解決する方法はありません。
スフィンクス
暗号作成者はすべてを見ました。 彼らは、リモートサービスを使用するというアイデアを気に入っており、次のように考えることにしました。 同様のシステムを作成することは可能ですが、Facebookが提供しているマイナス面はありませんか？
そして、彼らは次のようにこの問題に取り組むことに決めました：パスワードまたはパスワードハッシュが数字として表されるならばどうでしょうか？ passw0rd
という単語がある場合、8バイトで構成されています。 ほとんどすべてのプログラミング言語には、8バイトの整数型があります。 原則として、これはまったく同じです。 つまり 8バイト、単語passw0rd
で、通常の10進数として表すことができます。 これにより何が得られますか？ これにより、まったく異なる行動の自由が得られます。 それらからパスワードまたはハッシュを追加し、それらを乗算し、他のいくつかの数字に変換することができます。 それらを使用して、真に本格的な数学演算を実行できます。
この技術を使用した最初のシステムの1つはSphinxでした。 彼女は数年前に登場しました。 これは確定的なパスワードマネージャーです。 keepassのようなさまざまなプログラムがあり、マスターパスワードがあり、サイトごとにランダムなパスワードを生成します。 しかし、マスターパスワード、行きたいサイトを入力し、そこに何かを計算し、各サイトに固有のパスワードを発行する決定的なものもあります。 しかし、このマスターパスワードがどこかに行くと、サイトのすべてのパスワードが永久に危険にさらされることは明らかです。
Sphinxはこの問題にどのように取り組みましたか？ 彼はマスターパスワードを取得し、ログインしたいドメインを取得し、ハッシュ全体を実行し、それを数字に変換します。 しかし、実際には、そこで楕円暗号法が使用されています。簡単にするために、通常の数学で通常の数でこれをすべて説明します。 彼はそれを数字に変えて（ a
と呼ぼう）、次に何をしますか？
大きな乱数r
生成できるたびに、絶対に素晴らしいことです。 数値a
をr
の累乗に上げ、しばらくしa
からこの数値を数値r
逆の累乗に上げると、同じ数値a
戻りますか？ つまり 最初から何かをマスクしてから、マスクを解除できます。
そして、スフィンクスは何をしますか？ 繰り返しますが、ユーザーがいて、リモートサービスがあります。 マスクされた番号がこのリモートサービスに送信されます。 リモートサービスには、秘密キーb
ます。 彼は何をしていますか？ 彼は送信された番号a^r
に彼の秘密鍵b
を掛けて送り返します。 （ 要約の著者の注記：スライド上で、送信された数は秘密鍵で乗算されず、秘密鍵の程度まで上げられますが、要点はです ）。 数r
毎回異なるため、リモートサービスはどのパスワードとドメインがマスクされたかについては何も言えません。 彼はいくつかの異なる乱数を見るたびに。 そして、彼は単純に自分の秘密鍵b
を掛けて送り返します。
ユーザーはサーバーが送信したもののマスクを解除し、数字を取得します-ドメインとサーバーの秘密鍵を掛けたマスターパスワードa^b
。 彼はサーバーの秘密鍵を知らず、サーバーはユーザーが彼に送ったものを知りませんが、最終的にはある種の決定論的な数も取得します。 このプロトコルを実行するたびに、変装は異なりますが、結果は常に同じであり、この結果を何らかのパスワードに戻し、さまざまなサイトへの入力に使用できます。
本当に素晴らしいテクノロジー。 まず、大きなパスワードを生成できます。 破壊から保護します。 第二に、ハッカーが複数のパスワードにアクセスした場合、残りについては何も言えません。 それらは互いに独立して生成されます。 第三に、ユーザーのパスワードがどこかに消えても、ハッカーは秘密鍵を持たないため、これも何も提供しません。 4番目では、非常に迅速に動作します。 ここでは、反復的な大きなハッシュは必要ありません。 文字通り2-3の乗算が実行され、すべてが即座に機能します。
しかし、このシステムには欠点があります。 ユーザーが話しているサーバーは、彼について何も知りません。 彼は単に入力としていくつかの乱数を受け取り、それらに何かを掛けて送り返します。 また、クライアントはサーバーについて何も知らず、どこかに何かを送信し、結果を受信し、動作します。 しかし、サービスに何かが起こった場合、ユーザーはそれについて何も言うことができず、このための情報を持っていません。 秘密鍵も変更することはできません;それで何もできません。
ピチア
もっといいだろうか？
暗号作成者はこのシステムを見て、システムを改善し、エンドツーエンドの原則に準拠していると言えるようなプロパティを追加することは可能でしょうか？ つまり クライアントはサーバーと通信できますが、同時に認証もでき、ある程度まで信頼できます。
そして、彼らはPythiaと呼ばれるプロトコルを思いつきました。
それは素晴らしい人アダム・エヴァースポーと彼の同僚によって作られました。 何がユニークなのですか？ まず、サービスは誰がパスワードを入力したか、つまり ユーザーIDはパスワードを過ぎてサーバーに渡されます。 隣にあるランダムなIDボックス、または単なるユーザー名です。 関係ありません しかし、サービスはそれを知っています。 しかし、サーバーはこのことをほんの少し知っているだけでなく、それが彼であることを数学的に厳密に証明できます。
どのように機能しますか？ バックエンド（何らかのWebサービス、サイト）があり、Pythiaサービスがあります。 バックエンドは何をし、サービスは何をしますか？ サービスには秘密鍵k
がありますが、公開鍵もバックエンドに転送します。 サービスへのバックエンドは、Sphinxプロトコルの場合のようにマスクされた番号a^r
送信するだけでなく、何らかの種類のユーザー識別子（ UserID
）も送信します。 このサービスは、ユーザーIDとパスワードにその秘密キーを乗算し、結果(UserID, a)^(r*k)
がバックエンドを送信します。 また、応答として特定のProof
を送信します。これは、ハッキングされていないサーバーをチェックするためにバックエンドで使用でき、必要に応じて応答しています。
その後、マスクが解除され、結果として判明する数値y
がDBに格納されます。 データベースには、ハッシュだけでなく、数字、楕円曲線の点もあります。
ここにはいくつかの興味深い点があります。
- サーバーがユーザーIDとパスワードを1つの番号に結合する機能。 これは、双線形操作または双線形ペアリングと呼ばれます。 これは比較的新しい数学で、最近使用され始めました。 彼女はすべてがこれで正常であると誰もが確信するように、30年が経過していないという点で新しい数学者のすべての特性を持っています。
- しかし、サービスを送信する
Proof
はかなり古い技術です。 これは、Schnorrプロトコルと呼ばれます 。 公開鍵の生成は、基点に何らかの秘密鍵を乗算することです。 Schnorrプロトコルは、公開鍵の生成に使用された秘密鍵が、ユーザーのパスワードに同じ数字を掛けるために使用されたことを証明します。 このプロトコルは長い間存在しており、多くの場所で使用されており、証明することができます。 これはゼロプルーフ証明と呼ばれます -サーバーは公開鍵を表示しませんが、私が実行した操作はその秘密鍵によって実行されたと言います。
このシステムの利点は何ですか？
そして彼女には多くはありません。
- システムはバックエンドをロードしません。 バックエンドはすべてを実行するため、パスワードを数字に変換し、偽装して送信し、結果もマスク解除します。
- そのような番号のデータベースが盗まれた場合、秘密キーがないとパスワードのソートも意味がありません。
- Pythiaサービスは反復の試行をブロックできます。つまり、原則としてバックエンドはこれを行う必要がありません。 同じユーザーIDの下で、この変換操作を数回実行しようとすると、彼は単にそれを切り取り、レート制限でブロックすることができます。
- 変装のおかげで、サービスはパスワードについて何も知りません。 新しい乱数が彼に送信されるたびに。 ユーザーIDのみが一定です。
- ZKP（Zero-knowledge proof）のおかげで、バックエンドは、それが彼がかつて接触したまさにそのサービスであったことを常に知っています。
- たとえば、ハッシュとソルトを含むベースがある場合、ユーザー向けにこのようなソリューションにシームレスに移行できます。 彼らは何も気づかないかもしれません。 ユーザーのパスワードの代わりに、ハッシュを取得してPythiaに送り込み、このプロトコルを使用して番号
y
取得し、データベースに再度入力します。 その後、ハッシュを削除できます。 ユーザーがシステムにログインするたびに、このプロトコルが実行され、結果としていくつかの番号が取得されます。この番号をデータベースの内容と比較します。 認証システム自体は、次のように変更されません。 ユーザーは、同じパスワード（弱いパスワードでも）で以前にログインしてログインします。 この場合、システムははるかに安全になります。
しかし、これらはすべての利点ではありません。
主な機能の1つは、Pythiaサービスがハッキングされた場合でも、新しい秘密鍵を生成できることです。 データベースには、ハッシュではなく数値が保存されます。 古いキーを数値k
で表し、新しいキーを数値k'
で表すと、更新トークンと呼ばれる数値を計算できます。 これを行うには、新しい数に古い数の逆数を掛けます。 また、この更新トークンを使用すると、各ユーザーのデータベースを調べて、この数字y
に更新トークンを掛けることができます。 これを行った後、システムはリモートサービスの新しい秘密キーで引き続き動作します。 それはすべて瞬時に起こります。 災害が発生すると、パスワードデータベースが盗まれ、指をクリックするだけで更新トークンをリリースし、ハッカーがあなたから盗んだという事実が即座に役に立たなくなります。 バックグラウンドですべてのレコードを静かに歩き回って更新するだけで、新しいシークレットキーで動作します。 通常、ユーザーは何も気づきません。 つまり パスワードデータベースのシームレスな更新と即時の無効化は、このシステムの重要な革新的な機能の一部です。
しかし、それだけではありません。
基底にある数はy
が大きく、原則として大きく、むしろ擬似ランダムに見えます。 拾わないのはとても簡単です。 バックエンドにある機能、たとえばクライアントデバイスや電話に転送する場合、このy
を使用してキーを生成できます。 このことをBrainKeyと呼びました。 これは、ユーザーが電話のどこかにパスワードを入力し、それを偽装し、リモートサービスに送信することを意味します。 サービスは特定の数y
返し、このy
を使用して非対称キーを生成できます。 したがって、ユーザーは自分のパスワードからキーペアを取得できます。 これは、すべての種類のBrainWalletsで使用されます。 これは、パスワードを入力し、そのために生成されたビットコインウォレットを取得するときです。 ただし、このアプリケーションは暗号通貨に限定されず、デジタル署名、一部のバックアップ、およびアカウントの回復、つまり 非対称キーが必要な非対称暗号が使用される場所。 これらはすべて使用できますが、同時にキーペアを使用し、必要に応じて必要な数だけ生成できます。 したがって、それらはすべてユーザーのパスワードに依存し、これは非常に便利です。
蜂蜜の樽の中では、軟膏にハエがないわけではありません。
そして、この技術の特徴は非常に新しいことです。 双線形操作（ BLS12-381 ）用の楕円曲線を使用します。 数学自体は以前から存在していましたが、特に実装で使用されるこの特定の曲線は、私たち以外の
PHE
しかし、さらに改善できるかどうかを考えましたか？ 昨日の数学を使用して、Pythiaが提供する特性を達成することは可能ですか？ 明日でも今日でも、昨日でさえ、長年使用されてきました。
そして今年の7月、科学者たちはSimple Password-Hardened Encryption Services（略してPHE）と呼ばれる新しいプロトコルをリリースしました。
これはヨーロッパの科学者であるラッセル・ライです。
このサービスの利点は何ですか？ まず、標準のP-256曲線を使用します。これは、すべてのブラウザー、製品、どこでも使用されており、長年使用されているデフォルトの曲線です。 第二に、このことはPythiaよりも約10倍速く動作し、標準プリミティブを使用します。 ちょっと難しいですが、理解できないライブラリを使わずに自分で実装できます。 OpenSSLまたはBouncy Castleを使用できます。
ただし、動作は少し異なります。 再びバックエンドがあり、PHEサービスがあります。 バックエンドには公開キーがあり、サービスには秘密キーy
ます。 Pythiaとは異なり、登録プロセスとパスワード検証プロセスは少し異なります。 新しいユーザーがサービスにアクセスして登録したい場合、バックエンドは何をしますか？ 彼は最初からPHEサービスに尋ねました。登録に使用できるデータ、登録レコードを教えてください。 サービスはOKと言って、次のことでバックエンドに応答します。 ランダムな32バイトのソルト（ sNonce
）を生成します。 このソルトとその秘密キーyに基づいて、2つの数値を生成します。それらをC0
およびC1
と呼びましょう。 また、Schnorrプロトコル（以前のプロトコルと同様）を使用して、プライベートキーy
を使用してこれら2つの数値または2ポイントが正確に生成されたという証拠（ Proof
）を生成します。 バックエンドはProof
チェックします。 ここにはまだパスワードがありません。 バックエンドは何をしますか？ また、彼は自分の個人クライアントの秘密鍵x
を持ち、ユーザーからパスワードを受け取った後、サービスとほぼ同じように、そこにパスワードを追加するだけです。 ランダムなcNonce
（ランダムなクライアントソルト）、パスワードをHC0
、再び2つの数字HC0
とHC1
生成します。 なぜ2ですか？ 最初のHC0
認証に使用され、2番目の数字HC1
、乱数M
に秘密鍵x
（ MC
）を掛け合わせたものであるためです。 数値M
もサイズが32バイトで、後でユーザーデータの暗号化に使用できます（暗号化サービスがあります）（ メモの作成者によるメモ：この場合の暗号化キーはMC
）。 MC
番号は、ユーザーが正しいパスワードを入力した後にのみキーとして使用できます。 登録段階では、認証レコードだけでなく、ユーザーごとに一意の暗号化キーも生成できます。この暗号化キーを使用して、プロファイル、一部のデータなどを暗号化できます。 その後、バックエンドはサービスが送信したものと実行したものを単純に加算します-これらのポイントを加算してT0
とT1
を取得します。 最初のケースでは2つ（ C0 + HC0
）、2つ目は3つ（ C1 + HC1 + MC
）になります。 そして、これらの数字が得られた助けと、合計の結果として判明した2つの数字（ T0
とT1
）をsNonce
、塩基2の塩（ sNonce
、 cNonce
）を入れます。
したがって、ユーザー認証プロセスは逆の順序で行われます。 ユーザーはバックエンドでパスワードを入力します。 バックエンドはHC0
を計算し、データベース内にあるものからT0
からHC0
を減算し、結果のC0
をサーバーソルトとともにサービスに送信します。 サーバーソルトを知っているサービスは、それ自体で同じポイントを計算し、バックエンドを送信したかどうかを照合し、一致した場合はパスワードが正しいため、番号からHC1
一緒に減算する2番目の数字C1
で答えることができますT1
および暗号化キーを取得します。 したがって、PHEサービスのパスワードはなくなりません。 彼はバックエンドからも離れません。 それは、バックエンドの秘密鍵で乗算されたいくつかのポイントの形式です。 それ自体は存在しませんが、同時に、リモートサービスはこのパスワードが正しいかどうかについて厳密な結論を下し、プライベートキーy
を使用してすべての計算を実行したことを証明できます。
このシステムにはどのような機能がありますか？
私が言ったように、パスワードはバックエンドを離れません。 ただし、Pythiaとは異なり、バックエンドに秘密キーが必要です。 よく必要であり、どこかに保存してください。 PHEには、Pythiaのすべての基本機能があります。
- 秘密鍵で何かが起こった場合、更新トークンを発行することもできます。
- また、データベース全体を調べて更新することもできます。
- 検索保護;
- サービスはパスワードについて何も知りません。
- (Pythia , , , , PHE );
- .
...
… . . passw0rd.io . password , 18- , , zero trust, .. . , , .. Let's encrypt . , . CLI , . 2 SDK , GO .Net, .
:
- .
- .
- .
, .
?
37. ?
.
Q: , ! . , Pythia update token, ? private key . update token? かどうか？
A: , update token- .
Q: . - update token-, Private key ?
A: , update token-, , - , , , update token. , .. .
Q: , , , .
A: .. .
Q: , , , - Pythia - , , , ?
A: .
Q: ?
A: , Pythia . つまり , .
Q: ( ) bcrypt ?
A: , , , .
Q: , . ? , …
A: password
Q: password ? ファイアー！ 一般的に。
A: 123456 , 12345, 123456.
Q: . Pythia , PHE .
A: , .
Q: . . ? production ?
A: . あ！ Pythia.
Q: Pythia, , ?
A: .
Q: , ?
A: .
Q: , , !
A: SDK, .
Q: , , , , .. - , ? ? ?
A: , , , .. PHE, , 5 2 , 2 5 . , . PHE ( , ), , 10 , .
Q: .. - , - ? ?
A: . rate limiting, , .
Q: .. , ?
A: .
Q: . , .. Pythia (), , ? ?
A: , , .
Q: , update ?
A: , Pythia , , - - , , , )
A: ? ! 楽しんでいただけましたでしょうか。 , , PHE, , .
結論
PHE ( ) + — ( , , ) ( ). PHE , .
:
- ( ) ;
- ( ).
, .
Scratch Virgil Security , , !
( )?
UPD : Scratch . . , . .