私の計画はこれらの攻撃にさらされているWebサイトの99%より安全ではありませんか?

私はREST APIを使ってモバイルやデスクトップブラウザ用の一種のソーシャルネットワークを開発します。

U2Fキーやハードウェアを購入するようユーザーに頼むことはできません(ただし、Chrome/Firefoxは現在ネイティブでサポートしているので、持っていればサポートすることを提案できます)。

大多数のユーザーが複数のWebサイトで同じパスワードを使用しているため、パスワードを要求したくありません。そのため、パスワードをクリアテキストで保存する、またはハッシュ化したが塩漬けにしていない、レインボーテーブルを使用してパスワードをクリアに取得するなど、弱いWebサイトをハッキングするのは簡単です。

私は彼が資格情報を失ったときにユーザーの身元を証明する必要がありますが、これは攻撃のベクトルを開くので、私はemail/smsによる古典的なOTPリンクを望みません。 /オタクしかし彼女は簡単に私は私のパスワードをリセットし、私のアカウントに接続するために«私は私のパスワードを忘れました»をクリックし、Mail/SMSアプリケーションに行きます)

あなたの妻/家族/友人は一般的に答えることができるので、それはプライバシーの漏洩であり、そしてユーザーは常に使用される正確な言葉/構文を覚えていないので、私は登録に個人的な質問/答えを求めたくありません。

私はこれらの攻撃に抵抗するユーザーフレンドリーな方法を探します。 (だから、これらの攻撃にさらされているスキームを使うように言ってSTOPを止めてください)

