UXの観点から見ると、CAPTCHAは悪い、悪い、悪い。
しかし、これを要件として持っているとしましょう。ハイブリッドアプリ(コンパイル済みアプリですが、HTML5プラットフォームに基づいて構築されています)用です。
私は見つけようとしています:
ボットが実際にフォームを自動的に送信できるかどうかという質問に関して、これは Stack Overflowの回答 で見つけたものです。
ネイティブアプリ内でデータ送信を自動化することは比較的困難です。これは、ソースコード内の要素を検出してフォームの送信を模倣するための自動スクリプトを作成することはできないためです。また、アプリケーションを(購入して)インストールする必要があります(物理デバイスまたはシミュレーターに)。
とはいえ、コメントの1つは、フォームの送信がモバイルではるかに簡単であることを実際に示唆しています。
モバイルアプリは通常、REST API(または他の明確に定義されたAPI))とやり取りするため、スクレイパーを必要としないため、はるかに簡単です。
だからあなたの質問に関して私はCAPTCHAが必要かどうかについて明確な答えはまだありません。
とはいえ、モバイルデバイスのCAPTCHAに関しては、いくつかの興味深いアプローチが提案されています。
スライダーCAPTCHA:Luke Wroblewskiは、スライダーCAPTCHAを使用して、人間の操作を取り入れ、コンテンツの自動送信を防ぐことをお勧めします。 article を引用するには:
最近のCAPTCHAのほとんどを代表する歪んだテキスト文字列(上記)の代わりに、They Make Appsのサインアップフォームは、ユーザーに次のように尋ねるスライダーを使用します:「私たちにあなたの人間の側面を見せてください。アカウント。"スライダーを右に移動すると、フォームが完全に送信され、標準の[送信]ボタンと同じようにエラー検証がトリガーされます。
上記のオプションはWebベースのソリューションですが、簡単なスライド操作はモバイルパラダイムに適合し、デザインにも適合します。
MotionCAPTCHA:私が見つけた別のオプションでは、CAPTCHAを完了するためにユーザーが画面上のパスをトレースする必要があります。記事を引用するには:
MotionCAPTCHAは、HTML5 Canvasに基づくjQuery CAPTCHAプラグインです。ユーザーがフォームを送信するには、キャンバスに表示される形状をスケッチする必要があります。これは、モバイルキャプチャの素晴らしい代替手段になる可能性があります。モバイルユーザーは、これらの小さな数字を入力する必要がないことをきっと認めます。
NuCaptcha:NuCaptchaは、従来のCAPTCHAモデルを使用する別のオプションですが、モバイルデバイス用に最適化されています。これを引用するには TechCrunch 記事:
NuCaptchaのモバイルバージョンには、Webバージョンと同じシンプルさが含まれています。しかし、新しく最適化されたモバイルキャプチャは、複数のデバイスで一貫したユーザーエクスペリエンスを提供します。たとえば、ユーザーがモバイルタッチスクリーンをクリックしてキャプチャを解くと、キーボードによって残されたスペースに完全に収まるため、キャプチャをすばやく簡単に完了することができます。 NuCaptchaはFlashまたはJavaScriptを必要としません。同社は、2011年第4四半期の初めにCaptchaテクノロジーのHTML5モバイルバージョンをリリースする予定です。
とは言え、これらのオプションのいずれも、CAPTCHAブレーカーとして支払われた人間を妨げることはありません。
Snapchatは最近画像認識を追加しました:
( http://venturebeat.com/2014/01/22/snapchat-find-the-ghost/ )
注意:
ほとんどのキャプチャと同様に、これも壊れやすいものです。
しかし、あなたのアプリが人気のターゲットになるまで、これはかなり素晴らしい代替手段です;-)
ユーザーに質問に答えたり、正しい写真を選択したり、何かを入力したりするのではなく、通常のテキストフィールドからdeleteを入力するだけです。
少なくとも実装の観点からは、これは簡単なことではありません!
賛成された答えのほとんどの例を使用しないでください。それらは、広範囲の障害を持つ人々を完全に除外します(あなたが盲目である場合、画像認識は役に立たず、自閉症である場合、比喩的な関連付けは役に立たず、数学の質問は役に立たない場合、計算不可能など)、そして彼らはまた、捕獲農場で働く人間の問題を取り除くために何もしません。
基本的に、検証にコンテンツとは異なるタイプのスキルが必要な場合、不必要に人を除外しています。
この不利な点のない他の方法があります。たとえば、askismet、ハニーポット、または本当に人々がフープを飛び越えようとする何かがある場合は、SMS検証。
サイトのセキュリティ問題をユーザーに修正する責任を完全にオフロードすることに専念している場合は、少なくともユーザーに選択肢を提供してください。そして、私はreCAPTCHAに見られるような極端な「オーディオ」バージョンを意味しません(reCAPTCHAは見落としているようです)視覚障害の最も一般的な理由である老年もしばしば聴覚障害を引き起こすという事実)。したがって、複数のキャプチャを提供し、人々が簡単な質問に答えるか、画像を認識するかなどを選択できるようにします。
あるいは、一部の企業のように、セキュリティの問題を自分の問題として受け入れ、ユーザー側の保護の試みを省略して、その影響を受け入れることもできます。
IPhone(またはAndroidデバイス))からのボットトラフィックは実際に問題ですか?
問題はそれほど「iPhoneから」ではなく、話しているAPIも保護する必要があるということです。基礎となるIPレベルでは、リモートデバイスが何であるかを証明するためにできることはあまりありません。HTTPの場合、これは実際にはヘッダーまたはフォームデータにすぎず、ボットが簡単に生成できます。つまり、私はあなたのUXが何であるかを気にしません、私はあなたのAPIを直接攻撃します。
ネイティブアプリについて具体的に質問しているため、プログラマーのような問題へのアプローチではユーザーは関与せず、送信前に公開鍵/秘密鍵スキームを使用してペイロードを暗号化します。アプリにのみキーがあるため、APIを直接攻撃するボットは阻止されます。 SSLを使用するだけでなく、送信前にペイロードを暗号化することを意味することに注意してください(これは実際にアプリケーションを認証するのではなく、処理中のデータを保護します)。
もちろん、アプリにキーを埋め込む際の問題は、アプリもリバースエンジニアリングできることです。
セキュリティの低いアプリには、数百のキーワードのテーブルがあり、これらのいくつかをhttpフォームリクエストで送信するにはアプリ(多くの場合htmlハイブリッド)が必要です。どちらを選択するかは、クライアントとサーバーの両方が知っているアルゴリズムを使用して、現在の日付に基づいています。その後、sslを使用して送信されます。完璧ではありませんが、アプリのリバースエンジニアリングにオープンですが、実装するのに十分シンプルです。
セキュリティの高いアプリでは、デバイス固有のキーを共通のテーブルではなくすべてのデバイスに保存し、サーバーはすべてのキーの使用を注意深く監視/追跡します。もちろん、これは大量に配信されるアプリには現実的ではありません。
ハニーポットフィールドを使用できます。
それらは、ユーザーからは隠されているが、任意のボットが気づいて入力するように設計されたフォーム内のフィールドを提供します。
それらは、cssで非表示にされた「phone_number」と呼ばれるフィールドと同じくらい単純にすることができます。ボットはcssを処理せず、フィールドを表示しますが、ユーザーは処理しません。
これはデスクトップとモバイルの両方で機能し、かなり長い間流通しています。
アクセシビリティの懸念をカバーするコメントを含むいくつかの詳細: http://haacked.com/archive/2007/09/11/honeypot-captcha.aspx/
ここでSmashing Magazineはこれをより詳細に概説し、他のいくつかのCaptchaメソッドを扱います:
http://coding.smashingmagazine.com/2011/03/04/in-search-of-the-perfect-captcha/
彼らはまた、ソーシャルログイン、画像認識、友人認識を他のより近代的な方法として挙げています。これらはすべて、モバイルでうまく実装でき、ハニーポットが従来のWebフォームCaptchasに次ぐ最も人気のある選択肢であることを投票で示しています。
PSハニーポットフィールドは実際にはCAPTCHAでもあり、これは「完全自動化されたパブリックチューリングテスト」の略です。この原則について学ぶことは、根底にあるアイデアの一般的な理解に役立ちます。
HTML5について説明していただいたので、私はハニーポットアプローチの大ファンです。ほとんどのユーザーは、それが存在することすら知らないでしょう。送信時にサーバー側で検証する必要がある次の4つの入力フィールドをすべて使用します。
必須フィールドは既に入力されている必要があります。nullにする必要があるフィールドには、「連絡先番号」など、クリエイティブな名前を付ける必要があります。すでに使用されている入力名を使用しないように注意してください!
ユーザーがCSSまたはJavaScriptを無効にしている場合は、「このフィールドをそのままにする」または「このフィールドを空白のままにする」など、送信を成功させるために何が必要かを説明する必要があります。
注意: これらは見えない場所にある必要がありますが、ブラウザから完全に隠されているわけではありません。そうでなければ、登録もされません。徹底的にテストしてください!
個人的には、CAPTCHAの簡単な数式を大々的に支持しています。たとえば、フォームの最後にフィールドセットがあるとします。
What is 1+5?
[_____________]
2つの数値をランダムに生成させます。この方法では、スパム/ボットフォームの送信が大幅に減少しました。これらのボットには、これらの方程式を認識して解決するプログラミングがないかのようです。おそらく、彼らがWordベースのキャプチャを解決するのに慣れている/プログラムされているためです。
さらに、ユーザーエクスペリエンスの見通しから、これらは私が遭遇した最も簡単なキャプチャの形式です。シンプルで難しいことではありません。また、HTML/CSSでのコーディング/スケーリング(レスポンシブデザイン)も簡単です。
私は開発者ではないので、セキュリティ上の懸念(ある場合)はわかりませんが、ユーザーにタッチ入力で応答させるとどうなりますか?たとえば、ユーザーにボックスを3回タップさせたり、単純にスワイプしたりできます。ユーザーに形状を描画させることもできます: http://www.josscrowcroft.com/projects/motioncaptcha-jquery-plugin/
必要ですか?
第一に、アプリに埋め込まれたHTMLコード内でのみ宣言されているURLへの「ボット」トラフィックが多くなるとは信じられません。スパムボットの主な目的は、他のサイトへのリンクを植えることです。それ自体がインデックスに登録されていないページでそれを行うことはあまり意味がなく、コンテンツに影響を与えないフォームではまったく意味がありません。
アプリを分解したり、リクエストを傍受したりすることは可能ですが、情報から作成されたボットには何らかの目的が必要になります。単にサーバーをトラフィックでいっぱいにすることが目的である場合は、不適切なCAPTCHAデータを十分な頻度で送信するだけで十分です。何を保護しようとしているのかがわからないため、CAPTCHAが必要かどうかはわかりません。
モバイル中心の代替
CAPTCHAの唯一の既知の目的は、仕様草案作成者からのロボットの要求に準拠することであるため、十分に確実なCAPTCHAは次のテキストの指示になります。
Please hold your device in your left hand.
誰もが知っているように、コンピューターには手がなく、常に指示に従うので、これに直面すると、おそらく自己破壊か何かが好きになるでしょう。理にかなう。
(デスクトップは通常片手では持てないので、これはモバイル中心です。)
このテキストは、代替のCAPTCHAのすべてのキーボックスを本当にチェックしています。
ここにある他の答えと同じように、コンピューターには指がないために滑りやすいものがあります。
この拡張バージョンは、特に読みにくいフォントのぼやけた画像にWord left
を配置して、目を潤す色の組み合わせで表示することです。
ユーザーを認証するためにNoMoreCaptchas.comを試すことができます。これは、BioChronometricsと呼ばれる新しいタイプのテクノロジーで行われます。これは、ユーザーの行動に基づいてすべてユーザーに対して受動的です。
非常にシンプルなアプローチで本番環境で機能したのはチェックボックスを追加フィールドで、属性type = "hidden"ではなくスタイル定義(CSS)によって非表示にされていました。
フィールドが送信時にチェックされる場合、ユーザーがフォームを送信しない場合、ロボットがフィールドをチェックする可能性が高くなります。
このソリューションは100%安全ではありませんが、実装が非常に簡単で、効果的でより重要です。ユーザーフレンドリーです!
0から10までの2つの乱数を生成し、それらの数値の合計をユーザーに尋ねるのはどうでしょう。
まず、APIを保護するために、WebサーバーのIPアドレス/ローカルネットワークIP範囲(開発者や他のマシンがアクセスを必要とする場合)からのAPIのIPアドレスとポートへの接続のみを許可する新しいインバウンドルールをファイアウォールに追加します。同じマシンでホストされています。もちろん、これはAPIに一意のポートを割り当てる必要があることを意味しますが、APIが公開されていなくても問題にはなりません。これにより、ボットがAPIに直接リクエストすることを防ぎます。
次に、FacebookまたはGoogleの確認をサインアッププロセスに追加します。これは、将来実装されるCaptchaソリューションのメリットを自動的に享受できることを意味します。また、ユーザーは別のパスワードを覚える必要がないため、ユーザーにとっては素晴らしいことです。
Captchaは非常に痛くて時々読みづらく、上記のコメントから判断すると、努力する価値はありません。
オプションの1つは、現在の携帯電話番号を入力するようにユーザーに要求し、[〜#〜] otp [〜#〜]を指定された番号に送信して、それを自動的に読み取る(ユーザーが同じものを手動で入力することを許可しないでください)。
音声認識に関連する技術が許容可能なレベルに進化した場合、それはタッチ入力CAPTCHAの真の代替手段となります。悲しいことに言うと、カピルチャリルマダティルスらの調査結果を読むと、まだ十分ではありません。 al。記事 音声とタッチ入力を備えたモバイルデバイスでのCAPTCHAの使いやすさの評価 。彼らはそれを結論付けます...
結果は、少なくとも現在のDragon Mobile SDK音声認識ソフトウェアを使用している場合、ユーザーが音声でCAPTCHAを完了することに満足していない可能性があることを示しています。ちなみに、Siri-iPhone用に開発された音声認識アプリケーションおよびパーソナルアシスタント-)は、この調査の時点では使用できませんでした。また、コンフィデントタッチは、モバイルデバイス。このCAPTCHAのもう1つの利点は、Webページとモバイル画面で使用するスペースセーバーのバージョンが少ないことです。全体的に、この結果は、可能な場合は画像ベースのCAPTCHAの使用をサポートしています。 GoogleのCAPTCHAで歪んだ文字を認識しようとするとイライラしたように見え、オンラインで遭遇した同様のテキストベースのCAPTCHAでの不満についても言及した人がいました。
しかし、この世界では状況が急速に変化しており、Siriがテストされていなかったという事実は、音声認識のCAPTCHAの将来に希望をもたらします。それまでは、画像ベースのCAPTCHAが最良の選択肢です。
iPhone(またはAndroidデバイス)からのボットトラフィックは実際に問題ですか?
はい、とにかく、スパマーが正しく処理した場合、サーバーはPCからのトラフィックとスマートフォンからのトラフィックを分離できません。
もしそうなら、まだ別の厄介なCAPTCHAよりもモバイル中心のより良い代替案はありますか?
キャプチャに代わるものはありません。
別の答えでリンクされた 概念 のようなものは、キャプチャとはまったく比較できません。強力なパスワードハッシュは難読化するため、Captchaはこの種のソリューションです。いくつかのリバースエンジニアリングスキルがあれば、誰でもそれを破ることができます。
Captcha(ビジュアルまたはオーディオ)は、今日のコンピューターの限られた能力に依存しているため、画像や音声の認識における機能が制限されています。他のソリューションは、スパマーが愚かすぎて正しいスパムボットを作成できないという事実に単に依存しています。