カスタマーサービスで、パスワードでの記号の使用は安全でないと言われたのはなぜですか？
パスワードを忘れたため、最近パスワードをリセットする必要があったオンラインサービスを使用しています。パスワードを変更しようとしたとき、!@£$%^&*()という記号の付いたパスワードを使用したいと思いました。 「パスワードの確認」をクリックすると、「_ Invaid Data」と表示され、最終的には記号が原因であることがわかりました。次に、カスタマーサービスに連絡してこれについて説明し（「_Invalid Data」を「パスワードには文字と数字のみを使用できる」と置き換えます）、彼らは「申し訳ありませんが、導入されたガイドラインはセキュリティのために用意されています対策」。 （これは私のメッセージのように聞こえたものです）
問題は、なぜシンボルがパスワードを安全にするのに、パスワードにシンボルを許可するのは安全でないと彼らが言ったのかということです。
彼らが将来的により良いセキュリティを確保するために、私はそれらを教育し、文字と数字のみで構成される8文字の長いパスワードがある場合、12の記号を含む36^8=2,821,109,907,456の組み合わせが可能になると述べました（!@£$%^&*()_+）、これは48^8=28,179,280,429,056文字を長く許可します。つまり、余分な25,358,170,521,600の組み合わせがあり、この情報をマネージャーに転送しています。
これらの「セキュリティ対策」は、セキュリティのためではなく、セキュリティのためのものです。
ハイフン、アポストロフィ、パーセント記号、アスタリスク、スラッシュ、ピリオドなどの記号は、SQLインジェクション、XPathインジェクション、ファイルパスインジェクションなどの「インジェクション」攻撃を実行する攻撃者に役立ちます。これらの文字をブロックすることにより、サイト所有者は希望する彼らはあなたが彼らのサーバーを攻撃するのを防ぎます。
それらはおそらく、内部的にパラメーター化されたSQLや特殊文字のエスケープを使用するなど、適切なデータ処理により重点を置く必要がありますが、これは、サイトに隠されたコーディングエラーがある場合の一時的なギャップとして役立つ可能性がある追加の手段です。
私は彼らがこれをした理由を明確に答えることはできません。おそらく、「ユーザー入力にはホワイトリストに登録された文字セットを使用し、英数字以外の記号はすべてブロックする」というセキュリティ監査人がいたのかもしれません。おそらく、彼らが購入したWebパッケージにはその制限が付いていたのでしょう。おそらく、セキュリティ担当副社長は、「私たちがセキュリティを真剣に考えているという印象を顧客に与えるいくつかの目に見える手段を追加する」と述べました。誰がその理由を知っていますか？
問題は、なぜシンボルがパスワードを安全にするのに、パスワードにシンボルを許可するのは安全でないと彼らが言ったのかということです。
特定のルールが設定された理由について手がかりがなく、過去にこの言い訳を使用して結果を得たか、頭の中でそれを作り上げて結論に至ったカスタマーサービスの担当者と取引していた可能性が高いこれにより、相手が質問するのではなく、問題を解決できるようになります。
あなたの説明は、文字、大文字、小文字、数字だけでなく記号を追加することによって、パスワードの複雑さが非常に安全になることについて正しいです。
トレーニングを積んでいないカスタマーサービス担当者が仕事を簡単にしようとしているのか、ポリシーに欠陥があり、この会話をできるだけ短くしたいと思っているので、これを書き留めます。
parameterized query および output sanitation ではなく、 input sanitation を使用しているためです。
パラメータ化されたクエリがあった場合、これは問題にはなりません。 output をサニタイズする方法を知っていれば、これは問題にはなりません。
おそらく、彼らのコードは nicode-based smuggling のような他の多くのものに対して脆弱です。多くの「安全な開発者」にとって、入力衛生は入力からアポストロフィを取り除くだけであり、これは信じられないほどひどいアプローチです。
これは、Unicodeベースの密輸を防止するものではなく、データベース内のアポストロフィの正当な目的（人の名前など）を妨害します。データベースで誰かの姓を検索しようとしているが、アポストロフィがあるため検索できない場合を想像してみてください。それはばかげています。
正しい解決策は次のとおりです：入力検証（null>長さ>フォーマット>ホワイトリスト）**> **パラメーター化されたクエリ> 出力サニテーション （XSSを回避するため）、おそらくフォローしていません。適切なデータを除外する正当な理由はありません。
シンボルを許可するとセキュリティが強化されるという分析に同意しますが、一般的にはそれほど多くはありません。特に、少し長いパスワードを使用する場合と比較すると（パスワードが完全にランダムに選択された記号であると想定）。 95の印刷可能なASCII文字のいずれかを使用：
0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ!"#$%&\'()*+,-./:;<=>?@[\\]^_`{|} ~
（タブや改行などの文字を印刷可能として数えると、さらに数文字）8文字のパスワードには95 ^ 8〜6.6 x 10 ^ 15の可能性がありますが、（大文字と小文字を区別する）文字と数字のみの場合、8文字のパスワードには62 ^があります8〜2.2 x 10 ^ 14で、約30倍弱くなります。
ただし、数字+小文字+大文字のみの9文字のパスワードは、特殊文字を使用できる8文字のパスワードより2倍強力です。したがって、パスワードの長さに厳しい制限がない限り（そして、実際には少なくとも数百文字未満のパスワードである必要はありません）、文字セットが制限されていても、少し長いパスワードに簡単に移行できます。
セキュリティ上の最大の懸念事項は、パスワードに特殊文字を許可すると、アプリケーションまたはデータベースに問題が発生する可能性があると考えている場合です。印刷不可能なASCII文字（例、ASCII制御文字NUL（\0）、バックスペース（\b）など）は問題を引き起こす可能性がありますが、適切に設計されたアプリケーションは、インジェクション攻撃に対して脆弱ではなく、'や-などの通常の特殊文字を処理できる必要があります。アプリケーションは、これらのタイプの文字は、たとえば引用符やハイフンが含まれている名前（たとえば、Conan O'Brien、Daniel Day-Lewis）に表示されるとおりに処理します。さらに、パスワードをデータベースに保存したり、データベースに返したりしないでください。ユーザーとすぐにハッシュ化され、印刷可能なASCII特殊文字は許可されません。
Unicodeのような非ASCIIの特殊文字にはいくつかのユーザビリティの問題があることは当然ですが、ユーザビリティの問題については、これらの文字を禁止するか、標準的な方法で正規化することをお勧めします。ハッシュ関数は通常、バイトの文字列を期待し、ASCIIを超える特殊文字を含むパスワードは、バイトレベルでさまざまな方法でエンコードできます（UTF-8、UTF-7、UTF-16、 ISO-8859-1）。さらに、異なるエンコーディング（アプリケーションレベルで一貫性を保つことができる）に加えて、Unicodeで異なる値を持つ同一の文字に注意する必要があります。たとえば、次の文字Åは nicode 00C5 ですが、これと同じように見える文字はÅ nicode 212B ですが、このÅは実際には2文字です-ascii Aと結合文字 nicode 030a を追加しますA上の円.
[〜＃〜] edit [〜＃〜]：共通のシンボルの1つとして£がリストされていることに気づきました。残念ながら、これは標準ではありませんASCII記号です。ISO-Latin-1では、バイトA3です。UTF-8では、2バイトC2 A3です。UTF-では7これはASCII文字+AKM-です。UTF-16では00 A3です。これらの異なるエンコーディングは、適切に処理されない場合、ハッシュ関数がこの文字で壊れる可能性があることを意味します。確かに、アプリケーションはエンコードを適切に処理できるはずですが、一部のデバイスのサブセットでは失敗する可能性があります。
'や"などの文字には、ユーザビリティの問題があり、一部のアプリケーション/プラットフォームではスマートクォート‘’“”に変換される場合があります（ただし、これはパスワードコンテキストでは行わないでください）。
最後に、一意のパスワードルールを使用するための1つの追加の合理性があります。ユーザーがどこでも再利用される1つの記憶されたパスワードを保持することを困難にします。これは恐ろしいセキュリティ対策です。ユーザーの「通常の」パスワードが1つのサイトの一意のルールを満たしていない場合、通常のパスワードが他のランダムなサイトで侵害された（つまり、パスワードがプレーンテキストで保存されている）場合、そのアカウントは一意のサイトで侵害されません。ルール。
少しだけフェッチされましたが…
たとえば、ジョンの母親がクリスマスにIPadを受け取った後、彼女はラップトップではなくそれを使用して銀行にログインすることに決めましたが、IPadに記号を「入力」する方法を理解することができません。そこで、彼女は誰かに自分のパスワードを入力する方法を見せてくれるよう頼みます…..
さて、サポートの問題について考えてみてください顧客は、携帯電話やタブレットで「入力」する方法がわからないパスワードを持っています。パスワードのリセットを要求する多くのサポートコールは、セキュリティの問題であると同時にコストの問題です。
一部の記号は、操作するすべてのキーボードレイアウトで使用できない場合があります。これはログインできなくなります。これは、セキュリティではなく、可用性の問題になります。
ただし、問題の記号が、使い慣れていないキーボードレイアウトで使用できるが、慣れ親しんだ位置にない場合、これはセキュリティのわずかな問題になる可能性があります。その場合、パスワードフィールドに入力する前に正しいキーを見つける必要があるかもしれません。そして（特に一致するキー配列がない場合）、検索した記号が表示されるまで、エディターに記号を入力することが考えられます。そこに立ち止まると、エディターを一目見た人（入力中または後で閉じるのを忘れたため）は、パスワードに含まれている記号の少なくとも1つを知っています。
私は同意する必要があります Eddie Studerの回答 ：遠くにあるセキュリティへの影響はありますが、これについてあなたに話した人がそのポリシーの背後にある本当の理由について手がかりを持っていなかった可能性があります。ただし、ユーザーがログインできないなど、前に述べた可用性の問題であった可能性があります。海外のインターネットカフェから。これらはまだ非常にありそうな理由ですが、他のほとんどの回答によって表明された注入の懸念に対する1つの代替案を提供するためだけに。
ほとんどの人は、速度を落として一度に複数のキーを押さないと記号を入力できません。そのため、人間が目にする可能性のある場所に入力しようとすると、セキュリティが少し低下します。
あなたの議論は：
1。記号を使用してランダムに生成されたパスワードは、文字と数字のみを使用して同じ長さでランダムに生成されたパスワードよりも強力です。
2。したがって、パスワードに記号を使用できるようにすると、より強力になります。
これは、人々がランダムにパスワードを生成する場合にのみ有効です。
ただし、次のアルゴリズムで作成されたパスワードを比較してみましょう。
1。最大長のパスワードを作成-1数字と文字
2。末尾に記号を貼る
記号の数が文字と数字の数よりも少ないと仮定すると、これは、文字と数字だけのランダムなパスワードよりも弱いパスワードを生成し、さらに、誤った安心感を提供します（ `パスワードではなく、パスワード$に設定します！）。文字を記号などで置き換えることにより、パスワードを生成するために同様の議論をすることができます。
したがって、人々がpa$$Wordの代わりにランダム/長いパスワードを使用することを選択することを期待して、彼らがシンボルを許可しないことを決定するかもしれません。もちろん、これは文字+数字+記号でランダムなパスワードを使用したいユーザーを「傷つけます」。ただし、これらのユーザーは、数文字を追加するだけで十分な教育を受け、同等の長さのパスワードが得られると予想します（長さに制限がない場合）。
結局のところ、記号をsomeパスワードに含めると強度が高まるため、人々が記号を使用できるようにすると、平均的なパスワードの強度が高まるというわけではありません。
XML/Json仮説：
パスワードがWebサービスに（できれば安全なチャネルを介して）送信され、特殊文字が無効なXMLまたはJsonになることがわかった可能性があります。エンティティをエスケープする代わりに、すべてのシンボルを制限しました。
1つのセキュリティ問題は、XMLでエスケープ文字 "と\"Jsonでは、XML/Jsonは、CDATAまたはエスケープなしの文字列連結によって構築されます。文字列で一重引用符と二重引用符をチェックした場合でも、フィールドの引用符で終了する場合があります。
もちろん、解決策は、外部パラメーターを使用してクエリを構築するための文字列連結を回避することです。
PS：パスワードもLDAPに送信される可能性があり、 LDAPインジェクション
自分のセキュリティの代わりに、大文字、小文字、数字、特殊文字を含むパスワードを覚えておかなければならないことを想像してみてください。彼らのために行く人のほとんどは、おそらくログインと一緒に、そのパスワードを紙に書いて、考えられます。高いセキュリティリスク
そして、覚えやすいシンプルなパスワードを使用すると、パスワードが漏洩する可能性がはるかに低くなります
もちろん、このようにして、パスワードマネージャーで複雑なパスワードを使用する機能をブロックします。紙よりも安全なソリューションですが、パスワードやパスフレーズを覚えておくよりも安全性は低いと思います。
しかし、合理的な理由があるのか、それともシステムや管理に欠陥があるのかを判断することは、関係者でないと不可能です
特にキーボードのレイアウトやよく知らないデバイスでは、入力が難しい可能性があるため、パスワードに記号を使用することは避けます。
また、さらに重要なことに、すべてのソフトウェア開発者を信頼しているわけではありません。かつて、スペースを含むパスワードを使用していました。一部のサービスは、後で認証方法を変更して、パスワードから空白を削除しました。これにより、ログインできなくなりました。
特に、ASCII以外の記号を検討する場合、他の記号でも同様のことが発生する可能性があるのではないかと恐れています。ちなみに、カスタマーサービスが特別なシンボルの使用を推奨していないという事実は、それらが信頼されるべきではなく、奇妙なことをする可能性があることを強く示しています（現在または将来）。
結局のところ、数字について考える場合、記号を使用することは、英数字のパスワードにいくつかの文字を追加することと大差ありません。
- 100シンボル（すべてASCII印刷可能文字）、長さ8：1008 組み合わせ;
- 62記号（ASCII文字と数字）、長さ9：629 100を超える組み合わせ8。
より多くのシンボルを使用することは役立ちますが、長さを増やす方がはるかに優れています（kバツ xより速く成長するk）。
ただし、パスワードとユーザー名の両方で、文字の制限はかなり一般的です。
安全なコンピューティングでは、攻撃面、脆弱性、悪用と呼ばれるものがあります。分離は信頼性です。
はい、より多くのキャラクターはよりランダムですが、攻撃面も大きくなります。
限られた文字セットで十分にランダムなパスワードを作成できます。 36 ^ 8 = 2,821,109,907,456は、ほとんどのセキュリティニーズに対して十分にランダムです。そうでない場合は、10または12文字に増やします。あなたは彼らがランダムな文字を使用することを望みます。脆弱性にはFistNameLastNaveYYMMDDと推測できるパスワードがあります。YYMMDDは生年月日です。
一部のUnicode文字は同じように見えます。分音記号を別のキャラクターとして作成できます。これらの文字は同じではありません：ギリシャ語Ο、ラテン語O、キリル文字О。
コンピュータの文字セット（コードページ）によっては、実際に異なるマッピングが得られる場合があります。このアイデアは、文字セット全体での確定的な文字の安全なセットです。
HTMLエンコーディング、ネットワーク上の圧縮、ソルティングなどを考慮する必要があります。制御文字についてはどうですか？
どこかに線を引く必要がありますが、実際には、十分にランダムなパスワードを作成するために大きな文字セットは必要ありません。
これは、プログラマが怠惰であったり、不十分であったりすることについてではありません。信頼性の高い確実なコードを提供することです。制御された文字セットを使用すると、すべての可能性をより適切にテストできます。送信中に奇妙なことが起こった場合、何がそれを壊しているかを理解するための小さなテストセットがあります。
@dr jimbobが言ったように、パスワード!@£$%^&*()に印刷できない文字£を使用しています。印刷不可能な文字_£_をパスワードから削除すると、サービスが何であっても受け入れられます。これは、高度なセキュリティを維持するために、コアレベルでパスワード暗号化がcまたはJava=で開発されたためです。
非技術者に印刷不可能な文字を理解させることは困難です。そのため、カスタマーケアエグゼクティブは、特殊文字ではなく単純な英数字を使用するように依頼しました。
!@$%^&*()で新しいパスワードを試してください。オンラインで公開されたので、テスト後にパスワードを変更してください。
単純に言えば、受け入れられる文字は ASCII 32から126 の間です。
この特定のシーケンスはただ押し続けています SHIFT ハッカーにとっては簡単であり、多くの人がこれを行うため、この特定のシーケンスは許可されていないと想定しています。たとえば、Shiftキーを押しながらキーボードの左側を下に移動しているだけなので、安全ではないパスワードにQWERASDFZXCVが使用されるのを見てきました。