私はスキームの提案があります、ここのほとんどの専門家は新しいスキームについて考えるのを好みません、しかし私が知っている既存のすべてのスキームはこれらの攻撃を解決しません:(

私の質問は簡単です: 私の計画はこれらの攻撃にさらされているWebサイトの99%より安全性が低いですか。

My scheme idea: https://medium.com/@lakano/an-idea-to-have-a-user-friendly-safe-authentification-3766af611560

4
コメントは詳細な議論のためではありません。この会話はチャットに移動しました。
追加された 著者 Rory Alsop,

5 答え

いいえ、これは蒸し暑い混乱です。実際、この2FAとさえ呼ぶのは誤称です。実際に行ったことは、要因の1つを排除することです。これは、2要素認証よりもサイドチャネル認証に近いです。

適切な2番目の要素を持たないことに加えて、不要な複雑さと非標準のインターフェースを備えたシステムを作成しました。これは2つの異なる方法であなたを噛むでしょう。まず、ユーザーはシステムの使い方を知らないでしょう。第二に、あなたはそれをプログラムする方法がわかりません。

それは標準的ではないのであなたのユーザーは永遠に混乱するでしょう。システムに不慣れであるという理由だけで、彼らは間違いを犯して自分自身のセキュリティを危険にさらすでしょう。

それは標準的ではないのでまた間違いをするでしょう。セキュリティの各層を実装する負担はあなたにあります、そしてこの概念を使用して確立されたパターンがないのであなたは必然的にシステムを危険にさらすでしょう。これはあなた自身の暗号を転がすのに似ています。概念的な段階でも、衝突に強くないファイルの整合性チェックサムを使用して間違ったテクノロジを提案しました。しかし、ここでの問題はそれより深くなります。たとえあなたがそれを修正して適切なハッシュタイプを使用しようとしても、あなたが知らない、そして他のソフトウェアに組み込まれている標準的な緩和策を持っていないあらゆる種類の攻撃面を露出しています。ユーザーをパスワードフィッシングから保護するために、このファイルAPIの使用からユーザーを保護する方法はわかりません(この使用を念頭に置いて設計されたものではありません)。

この道を下りてはいけません。ユーザーのために、より確立されたパターンと通常の2FAに固執する。

15
追加された
@ lakano正しく実装された2FAでは、1つの電子メールからの魔法のリンクだけでは認証できません。確かに多くのシステムがそれが提供するセキュリティを追加することなしに2FAを宣伝します、しかしあなたが正しい2FAを理解しないならばあなたは代わりを提供する立場にありません。どのベクトルを開くのかを証明するのに十分な詳細な説明をあなたのコンセプトに与えていませんでしたが、たとえ私たちがそれらの周りで自分自身のことを話そうとしたとしてもそうです。私が提供しているものはコードレビューではなく、全体的な概念のレビューです - そして私はそれがあなたが下へ行くための良い読みではないことを示唆しています。
追加された 著者 Josh Brown,
私は私の答えを待っています。あなたが編集したことはすべて、あなたが車輪を再発明しようとしていること、そして実際にあなたが何をしているのかわからないことを明確にすることです。これは私がここにリストする同じ2つの一般的な理由から悪い考えです。あなたは単一要素認証の問題を解決しようとしています - 私はあなたがあなたの時間とエネルギーを学ぶことと確立された2FAベストプラクティスを実行することをあなたに勧めます。 OTPジェネレーターアプリやハードウェアキーなどの既存のメカニズムを使用した優れた2FAは、自社製コンセプトよりもユーザーを保護します。
追加された 著者 Josh Brown,
@AndrolGenhaldこのOPのスキームでは、ファイル がリカバリ方法です。承認されたデバイスが利用できない場合のリカバリ方法です。プライマリが失敗した場合(チェックサムが衝突に耐えられず、時間やチャレンジベースの制限がない場合には安全ではありません)、基本的にセカンダリキー(セカンダリファクタ、セカンダリメソッドではありません)として使用されます。フィッシングに対する耐性を持たせます。
追加された 著者 Josh Brown,
@lakanoアカウントの復旧は、一般的に認証における最も弱いリンクの1つです。それを使用するか、一部のユーザーが自分のアカウントを復旧できなくなってしまうという事実を抱えて生活することができます。これは実際にフィッシング攻撃やプロキシ攻撃を防ぐため、FIDO U2Fを検討することをお勧めします。データベースが危険にさらされても安全です。あなたの計画はこれらの事のどれも防ぎません。
追加された 著者 AndrolGenhald,
@lakanoもしあなたが自分のシステムを構築しようとするのではなく、少なくとも現存のTOTPシステムを調べてハードウェアトークンを購入することをあなたのユーザに頼りたくないのであれば。
追加された 著者 AndrolGenhald,
@lakanoアカウントの回復にTOTPやバックアップコードを要求する以上に、あなたの計画には利点はありません。
追加された 著者 AndrolGenhald,
@lakano回復ファイルを紛失した場合、ユーザーはどのようにして自分の身元を証明できるのでしょうか。
追加された 著者 AndrolGenhald,
正しい、本質的にこれはあなた自身のソフトウェアトークン実装を構築している。 32ビットのハッシュではなく、チェックサムで何が問題になる可能性がありますか?
追加された 著者 Yaser Sulaiman,
@カレブ:あなたの厄介者の中に、攻撃のベクトルを説明できるものは何も見当たらない。ほとんどのWebサイトでは、(私ではなく)任意のデバイスからの接続が許可されており、電子メール以外に知られることなくOTPマジックリンクを使用できます(したがって、攻撃ベクトルはレスキューファイルを選択するよりも重要です)。攻撃のベクトルがどこにあるのか教えてください。
追加された 著者 Mohamed Yaser,
@Caleb(EDITパートに)精度を追加するために投稿を編集しましたが、もっと明確になるでしょう。
追加された 著者 Mohamed Yaser,
@Calebいいえ、良い2FAシステムはありません。 [2FAのあるWebサイト]を1つだけ教えてください。そうすれば、攻撃のベクトルがわかります。 [ユーザーが自分のデバイスやパスワードを紛失した場合、ほとんどのユーザーはアカウントの取得を許可する必要があるため]
追加された 著者 Mohamed Yaser,
@AndrolGenhaldはい、認証において最も弱いリンクです。外部サービスを使用しないことがセキュリティの最も重要な部分であるが、ユーザーが持っていて他に知られているものだけを使用するのはこのためです。 FIDO U2Fはハードウェアを必要とします、私は人々にそれを買うことを強制することはできません(しかしこれがChromeでネイティブに認識され、今日からFirefoxでそれを見てうれしいです)。既存のTOTPシステムの問題はまだあなたのアカウントを回復する必要がある場合です。
追加された 著者 Mohamed Yaser,
@AndrolGenhald 1.パスワードによる攻撃を解決します(ユーザーは同じパスワードを使用します)。 2.レスキューリンクへの攻撃を解決する(電子メールアクセス)。あなたのTOTPシステムで、私が資格を失ったとき、どのようにユーザーは彼の身分を証明することができますか?
追加された 著者 Mohamed Yaser,

これには非常に多くの問題がありますが、あなたの主な質問は2FAについてであり、あなたは攻撃が何であるかを尋ねていると仮定すると...

2FAは、オーセンティケータの1つの妥協を軽減することを目的としています。 「知っていること」に加えて「持っていること」を使用することで、攻撃者がユーザーと認証システム間のデータフローにアクセスできる場合、つまり「知っていること」を観察できる場合アクセスを得るために、彼らの攻撃であるという希望はこの段階で失敗するでしょう。

あなたのシナリオでは、データフローにアクセスする攻撃者はパスワード(あなたが知っているもの)だけでなく「デバイスの認証」のために選択されたファイルの詳細も見ることができるでしょう同じ特徴を持ち、悪意のあるデバイスを認証し、認証されたユーザーになりすますことができる別のファイル。

攻撃者がデータフローにアクセスできる場合は、データが別のデバイスから来ているように見せかけ、ファイルのCRCユーザーに確認を促して詳細を取得するようにデータを修正することもできます。

ファイルのCRCステップでは、異なる種類の攻撃を必要とする追加の要素が導入されることはないため、いくつかの複雑な問題を超えても価値はほとんどありません。

私はあなたの根本的な誤解は私がウィキペディアを引用するのは好きではありませんが、2FAが何であるかについてのあなたの文脈外引用と一致するために「あなたが持っている何か」と見なすものであると思う

所有する要素(「ユーザーだけが持っているもの」)は、何世紀にもわたり、ロックの鍵という形で認証に使用されてきました。基本的な原則は、鍵が鍵と鍵の間で共有される秘密を具現化することであり、同じ原則がコンピュータシステムにおける所有者認証の根底にあります。

あなたの前提は、ファイルはあなたのユーザーの一人が持っているものであるということですが、それが効果的な秘密であるためにはそれがユーザーだけに依存して'。

金庫を鍵でロックして、他の1000個の鍵でそれを切るとしたら、「正しい鍵がどのフックにかかっているかを知っているのは私だけです」と思いますか。

一般的に言って、あなたが要因を持っているものはコピーするのが簡単ではないはずであり(ユーザが他にそれができないならばある種の保証があるため)、これはリプレイ攻撃を防ぐのに役立ちます。誰かが何かが入力されているのを見ることができます、他にもたくさんありますが、うまくいけばあなたはポイントを得ます。望ましい特性などについてもっと詳しく調べてください。

あなたが説明したものは2FAではありません。

余談ですが、デバイスが認証されたデバイスであることを確認しているかどうかはまったくわかりませんが、そのためにも単純な攻撃が行われる可能性があります。

6
追加された
@lakanoあなたが記述するシステムは第二の要因でさえありません、それはあなたが知っている二つのことの単なるあいまいなバージョンです。
追加された 著者 Josh Brown,
あなたの質問は2FAについてでした、今あなたはゴールポストを動かしています。それにもかかわらず、ブラウザの攻撃者などが攻撃します...これ以上これを永続させることはしません。
追加された 著者 R15,
私はゴールポストを動かさないで、ゴールポストは私の2FAシステムが良いかどうかをチェックすることです...知られている(数字コード、または彼のハードドライブ上のどのファイルが登録時に使われたか)。
追加された 著者 Mohamed Yaser,
あなたは何かを忘れます。攻撃者は認証されたデバイスを必要としているので、たとえ彼が数字コードを盗聴するためにHTTPS通信をハッキングできたとしても、それは十分ではありません。また、CRC32ハッシュが登録時にサーバーにのみ送信されると言った場合、攻撃者は後でCRC32を盗聴するべきではありません。あなたが攻撃者が登録プロセスを盗聴すると思うが、それはどんなウェブサイトのための同じ問題でもあると思われるならば例外...
追加された 著者 Mohamed Yaser,
@calebこれは多要素認証です。まず自分が持っているものを承認する必要があります。また、知っているものが必要です。どちらかがなければ、これは機能しません。しかし、これが2FAではないと言ったとしても、投稿の目的はシンタックスワードリクエストではなく、代替システム認証のセキュリティです。
追加された 著者 Mohamed Yaser,
ところで、2FAの定義(ウィキペディアで)は、«2要素認証(2FAとも呼ばれる)は、2つの異なるコンポーネントの組み合わせを利用してユーザーの主張する身元を確認する方法です。二要素認証は、多要素認証の一種です。 »
追加された 著者 Mohamed Yaser,

質問を読んだ後、中程度の投稿をした後で、操作されている攻撃ベクトルや完全なセキュリティシアターが完全に理解されていないことは明らかです。

security に関するさまざまな質問から抜粋しました。

独自のセキュリティスキームを採用しないでください。

これには多くの理由がありますが、それを展開する前にそれが安全であることを確認するために開発の時間、テストのためのリソース、および外部の客観的なアセスメント評価を注ぐ必要があるからです。これにはたくさんのお金がかかります。

あなたがあなた自身の計画にしたくない最大の理由は、あなたがこれを転がしてそれを解放し、それが安全でないならばあなたはあなた自身とあなたのユーザに対して大規模なサービスを行ったからです。さらに悪いことに、あなたがそれを伝播するならば、あなたは世界に対して大規模な侮辱をしました。

あなたは一歩後退して、あなたが客観的な方法であなたがやろうとしていることを本当に評価して、そしていくつかのベストプラクティスを調べる必要があります。特にあなたの質問はずっと小さい、すでに尋ねられた質問にまとめられることができるので:

ユーザーフレンドリーで安全な方法でMFAを正しく実装するにはどうすればよいですか。

その質問には何年も前に答えました:標準化され広く採用されている時間ベースのコード(質問者はハードウェアキーはダメだと述べました)

ユーザーに自分のアカウントを安全に回復させるにはどうすればよいですか。

その質問には何年も前に回答されました。安全なサードパーティチャネルとワンタイムパスワードは、他には方法がないためです。

ユーザーを自分自身から保護するにはどうすればよいですか。

This question is a known quantity: You can't. Ever. A user is only as secure as the user keeps themselves

もっと大きな問題は、ユーザー自身が危険にさらされても問題にならないことです。

4
追加された
多要素認証が使用されるとき、安全なアカウントリセットサービスはしばしば使い捨てパスワード以外の他のチャンネルを使用するでしょう。例えば、GMailはアカウントが作成された日付のような質問をするでしょう、そして、Duoベースのログインはあなたが回復のために事前共有パスコードのセットを印刷することを可能にするでしょう。 Githubでは、回復のためにFacebookを使用できるようにFacebookアカウントを事前設定しましょう。質問者の期待に反して、アカウントの回復はユーザーに電子メールを送信することだけではありません。
追加された 著者 Nick Faraday,
そして、どうか私に教えてください。
追加された 著者 Mohamed Yaser,
どのWebサイトがリカバリソリューションで優れたMFAを使用しているかを教えてください。アカウントをハッキングするために複数の攻撃が考えられます。もちろん、ユーザーにYubiKeyのようなハードウェアを購入するよう依頼することはできません。
追加された 著者 Mohamed Yaser,

私はこの質問に答えるつもりです。修辞的な質問を提起し、あなたのシステムについて推論するためにそれらを使用します。

リクエストが「認証済みデバイス」から発信されたものかどうかを判断することをどのように計画していますか?あなたはすべてのリクエストと一緒にクッキーを送っていますか?チャレンジ - レスポンスを行っているTPMはありますか?ユーザーが自分のデバイスのバックアップを作成し、それを新しいデバイスに復元するとどうなりますか?新しいデバイスも自動的に「承認」されていますか?

私がそれを理解しているように、あなたがアカウント回復をしているとき、あなたはサーバーに「救助ファイル」を送るのではなく、代わりにCRC32を送る。 (なぜそれは特にCRC32でなければならないのですか?それはそれ自体がハッシュアルゴリズムではなくファイル完全性チェックサムアルゴリズムであるため、奇妙な選択のようです。まったくファイル? CRC32自体を保存しないのはなぜですか。デバイスがすべての要求とと​​もにCRC32を送信するようにしないのはなぜですか。

実際、ユーザーにCRC32を自分の「数字コード」と一緒に記憶させないのはなぜでしょうか。 (それがエントロピーを大幅に減らすので、なぜあなたがあなたの「ディジットコード」を4〜16の長さに(そして数字だけに)制限することに決めたのかもわかりません。

あなたのシステムがユーザーに彼の「ディジットコード」を入力してログインのためにCRC32を送ることを要求するならば、これは本質的に静的CRC32値とディジットコードの組み合わせがパスワードであることを意味しませんか?

ここに2つ目の要素があるとは思わない。

1日に2回試行に失敗した後にユーザーをロックアウトするレート制限によって、システムがDoSの脆弱性にさらされることにもなります。失敗したログインをそのユーザーとして繰り返し送信するだけで、そのユーザーをシステムから締め出すことができます。

あなたが提案した解決策のどれかがあなたが言及した攻撃のどれを防ぐのか私は知りません。セキュリティとユーザビリティがまったく向上しない、または悪くなるため、物事を不必要に複雑にしているという他の答えの感情を反映しています。

必要なセキュリティレベルを達成するための標準的な方法は次のとおりです。

  • 2つ目の要素は、機密事項(アカウントの変更やログインなど)に必要です。
  • 2番目の要因は、TOTPジェネレータや、1回しか使用できないトークンを生成するU2Fデバイスなどです。さらに、2FAという主要な方法を失った場合に備えて、ユーザーが一枚の紙に書き留める使い捨ての回復コードのリストです。
  • 2番目の要素がないとアカウントの復旧はできません(つまり、パスワードを電子メールにリセットするためのリンクがまだありますが、実際にパスワードを変更するには2番目の要素が必要です)。

私は少なくともHeroku、GitHub、そしてGoogleがこのようにしていることを知っています。これは標準的なやり方で、間違いを犯す可能性は低くなります。ユーザーがその使い方を理解するようになるでしょう。 2FAトークンは1回限りの使用であるため、あなたも無料のブルートフォース保護を受けられます。

tl; dr:あなたの解決策は過度に複雑で、否定的なセキュリティにはほとんど加えず、あなたが望むものを達成するための実証済みの標準的な方法があります。

3
追加された
あなたはこのうさぎのあなたの穴の中にかなり深く入り込んでいます - 脆弱性で大打撃をすること。私の答えで述べた、はるかに単純でより広く受け入れられ使用されている方法よりも、あなたのシステムがどのようにしてセキュリティを強化するのか私はわかりません。
追加された 著者 Rosa Gronchi,
あなたはブルートフォースを解決していますが、あなたはまだここでDoS問題を解決していません。すべての認証済みデバイスを紛失したため、再びログインする必要があるとしますが、偽の情報でログインをスパムしています。
追加された 著者 Rosa Gronchi,
しかし、アカウントの回復はどのように機能するのでしょうか。ユーザーが自分のデバイスを紛失した場合、アクセスを回復するために失ったデバイスから新しいデバイスを認証する必要があると言っているのでしょうか。
追加された 著者 Rosa Gronchi,
そう、それであなたは本質的にデバイスを識別するためのすべてのリクエストでクッキーを送っているのです。これがDoS攻撃をどのように防止するのか私にはわかりません。ユーザーが自分のデバイスを紛失した場合、アクセス権を取り戻すには、「ディジットコード」と「レスキューファイル」のCRC32を送信する必要がありますか?人々を締め出すために私があなたのアカウント回復ページに間違ったログイン情報を送らないようにするのはなぜですか?
追加された 著者 Rosa Gronchi,
よくわかりませんでした。許可されていないデバイスにアクセスすると、メールに記入されます。たとえ攻撃者が自分の正規のデバイスを紛失したと言ったとしても、通知は他のすべての正規のデバイスに送信されます(したがって、DoS攻撃があった場合、ユーザーはそれをX日間ブロックできます)。通知が送信された後、攻撃者はレスキューファイルを送信しようとする可能性があります。 1日2回まで。したがって、実際のユーザーはプッシュ通知を直接見て直接または数時間後にブロックすることさえできます。
追加された 著者 Mohamed Yaser,
投稿の一番上に私のEDIT 4リンクがあるかもしれませんが、よりよく理解するのに役立ちます。私の説明が十分に明確でないならば申し訳ありません(あなたが見たように、私は英語が堪能ではありません^^)
追加された 著者 Mohamed Yaser,
想像してみてください、ユーザーは承認されたモバイル機器を持っています。攻撃者が中国のデスクトップブラウザから接続しようとすると、中国人の男が電子メールを埋めます。プッシュ通知が今すぐユーザーに送信されます。それから、中国人の男は2つのレスキューファイルを試すことができ、その後1日間IPアドレス/デバイスからブロックされます。しかし、ユーザーの携帯電話で、彼はこの攻撃を見て、X日間、新しいデバイスでレスキューファイルをブロックすることができました。
追加された 著者 Mohamed Yaser,
実際、あなたのDoS攻撃は、ユーザーが認証されたデバイスを持っていない場合にのみ機能する可能性があります。ユーザーが承認された携帯電話を持っている場合、彼はプッシュ通知を受け取ります、彼は新しいデバイスを承認する必要があり、彼は "それは私ではありません"私はすべてのケースを説明するために私の論文を書き終えるつもりです。
追加された 著者 Mohamed Yaser,
すぐにあなたの質問に答えるには: - デバイスの検出は、デバイスの認証時および各ログイン成功後にサーバーから送信されるOTPトークンに基づいています。 OTPなので、スニッフィングでも攻撃には不十分です。 - CRC32または他の何でも、実際には、私達はチェックサムの速いシステムを必要とするだけです。 - あなたは許可されたデバイスを必要とするため、DDoSは機能しません;-)
追加された 著者 Mohamed Yaser,
最初に、@ tangrsにあなたの時間と答えてくれてありがとう。私は現在Mediumに長いポストを書いていて、私がここで少し説明しようとしていることをほとんどの単語/グラフィックで説明します。私は数時間以内にリンクで投稿を更新します。あなたの質問に素早く答えるには:
追加された 著者 Mohamed Yaser,

システムを最初から構築し、それを業界で確立された(そしてしばしば使いやすい)方法と同じくらい良くしようとしているなら、あなたはあなたに先んじる多くの仕事を持っています。パスワードをパスコードに置き換え、安全なCookieやその他のデバイス識別方法を事前共有トークン方式に置き換え、事前共有された書き留めコードまたはTOTPデバイス検証を置き換えることによって、一度に3つのことを置き換えようとする意欲的な功績があります。あなたの回復ファイルで。これらすべてを自分でやろうとすると、パスコードをハッシュする方法、他のシステムがシステムをフィッシングするのを防ぐ方法、ブルートフォースやDoSを緩和する方法、XSSやSQLインジェクション

編集:また、トークンの数を増やして暗号化を追加するような「修正」を提案し続けているので、複雑さを追加しても根本的な問題の大部分を解決できないことに注意してください。これらの問題を解決するための業界標準の方法がいくつかあります。ここで回避し、それらの詳細とその論理的根拠を詳細に理解するまでは、システムに対する「改善」はまだ安全ではない可能性があります。

考慮すべきいくつかの問題は、Gmail with YubikeyやGoogle Authenticatorのような確立された方法ですでに解決されています。

    リカバリファイルをオンラインでバックアップすることは、基本的に他の人に避けようとしている「外部サービス」を提供するように依頼しているため、許容できる解決策ではありません。
  • ユーザーにファイルを選択させ、その後それを保護させることは、あまりユーザーフレンドリーではありません。あなたは基本的にあなたのセキュリティの欠陥を補うために彼らの回復キーを隠すようにユーザに頼んでいます、そしてほとんどのユーザはそれをうまく隠さないでしょう。バックアップ認証方法が必要な場合に備えて、すべてのユーザーが何千もの類似ファイルから完全にランダムにファイルを選択し、それを非ディスクリプタロケーションのクラウドにバックアップし、宗教的に削除および変更から保護するとします。彼らがあなたのためにやる仕事の量をばかげて過大評価しています。

私が使用する単一の攻撃手段を知りたい場合は、最初にプロキシのようなランダムなIPアドレスを偽装し、ファイルバックアップのためにそれらのIPアドレスを認証解除します。最初にデバイスの認証かパスコードをチェックするかは不明ですが、前者の場合は認証要求でスパムを送信するために何百もの電子メールをフォームに入力し、後者の場合は何万ものIPアドレスを試してブロックしますパスコードを入力します。それからこの楽しみの後、私は本当の攻撃を始めます。私はインターネットカフェに立ち寄るか、そうでなければMITM攻撃を仕掛け(通常のようにユーザーが証明書エラーをクリックしたり、DNSポイズニングを使用したり、SSLの脆弱性を悪用したりします)。あなたはブルートフォース攻撃やリプレイ攻撃に対して適切な保護を持っていないので、デバイスID /トークンとパスコードのリプレイ。

編集:上記をたくさん修正しました。詳細はを見てください。

2
追加された
コメントは詳細な議論のためではありません。この会話はチャットに移動しました。
追加された 著者 Rory Alsop,