アカウント名:
パスワード:
> パスワードに記号を認めないのはどういった理由なのでしょうか。少なくとも、技術的に困難なことではありません。
わかってて書いているでしょうが、困難ではないですけど、確実にコストアップにつながりますよね。
とりあえず、「&」「?」「"」「'」あたりはHTMLやSQLなどのために対処が必要でしょうね。使用言語やライブラリなどによってコードのほうは記号未対応の場合と一緒でいいときもあるでしょうが、テスト項目のほうにはきちんと盛り込まないといけませんね。（パスワード強度を上げようとしてSQLインジェクションなどに陥っては意味がないですよね）
あと、「.」と「,」や「'」と「`」などの見間違えやすい記号を両方通すと書面等で通達するときにトラブルになりやすいかな？電話等の口頭の場合には「アポストロフィーって何？」とかなりそうですね。このあたりは英字の大文字と小文字を区別して受け入れる場合と同様にめんどくさそうです。
まあ、Pixivの件はどうか存じませんが大体、必要なセキュリティとコストの兼ね合いで仕様が定まるでしょう、マトモな開発に依頼すれば。
# 連投制限があるのでここで書いちゃいますが# パスワード数の上限設定はVARCHAR2(8)とかしちゃうせいでしょうね（大目に設定すればいいのに）
・ユーザーが入力したパスワード文字列を保存するなんていう危険な実装をしようという時点で、そんな開発はまともじゃないし狂ってます。受け取ったら即座にハッシュにして、そのあとはプログラム内ではそのハッシュを扱えばいいだけです。パスワード文字列をそのまま保持するなんてとんでもない！
・ユーザーが入力したパスワード文字列を画面に表示する必要性はありませんので、これで特に問題は起きません。ユーザーの入力ミスを防ぎたいなら、二つの欄に二度入力させるなどの方法で対応すべきです。
・パスワードを忘れたユーザーに、ユーザー自身が以前入力したパスワードを通知する必要はありませんし、また、かなりのユーザーが同じパスワードを複数のサービスで使ってるため、万一第三者に不正取得された場合にも被害が自サービスだけではすまない大ごとになりかねません。ランダムな文字列を自動生成してそれを通知すべきです。自動生成する文字列に限っては、ややこしい記号を使わずアルファベットと数字だけを使うようにしておけばいいことです。
＞確実にコストアップにつながりますよね。まったくです。
まあ、ぶっちゃけいうと、今となっては桁数増やす方がずっと楽。20文字でも30文字でも，コンピューターの記憶容量からすると誤差みたいな物だし。
ボトルネックは人間の記憶容量だな。最近は歳のせいか、物覚えが悪くて。
理想的にはそうですが、APOPのようなチャレンジ・レスポンス方式の場合、生パスワードが必要になりませんか？この辺り詳しい人がいたらお願いしたいです。
チャレンジ/レスポンス方式だからといって、生パスワードが必要とは限りません。プロトコルの設計次第です。例えば、HTTPのDigest認証 [wikipedia.org]では、パスワードハッシュを、更にチャレンジレスポンスでハッシュ化してるので、生パスワードを保存する必要はありません。
もっとも、この場合「パスワードハッシュ」がAPOPとかでの生パスワード相当であり、それが漏れたら同サービスでのなりすましは出来てしまうわけですが、影響が他に及ぶ心配がないというか「複数のサービスで同じパスワードを使い回している場合に、他のサービスに対しても攻撃が出来る」のを防ぐことにはなります。
> 生パスワードが必要になりませんか？
なります。だから「生パスワードを保管しているからセキュリティ的に問題あり。だから生パスワードが必要なサービスはやめましょう。」なんて一概にいえるはずはないんですよ。
どういう仕組みでも設計するときにはトレードオフの考慮は必要ですよ、当たり前すぎますが。
＞確実にコストアップにつながりますよね。
それくらいを見込んでコストを計算しないとね。サービスを劣化させてコストを縮小したい..というのはわかるけど、劣化させて安くしましたがほめられるというのも問題だろ？
＞パスワード強度を上げようとしてSQLインジェクションなどに陥っては意味がないですよね
そういう質の低いコードしか書けない安い人を雇って安くすると？
＞同様にめんどくさそうです
面倒なら、そもそもそんなシステム組むのやめたら？
＞＞パスワード強度を上げようとしてSQLインジェクションなどに陥っては意味がないですよね＞そういう質の低いコードしか書けない安い人を雇って安くすると？
この人、正気なのかな。
苦労して完璧にエスケープできるコードを書いて、十分にテストして安全性を保証するコストは、技術力の如何に関わらず結構なものです。しかもこのコストは無闇やたらと記号を入れるという決断さえしなければ、最初から要らないものだもの。しかも記号を入れても、とくにパスワードの強度が上がるわけでもないというのに。
なんだか、「シートベルトもエアバッグもなしで、しかもそれを使用している時と同等以上の安全性を技術力で実現しろ」といわれてる気分。不可能じゃないけど、金と技術の無駄づかいでしかない。
。。。。「タバコ自販機の顔認証」の方が例としては良かったかな？
>なんだか、「シートベルトもエアバッグもなしで、しかもそれを使用している時と同等以上の安全性>を技術力で実現しろ」といわれてる気分。
ちゃんとしたモノが作れないので、シートベルトもエアバッグも付けられないし、付けるとコストがかかっちゃうので、付けないということを言いたいわけですね。
必要なものが何かを理解してからプログラミングなり設計をされるとよいでしょう。
> わかってて書いているでしょうが、困難ではないですけど、> 確実にコストアップにつながりますよね。
その程度でコストアップとかいうのはサニタイズ脳じゃないですかね。
> 書面等で通達するときにトラブルになりやすいかな？
パスワードを書面で通達するんですか？初期パスワードなら紛らわしい文字は使わなければいいだけ。
かつてユーザ数2000人ほど(コンピュータリテラシは低い)の組織にシステムを導入したときの話ですが、初期パスワードは自動生成文字列を割り当てました。
が、紛らわしい文字を使うとログインできないと苦情が来て対応に追われることが予想されたため、0, o, O, 1, l, I, i, j, c, C, p, P, s, S, u, U, v, V w, W, x, X, z, Z は使わないようにして生成しました。
こんなんでも一見複雑そうに見えるパスワードにはなりますし、初期パスワードとしてユーザ名 + 番号みたいなものを与えてパスワードってそういうものなんだ、みたいな間違った学習をユーザにさせてしまうのはよろしくないですし。
だれか、このレスに「参考になる」をモデレートしてくれないかなぁ。
駄目なSIerがどういう間違いを犯すか、それをどう指摘・修正すれば良いかについて、大いに参考になるよ。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
ナニゲにアレゲなのは、ナニゲなアレゲ -- アレゲ研究家
貧弱なパスワードを要求するシステム (スコア:2, 興味深い)
パスワードに記号を認めないのはどういった理由なのでしょうか。少なくとも、技術的に困難なことではありません。ウェブサービスを作成されている皆さんにちょっと考えてほしいと思った一件でした。
# これを以って pixiv を悪く言うつもりはないので AC
記号に対応する必要はないという話ではないですよ (スコア:2, おもしろおかしい)
> パスワードに記号を認めないのはどういった理由なのでしょうか。少なくとも、技術的に困難なことではありません。
わかってて書いているでしょうが、困難ではないですけど、
確実にコストアップにつながりますよね。
とりあえず、「&」「?」「"」「'」あたりはHTMLやSQLなどのために対処が必要でしょうね。
使用言語やライブラリなどによってコードのほうは記号未対応の場合と一緒でいいときもあるでしょうが、
テスト項目のほうにはきちんと盛り込まないといけませんね。
（パスワード強度を上げようとしてSQLインジェクションなどに陥っては意味がないですよね）
あと、「.」と「,」や「'」と「`」などの見間違えやすい記号を両方通すと
書面等で通達するときにトラブルになりやすいかな？
電話等の口頭の場合には「アポストロフィーって何？」とかなりそうですね。
このあたりは英字の大文字と小文字を区別して受け入れる場合と同様にめんどくさそうです。
まあ、Pixivの件はどうか存じませんが
大体、必要なセキュリティとコストの兼ね合いで仕様が定まるでしょう、マトモな開発に依頼すれば。
# 連投制限があるのでここで書いちゃいますが
# パスワード数の上限設定はVARCHAR2(8)とかしちゃうせいでしょうね（大目に設定すればいいのに）
Re:記号に対応する必要はないという話ではないですよ (スコア:3, すばらしい洞察)
・ユーザーが入力したパスワード文字列を保存するなんていう危険な実装をしようという時点で、そんな開発はまともじゃないし狂ってます。受け取ったら即座にハッシュにして、そのあとはプログラム内ではそのハッシュを扱えばいいだけです。パスワード文字列をそのまま保持するなんてとんでもない！
・ユーザーが入力したパスワード文字列を画面に表示する必要性はありませんので、これで特に問題は起きません。ユーザーの入力ミスを防ぎたいなら、二つの欄に二度入力させるなどの方法で対応すべきです。
・パスワードを忘れたユーザーに、ユーザー自身が以前入力したパスワードを通知する必要はありませんし、また、かなりのユーザーが同じパスワードを複数のサービスで使ってるため、万一第三者に不正取得された場合にも被害が自サービスだけではすまない大ごとになりかねません。
ランダムな文字列を自動生成してそれを通知すべきです。自動生成する文字列に限っては、ややこしい記号を使わずアルファベットと数字だけを使うようにしておけばいいことです。
Re:記号に対応する必要はないという話ではないですよ (スコア:2, すばらしい洞察)
＞確実にコストアップにつながりますよね。
まったくです。
まあ、ぶっちゃけいうと、今となっては桁数増やす方がずっと楽。
20文字でも30文字でも，コンピューターの記憶容量からすると誤差みたいな物だし。
ボトルネックは人間の記憶容量だな。
最近は歳のせいか、物覚えが悪くて。
Re:記号に対応する必要はないという話ではないですよ (スコア:1, すばらしい洞察)
それだと、いずれにしろ、セキュリティ的に問題があるような気がする。
一方向ハッシュ取って、BLOBか、あるいは、Base64かけたうえで、テキストとして保存するべきだと思うんですが。
Re:記号に対応する必要はないという話ではないですよ (スコア:1)
理想的にはそうですが、APOPのようなチャレンジ・レスポンス方式の場合、生パスワードが必要になりませんか？
この辺り詳しい人がいたらお願いしたいです。
Re:記号に対応する必要はないという話ではないですよ (スコア:1)
チャレンジ/レスポンス方式だからといって、生パスワードが必要とは限りません。プロトコルの設計次第です。
例えば、HTTPのDigest認証 [wikipedia.org]では、パスワードハッシュを、更にチャレンジレスポンスでハッシュ化してるので、生パスワードを保存する必要はありません。
もっとも、この場合「パスワードハッシュ」がAPOPとかでの生パスワード相当であり、それが漏れたら同サービスでのなりすましは出来てしまうわけですが、
影響が他に及ぶ心配がないというか「複数のサービスで同じパスワードを使い回している場合に、他のサービスに対しても攻撃が出来る」のを防ぐことにはなります。
Re: (スコア:0)
> 生パスワードが必要になりませんか？
なります。だから「生パスワードを保管しているからセキュリティ的に問題あり。だから生パスワードが必要なサービスはやめましょう。」なんて一概にいえるはずはないんですよ。
どういう仕組みでも設計するときにはトレードオフの考慮は必要ですよ、当たり前すぎますが。
Re:記号に対応する必要はないという話ではないですよ (スコア:1)
＞確実にコストアップにつながりますよね。
それくらいを見込んでコストを計算しないとね。
サービスを劣化させてコストを縮小したい..というのはわかるけど、劣化させて安くしましたがほめられるというのも問題だろ？
＞パスワード強度を上げようとしてSQLインジェクションなどに陥っては意味がないですよね
そういう質の低いコードしか書けない安い人を雇って安くすると？
＞同様にめんどくさそうです
面倒なら、そもそもそんなシステム組むのやめたら？
Re:記号に対応する必要はないという話ではないですよ (スコア:1, すばらしい洞察)
＞＞パスワード強度を上げようとしてSQLインジェクションなどに陥っては意味がないですよね
＞そういう質の低いコードしか書けない安い人を雇って安くすると？
この人、正気なのかな。
苦労して完璧にエスケープできるコードを書いて、十分にテストして安全性を保証するコストは、
技術力の如何に関わらず結構なものです。しかもこのコストは無闇やたらと記号を入れるという
決断さえしなければ、最初から要らないものだもの。しかも記号を入れても、とくにパスワードの
強度が上がるわけでもないというのに。
なんだか、「シートベルトもエアバッグもなしで、しかもそれを使用している時と同等以上の安全性
を技術力で実現しろ」といわれてる気分。不可能じゃないけど、金と技術の無駄づかいでしかない。
。。。。「タバコ自販機の顔認証」の方が例としては良かったかな？
Re:記号に対応する必要はないという話ではないですよ (スコア:1)
>なんだか、「シートベルトもエアバッグもなしで、しかもそれを使用している時と同等以上の安全性
>を技術力で実現しろ」といわれてる気分。
ちゃんとしたモノが作れないので、シートベルトもエアバッグも付けられないし、
付けるとコストがかかっちゃうので、付けないということを言いたいわけですね。
必要なものが何かを理解してからプログラミングなり設計をされるとよいでしょう。
Re: (スコア:0)
> わかってて書いているでしょうが、困難ではないですけど、
> 確実にコストアップにつながりますよね。
その程度でコストアップとかいうのはサニタイズ脳じゃないですかね。
> 書面等で通達するときにトラブルになりやすいかな？
パスワードを書面で通達するんですか？
初期パスワードなら紛らわしい文字は使わなければいいだけ。
Re:記号に対応する必要はないという話ではないですよ (スコア:1, 参考になる)
かつてユーザ数2000人ほど(コンピュータリテラシは低い)の組織に
システムを導入したときの話ですが、初期パスワードは自動生成文字列を割り当てました。
が、紛らわしい文字を使うとログインできないと苦情が来て対応に追われることが予想されたため、
0, o, O, 1, l, I, i, j, c, C, p, P, s, S, u, U, v, V w, W, x, X, z, Z は使わないようにして
生成しました。
こんなんでも一見複雑そうに見えるパスワードにはなりますし、
初期パスワードとしてユーザ名 + 番号みたいなものを与えて
パスワードってそういうものなんだ、みたいな間違った学習を
ユーザにさせてしまうのはよろしくないですし。
Re: (スコア:0)
だれか、このレスに「参考になる」をモデレートしてくれないかなぁ。
駄目なSIerがどういう間違いを犯すか、それをどう指摘・修正すれば良いかについて、大いに参考になるよ。