アカウント名:
パスワード:
いまだに12文字制限のあるとこ（ゆうちょとか）、さらに8文字制限のクレジットカード系とかほんと勘弁してほしい。
記号入力必須なのに、特定の記号以外は入力制限がある(いまどき、SQL文でも直書きしてるの？)とかもやめてほしい。
たいていの文字がunicodeな時代なのに「ASCIIにマップされてる記号のみ有効」もけっこう理不尽だし、かといってunicodeに採用された文字なら全部OKにするも非現実的。英数字のみというのは人間にもわかりやすい上に入力端末などの言語環境に左右されずに済むというよさがある。
逆に「絵文字のみのパスワード」も面白いかも。英数字よりもバリエーションが多く、辞書攻撃用の辞書も作りにくい。
# デメリットも割とあるのでエイプリルフールネタ向きかな
Webアプリケーションファイアウォールってのがあってだな、記号有りにして、例えば「t' OR 't' = 't」みたいなパスワード使われてしまうと誤検出が発生してしまう。
誤検出を防ぐには、当該ページ（例えば login.php への POST）に対してWebアプリケーションファイアウォールを無効にするしかなくなる。すると、万が一SQLインジェクションとかOSコマンドインジェクションとかの脆弱性があっても、Webアプリケーションファイアウォールが作動しなくなってしまう。
なので、
・Webアプリケーションファイアウォールによって脆弱性があった場合にも悪用を防げる（場合がある）ことのメリット・記号を入れた分、ユーザのパスワードが強固になることのメリット
のどちらかを天秤にかけることになる
パスワードに記号を禁止してもユーザは強固なパスワードを指定することは可能（その分長くすればいいだけ）だし特定のユーザのパスワードが破られてもシステム全体には影響しないし会社としてのダメージは少ないしかし、SQLインジェクションでもされたら会社は大損害でイメージもがた落ち
なので、金融系とかクレジットカード系など、安全性が重視されるシステムほど、パスワードへの記号の使用は禁止して、Webアプリケーションファイアウォールで安全性を担保している
金融系とかクレジットカード系など、安全性が重視されるシステムほど、クライアントサイドでのハッシュとか、説明が難解な方法が拒絶されて、セキュリティが低下しがち…?
> クライアントサイドでのハッシュそんなことの為にJavaScript必須にするのはやめてくれ
そういうことされるとパスワードマネージャの種類やバージョンによっては自動入力やログインが上手くいかなくなって不便なんだよね。
SQL-INJやXSSなんて当然セキュリティ会社にチェックしてもらうでしょうせいぜい禁止記号縛りならわかるけど長々と何コメントしてんだか
何言ってんだこいつ。そんな本末転倒な代物に頼らざるをえない時点でそのシステムダメだろ。だいたいSQLインジェクションっていうが、その程度だと悪意ある入力はともかく、普通の入力だって記号関係がダメになってるってことだぞ。そんなの脆弱性以前の問題だっての。もっと、こう文字コード由来のインジェクションを防ぐってFWならともかくさ。当然そんな誤検出なんてありえん。
この長文はプレースホルダやせめてエスケープ処理を知らない昔の人ですか？
「ファイヤウォールがSQLインジェクション攻撃と誤認してアクセスをブロックしてしまう」ことを問題にしているのであって、ウェブアプリがSQLインジェクション対策されてるかどうかは無関係。
別のコメントみたいに「そんなファイヤウォールに頼るな」というツッコミは正当だけど、プレースホルダとかエスケープ処理とか「SQLインジェクション対策しろ」というコメントはまったくの的外れ。
WAFって今時どこでも使ってる気がするけど、金融系でだけそんな問題が発生するの? それは金融系のセキュリティが甘いってことじゃないの?
金融系は真っ先にWAF入れた真っ先に入れたからチャチかったので先のようなことになったそれに対応するためのバッドノウハウも必要だった
東京都心の地下鉄駅が狭くてぼろいようなもん
WAF知ってるけど、だからなに？
出来の悪いWAFのために、ユーザー側を制限しますって馬鹿？
安全性が重視されるシステムほど、認証用のデータベース（およびページ）とそれ以外を切り離したほうがいいに決まっているじゃない。設計ミスを他人のせいにするのはやめましょう。
SQLインジェクションはSQL発行する段階で防止すればいい話じゃないの？結局そのファイアウォールをあてにした杜撰なプログラムになったりページによって例外的にそのファイアウォールを無効にするとかややこしい実装になったりでかえってセキュリティが低下するような気がするんだけど。
サマータイムの話でたくさんいた「テストしてないから保証できない」「発注元が値切るから仕方がない」ってやつじゃない？
激しく同意。仕様を無駄に複雑にする必用なぞどこにもない。99.99％動くからといって、テストがなくなるわけじゃないし、将来実装が変更されない保証もない。
仕様を無駄に複雑にして、工数を増やして現場を疲弊させる経営者や政治家は大馬鹿者だと、ハッキリ言っておきたい。
それに一度でも公開された仕様は、あとで不具合がでたからと言って簡単には変更できない。特にパスワード系は厄介。
「英数記号を必ず1文字使用すること(ただし使用できる記号は...)」と(中途半端に)記号を入力できる＋記号は必ず使用しなければならないという時点で、無駄に複雑とはならないのですか？
> 仕様を無駄に複雑にする必用なぞどこにもない。
サマータイムについて、制度導入により、政治的・ビジネス的には別として、システム稼働上不必要な仕様の複雑化が発生することには同意。パスワードに記号を認める(多分@とか`とかのことかと)ことについては、仕様の複雑化はシステム稼働上不必要とは思わないし、そもそも複雑化にはつながらない。
むしろキッチリと対応していた方が、将来的にバグが発生する可能性が減る。それこそどこかにSQLを直打ちしている所でもあったりしたりで。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
一つのことを行い、またそれをうまくやるプログラムを書け -- Malcolm Douglas McIlroy
文字数制限 (スコア:1)
いまだに12文字制限のあるとこ（ゆうちょとか）、さらに8文字制限のクレジットカード系とかほんと勘弁してほしい。
Re:文字数制限 (スコア:0)
記号入力必須なのに、特定の記号以外は入力制限がある
(いまどき、SQL文でも直書きしてるの？)とかもやめてほしい。
Re:文字数制限 (スコア:2, 興味深い)
たいていの文字がunicodeな時代なのに「ASCIIにマップされてる記号のみ有効」もけっこう理不尽だし、かといってunicodeに採用された文字なら全部OKにするも非現実的。
英数字のみというのは人間にもわかりやすい上に入力端末などの言語環境に左右されずに済むというよさがある。
うじゃうじゃ
Re:文字数制限 (スコア:2)
逆に「絵文字のみのパスワード」も面白いかも。英数字よりもバリエーションが多く、辞書攻撃用の辞書も作りにくい。
# デメリットも割とあるのでエイプリルフールネタ向きかな
Webアプリケーションファイアウォールを知らないの？ (スコア:1)
Webアプリケーションファイアウォールってのがあってだな、
記号有りにして、例えば「t' OR 't' = 't」みたいなパスワード使われてしまうと誤検出が発生してしまう。
誤検出を防ぐには、当該ページ（例えば login.php への POST）に対してWebアプリケーションファイアウォールを無効にするしかなくなる。
すると、万が一SQLインジェクションとかOSコマンドインジェクションとかの脆弱性があっても、Webアプリケーションファイアウォールが作動しなくなってしまう。
なので、
・Webアプリケーションファイアウォールによって脆弱性があった場合にも悪用を防げる（場合がある）ことのメリット
・記号を入れた分、ユーザのパスワードが強固になることのメリット
のどちらかを天秤にかけることになる
パスワードに記号を禁止してもユーザは強固なパスワードを指定することは可能（その分長くすればいいだけ）だし特定のユーザのパスワードが破られてもシステム全体には影響しないし会社としてのダメージは少ない
しかし、SQLインジェクションでもされたら会社は大損害でイメージもがた落ち
なので、金融系とかクレジットカード系など、安全性が重視されるシステムほど、パスワードへの記号の使用は禁止して、Webアプリケーションファイアウォールで安全性を担保している
Re: (スコア:0)
金融系とかクレジットカード系など、安全性が重視されるシステムほど、クライアントサイドでのハッシュとか、説明が難解な方法が拒絶されて、セキュリティが低下しがち…?
Re: (スコア:0)
> クライアントサイドでのハッシュ
そんなことの為にJavaScript必須にするのはやめてくれ
Re: (スコア:0)
そういうことされるとパスワードマネージャの種類やバージョンによっては自動入力やログインが上手くいかなくなって不便なんだよね。
Re: (スコア:0)
SQL-INJやXSSなんて当然セキュリティ会社にチェックしてもらうでしょう
せいぜい禁止記号縛りならわかるけど長々と何コメントしてんだか
Re: (スコア:0)
何言ってんだこいつ。
そんな本末転倒な代物に頼らざるをえない時点でそのシステムダメだろ。
だいたいSQLインジェクションっていうが、その程度だと悪意ある入力はともかく、普通の入力だって記号関係がダメになってるってことだぞ。
そんなの脆弱性以前の問題だっての。
もっと、こう文字コード由来のインジェクションを防ぐってFWならともかくさ。
当然そんな誤検出なんてありえん。
Re: (スコア:0)
この長文はプレースホルダやせめてエスケープ処理を知らない昔の人ですか？
Re:Webアプリケーションファイアウォールを知らないの？ (スコア:1)
「ファイヤウォールがSQLインジェクション攻撃と誤認してアクセスをブロックしてしまう」ことを問題にしているのであって、ウェブアプリがSQLインジェクション対策されてるかどうかは無関係。
別のコメントみたいに「そんなファイヤウォールに頼るな」というツッコミは正当だけど、
プレースホルダとかエスケープ処理とか「SQLインジェクション対策しろ」というコメントはまったくの的外れ。
Re: (スコア:0)
WAFって今時どこでも使ってる気がするけど、金融系でだけそんな問題が発生するの? それは金融系のセキュリティが甘いってことじゃないの?
Re: (スコア:0)
金融系は真っ先にWAF入れた
真っ先に入れたからチャチかったので先のようなことになった
それに対応するためのバッドノウハウも必要だった
東京都心の地下鉄駅が狭くてぼろいようなもん
Re: (スコア:0)
WAF知ってるけど、だからなに？
出来の悪いWAFのために、ユーザー側を制限しますって馬鹿？
安全性が重視されるシステムほど、認証用のデータベース（およびページ）と
それ以外を切り離したほうがいいに決まっているじゃない。
設計ミスを他人のせいにするのはやめましょう。
Re: (スコア:0)
SQLインジェクションはSQL発行する段階で防止すればいい話じゃないの？
結局そのファイアウォールをあてにした杜撰なプログラムになったり
ページによって例外的にそのファイアウォールを無効にするとかややこしい実装になったりで
かえってセキュリティが低下するような気がするんだけど。
Re: (スコア:0)
普通にFW屋に行ってWAF買ってくればSQLインジェクションをブロックしてくれるFWが売ってる
Re: (スコア:0)
サマータイムの話でたくさんいた
「テストしてないから保証できない」
「発注元が値切るから仕方がない」
ってやつじゃない？
Re: (スコア:0)
激しく同意。
仕様を無駄に複雑にする必用なぞどこにもない。
99.99％動くからといって、テストがなくなるわけじゃないし、将来実装が変更されない保証もない。
仕様を無駄に複雑にして、工数を増やして現場を疲弊させる経営者や政治家は大馬鹿者だと、
ハッキリ言っておきたい。
それに一度でも公開された仕様は、あとで不具合がでたからと言って簡単には変更できない。
特にパスワード系は厄介。
Re: (スコア:0)
「英数記号を必ず1文字使用すること(ただし使用できる記号は...)」
と(中途半端に)記号を入力できる＋記号は必ず使用しなければならないという時点で、
無駄に複雑とはならないのですか？
Re: (スコア:0)
> 仕様を無駄に複雑にする必用なぞどこにもない。
サマータイムについて、制度導入により、政治的・ビジネス的には別として、システム稼働上不必要な仕様の複雑化が発生することには同意。
パスワードに記号を認める(多分@とか`とかのことかと)ことについては、仕様の複雑化はシステム稼働上不必要とは思わないし、そもそも複雑化にはつながらない。
Re: (スコア:0)
むしろキッチリと対応していた方が、将来的にバグが発生する可能性が減る。
それこそどこかにSQLを直打ちしている所でもあったりしたりで。