パスワードに特殊文字を許可しないのはなぜですか？
この場合の原因は、パスワードに特殊文字（あらゆる種類の）を許可しない特定の（そして特に大きな）銀行です：Just [a-Z 1-9]。これを行う正当な理由はありますか？このような貴重な情報を保護するシステムでは特に、このようなパスワードの強度を阻害することは逆効果です。
私が思いついた唯一のことは、SQLインジェクションを阻止するための弱い試みですが、それはパスワードがハッシュされていないことを想定しています（これは確かに本当ではないと思います）。
ここで見たことのない説明の1つは、多くの金融機関は古いシステムと緊密に統合されており、それらのシステムの制限に縛られているということです。
これの皮肉なのは、古いシステムと互換性があるように構築されたシステムを見たことがありますが、古いシステムはなくなったため、古いシステムと互換性があるように構築された新しいシステムとの互換性のためのポリシーが存在する必要があります。
（ここでの教訓は、古いシステムとの互換性が必要な場合は、将来的にこれらの制限を排除できるようにすることです）。
サポート費用はどうですか？誰でも€文字で構成されるパスワードを作成することを許可したとしましょう。万歳、私たちはパスワードに特殊文字を使用することができます。しかし、ちょっと待ってください。携帯電話から銀行にアクセスしたい場合は、いったいどうすればそのパスワードを入力できるのでしょうか。携帯電話よりもキーボードから€を入力する方が簡単です。
休日はどうですか？私たちは英国にいて、英国のキーボードにしかアクセスできません。 €の代わりに、£と簡単に入力できます。ここでは、単語easilyが非常に重要です。一部の平均的なユーザーにとっては、「新しい」キーボードの文字を入力することが問題になる可能性があります。彼はそれをどのように解決しようとしていますか？彼はおそらく銀行サポートに電話して、パスワードを変更するよう依頼するか、why the € character dissapeared from his keyboardに依頼します。
これは、多層防御手段として（弱く）正当化できます。インジェクションまたはその他のデータ解釈バグがある場合、パスワードの文字セットと長さを制限すると、悪用されるのを防ぐことができる場合があります。 7ビットのASCII=文字のみを処理する場合、Unicodeとマルチバイト文字列の処理は無関係であり、単純な実装は一般にバグを含む可能性が低いため、実装も多少簡略化されます。
ただし、この低下したリスクを、パスワード品質の低下によるリスクの増加に対して評価することは簡単ではありません。システムのユーザー数が増えると、侵害される可能性のあるパスワードの数も増えるので、そのようなものを取り除くための投資をすると思いますより価値のある制限。そうは言っても、フィールドが完全に無制限であっても、ほとんどのユーザーのパスワードはひどいものになります。
私の推測では、このポリシーはすべてのユーザー入力フィールドに存在し、同じユーザー入力ポリシー（特殊文字なし）が単純化のためにパスワードを含むフィールドに適用されたと思います。または、ある銀行がパスワードをハッシュしておらず、パスワードフィールドを介してSQLi攻撃を受けていたため、パスワードに特殊文字を含めることができないというポリシーが決定されました（ハッシュが導入されると、ポリシーの理由は忘れられました）。
ハッシュ化されておらず、SQLiやXSS（口座を見る銀行の管理者）などのさまざまな攻撃に使用される可能性がある、他のユーザー入力フィールドに特殊文字を許可しないことには、セキュリティ上の利点があります。ただし、これらの脅威は通常、SQLで常にバインドされたパラメーターを使用し、dbを表示/保存する前に常にユーザー入力をサニタイズすることで解決されます。
他の推測では、他の場所とは異なるカスタムルールが必要なため、標準の強力なパスワード（紛失する可能性があります）を簡単に再利用できず、サイトに固有の何かを考え出す必要があります。
編集：さらに考えてみると、言語に応じて、少なくとも3つの特殊なASCIIの文字を考えることができます。これらの文字は、運命を誘惑するだけなので、禁止/削除する必要があります。具体的に：\0 （null-ascii 0）、これは通常、Cスタイルの言語で文字列の終わりを示すために使用されます（おそらくユーザーは、文字列の終わりの後でメモリを変更します）。キャリッジリターンとラインフィード\r（ascii 13）と\n（ASCII 10）。改行が\r\nまたは\nであるかどうかはシステムに依存し、MacからではなくWindowsからしかログインできないことを避けられないためです。/linux machine。実際、 printable ascii （32-126）のみを許可し、印刷不可のASCII 0-31および127を禁止することは、かなり合理的であるようです。
ただし、特殊文字とは、ユニコードではないASCII文字（,./<>?;':"[]{}\|!@#$%^&*(-=_+など）を意味します。パスワードには小文字のpiが含まれていました。コードポイント0x3c0であるギリシャ語のpi（π）またはコードポイント0x2ca1であるコプト語の小文字pi（ⲡ）でした-1つだけが機能し、異なるコードポイントの同様の文字のこのタイプの問題はunicodeに存在します。ビットを操作するハッシュは2つのπを等しくできないため、異なる場所にログインしようとすると、異なる文字を入力する可能性があります。
同様に、この問題はプログラマーが大部分を制御して修正を試みることができる問題の1つですが、Unicode文字を許可するとエンコードの問題が発生します。これは、基本的なASCII文字の場合、すべてが1バイトの数値で表されます。ただし、Unicodeのエンコード方法にはさまざまなスキームが多数あります。 UTF-7、UTF-8、UTF-16、UTF-32、Latin-1（iso-8859-1）、Latin-Nエンコーディング、および（一部のエンコーディングでは）バイトオーダー（リトルエンディアンまたはビッグエンディアン） ？ pi（0x3c0）のUnicodeコードポイントは、UTF-7では2b 41 38 41 2d、UTF-8ではCF 80、UTF-16ではFF FE c0 03、FF FE 00 00 c0 03 00 00ではバイトとして表されます。 UTF-32。 Latin-1でpiを表すことはできません（印刷可能な余分な文字は95文字のみです）が、パスワードにA1があり、異なるエンコーディングである場合、いずれかからそれを表す必要があるかもしれません次の文字¡ĄĦЁ‘ก”Ḃ（一部のLatin-NではA1になる場合があります）。
はい、ウェブページには文字セットが定義されている場合がありますが、ユーザーはブラウザのページの文字セットを上書きしたり、他の場所から別のエンコードでデータをコピーして貼り付けたりできます。結局のところ、それらの文字を禁止する方が簡単な場合があります。
一般化として、金融機関が長さと文字セットの複雑さを制限する最も一般的な理由は次のとおりです。
（1）Webサービスは、レガシーメインフレームアプリケーションのフロントエンドシステムであり、多くの場合、小文字の英字と数字のみで構成される8文字の制限があります。 「特殊文字」はありません。奇妙なことに、これは最も一般的な制限です。上記のマークバーネットに+1。
（2）それらはパスワードをハッシュしないため、固定長の数値文字列（つまり、ハッシュ出力-32バイトのSHA256（password））を単純に格納することはできません。そのため、入力のサイズを制限することについて心配する必要があります。
（3）SQLインジェクションの脅威ベクトルは、パスワードがクリアテキストとして保存されている場合のパスワードの問題にすぎません。多くの組織やその他の組織は、ハッシュされたパスワード（理想的にはsaltedおよびstretchedPBKDF2などを使用）。
セキュリティよりも簡単なカスタマーサポートパスワードリセットを優先する以外に、ユーザーのデバイスからユーザーパスワードをクリアテキストで送信することに気付いている許容できる理由はありません。あなたは責任を望まないので、決して受け入れないでください。それが暗号化ハッシュの目的です。
以下は、ベストプラクティスのいくつかをまとめ、コードサンプルを含む優れたブログ投稿です。 http://crackstation.net/hashing-security.htm
私は実際に大きなウェブショップに質問しました（bol.com、国際的かどうかはわかりません）。
彼らのアドバイスは、強力なパスワードを使用し、それを頻繁に変更し、文字と数字を使用し、長くする必要があること、そしておそらく他のいくつかのことを忘れることです。とにかく、nobodyという通常のアドバイスに従います。しかし、彼らはパスワードポリシーを気にしているようです。
ただし、ほとんどの特殊文字は使用できません。パスワードの最大長は12文字です。尋ねると、そうでなければ、サポートに連絡する人が多すぎると彼らは私に言った。
「パスワードをお忘れですか？」機能があったため、返事がありませんでした...
したがって、電子メールによる簡単なパスワードのリセットが問題外である銀行にとって、サポート費用が本当に理由だと思います（他の人がここで提案したように）。このbol.comのような他のどのWebサイトについても、パスワードをハッシュ化するかどうかは非常に不信です。データベースでリークが発生した場合は、パスワードが知られるようになるでしょう。
文字セットを英数字に制限すると、スクリプトまたはエクスプロイトが入力検証段階を通過する可能性が制限されます。
ユーザーは長いパスワードを使用することで常にセキュリティを向上させることができますが、アプリケーションには攻撃を防ぐための特定のホワイトリストが必要です。
上記の問題について、プログラマーではなく、UIインターフェイスデザイナーと見なすことができます。ここで重要なのは、ログイン要件はUIインターフェースの設計の問題であり、プログラミングのみの問題ではないということです。
以下に掲載する、ウィンドウサイズに関連する類似の問題を示す優れた本「Apress-プログラマのためのユーザーインターフェースデザイン」があります。
プログラマの一般的な思考パターンは次のとおりです。0、1、nの3つの数字しかありません。 nが許可されている場合、すべてのnの可能性は等しくなります。この思考パターンは、0と1を除いてコードに数値定数を含めるべきではないという古いコーディング規約（おそらくスマート）に由来しています。
今、上記の考え方はプログラミングのみの問題では正しいですが、ユーザーインターフェース、特にWindowsに関係しているため、そうではありません。
しかし、それは真実ではありません。結局のところ、可能性は同じではありません。ウィンドウを画面の最上部に正確に配置する必要があるのには多くの理由があります（画面の領域を最大化します）が、画面の最上部とウィンドウの最上部の間に2ピクセルを残す理由は実際にはありません。 。したがって、実際には、0は2よりもはるかに可能性が高いです。
ここで問題が発生します。理論的には、プログラミングと正式な観点から、すべてのキャラクターが等しく可能かつ等しく許可されているはずですが、ここでもUIインターフェースの問題インスタンスにいるため、これを認識して適切な重みを与える必要があります。
だから私は私の意見では正しい上のスレッドからの答えを言い換えます：
€文字を含むパスワードの作成を誰にでも許可したとしましょう。万歳、私たちはパスワードに特殊文字を使用することができます。しかし、ちょっと待ってください。携帯電話から銀行にアクセスしたい場合、いったいどうすればそのパスワードを入力できるでしょうか。携帯電話からよりもキーボードから€を入力する方が簡単です。
それがユーザビリティの観点からの主要なポイントであり、ユーザーがスマートフォンを使用して数年後、存在しない前の何年も存在していなかったときに、彼が避けるべき文字を使用していることに気付いたとしても、ユーザーのせいにするべきではありません。
この種の問題について考え、ユーザーがそれを回避できるようにすることは私たちの義務です！
パーティーに少し遅れました-私が最近読んだ理由は、この理由は、多くの銀行にとって、これらの文字を許可することによるセキュリティの強化の価値は、パスワードを覚えていない顧客への対処の実装コストとサポートコストを上回っていることです。 。
それが正当な理由だと言っているわけではありませんが、それが私が読んだものを解釈した方法です。