アカウント名:
パスワード:
元のパスワードに戻せるので元の木阿弥です(・3・)あるぇ～?
それ以前に、いいかげん「英数字のみで10文字まで」って何とかしてほしい……
文字数を妙に短く制限するところ、記号を使わせないところって多いけど、どうしてなの?ウェブアプリのログイン認証において、プログラム上、制限を設けて楽になることって何なのでしょう。思いつかないのですが。
記号を使わせないのは、（誤った）サニタイズ [takagi-hiromitsu.jp]によるものではないかな。
単純にパスワードは付箋に書いて貼り付けておくものではなく、記憶することが前提だからではないでしょうか。記号の方が覚えやすい例もある。たしかに。おそらく流行するのは顔文字を使ったパスワードの横行が予測できます。顔文字アタックの脆弱性を突かれた馬鹿ニュースの題材になると・・・開発する側は普通そこまでは想定するのでは？
# 因果理由が無いものなんてありません
昔おバカなプログラマが SQL インジェクション可能な脆弱性を作っていたころの名残かもしれませんね。「怒れるサル」と同様な現象かもしれず。
入力しにくいのは理解出来ますが、だからといって使用制限するのはどうかと思いますね。めんどうくさいから英数だけで、というのはユーザーが自分で決めればいいだけですし。
# 逆に最近、セキュリティ意識の高い(?)ウェブサービスだと、パスワードは何文字以上、英数記号をすべてまぜろ、と強制してくるところもある。
その両者が混ざると同じ生成アルゴリズムでパスワードを作れないのでマジめんどくさい
きっとそう。中途半端に頭のいい人が仕様に関わってるから。「パスワードで許容する文字の種類について定義してください」と、「なんで記号が存在するんですか？理由を述べてください」のコンボ。返答が面倒な下請け会社は、最初から記号を含めないのではないかと妄想しました。
使用可能な記号を羅列するのも面倒だからねぇ。と思ったが、使用不可にしないとまずい記号ってあったかな。なんか盲点があるような気がして不安になってきた。
という思考を経て「制限したほうが楽だわ」になります。
仕様不可にしないとまずいってわけじゃないけど、パスワードに記号使ってて101キーボードに換わったときに困ったことはある。
＃ユーザ名は固定でパスワード欄しか入力項目がないシステムにて
# 内容が内容なんでACそれがあるんで自分は101と106で共通になる記号しか使わないようにしてます。
「使用不可にしなければならない記号」はないけど、エスケープに失敗したり、検証を間違えたりすると、どこで下らんバグが発生するか分からんから、可能な限り記号は入れないことにしてる。動作確認もそんだけ面倒になるし。
ただでさえ人手も開発費も足らんとゆーのに。そんな所に無駄な工数かけられない。
＞ウェブアプリのログイン認証において、プログラム上、制限を設けて楽になることって何なのでしょう。思いつかないのですが。記号を減らすのは重要。記号を入れるのはセキュリティ上でもユーザビリティでも必要性はない。文字数は減らしても増やしてもそんなに影響は無い。（数百文字とか言われたら別だけど）
だから- 記号は除去。- 文字はアルファベット大文字／小文字と数字- 文字数は２０～３０文字にするのが多かったな。
記号の有無で辞書攻撃の成功率は桁違いに変わると思いますが・・・。ユーザビリティも変わります。カナ打ちなので、ローマ字入力状態でカナ入力って手を使うのですが、“,”、“.”、“;”、“:”、“]”、“-”など、いくつかの記号が引っかかります。ユーザビリティに必要ないと決めつけるのはどうかと思います。
＞ 記号の有無で辞書攻撃の成功率は桁違いに変わると思いますが・・・。迷信でしょ。
根拠も無く、こういうこと言う人が多すぎて困る。
内部でやりとりする経路(フロントエンドからバックエンドDBまで)でのエスケープとかは、まあ気にはなりますよね。
# それで制限していいかは別なんだけど。
まあ、英数+ASCIIの記号内がいいけど、英数だけでも15以上OKになってれば文句はいわんのだが# 普段は14字ランダムを生成してる
羅列された記号を使ったらログインできなくなったことがあるので、「制限してくれたほうが楽だわ」になっています。
うわ、分かる分かる。＃これやっちゃうと、かなり恥ずかしいんだわ。初歩的ミスといえば初歩的ミスなんだけどね。orz
どこかで処理を間違えてると、「特定の記号を使った時だけログインできない」みたいなことも起こらないとは限らない。記号を入れなければ、どんな阿呆に作らせても（他のバグは出ても）まずそういうバグは出ないので、記号を入れるのは可能な限り止めた方が良い。
その辺りのリスクも想定できずに、むやみやたらと記号を入れたがるのは、プログラミングスキルの無い人の場合が圧倒的に多いと思う。
そんなバグを入れる奴こそプログラミングスキルがないに決まってるのに何この逆切れ。しかも完全に開発者の論理。
普通に考えて、パスワードはソルト付でハッシュ化するのが当たり前になってるので、入力文字列はなんでもいいはずなんだけどね。もちろん、マルチバイトでも。文字コードは注意が必要だろうけど。特に日本のお固い業界(銀行などの金融機関)が、文字種・文字数制限が多いイメージ。一般の人が使用する率が高いからかな？そう考えると、いまだに銀行のキャッシュカードのパスワードが数字４桁っていうのもね。
普通に考えて、パスワードはソルト付でハッシュ化するのが当たり前
チャレンジ/レスポンス認証 [e-words.jp]方式の全否定ですね。
普通に考えて、パスワードはソルト付でハッシュ化するのが当たり前チャレンジ/レスポンス認証方式の全否定ですね。
チャレンジ/レスポンス認証方式の全否定ですね。
設計の新しいチャレンジ/レスポンス認証方式、例えばHTTPのDigest認証などは「「「パスワードのハッシュ」+チャレンジ」のハッシュ」を比較するので、サーバ側に生のパスワードを持っておく必要はありません。
APOPみたいなサーバ側で生のパスワードを保持しなきゃならないような古くさいタイプのチャレンジ/レスポンス方式は、否定しちゃっても問題ないと思う。
「パスワードハアンゴウカ」だけを意味もわからず呪文のごとく唱えまくった結果がごらんのありさま。「サニタイズ」を呪文のように唱えまくった結果パスワードに意味不明な文字種制限がつきましたとさ、とまったく同じ構造の問題なのだが少しは応用力とか抽象化の能力とかないものだろうかね。Cargo cult security (日本語にすると「鰯の頭セキュリティ?」)もいい加減にしてもらいたいもんだ
私が普段使ってる銀行のネットログインパスワードが数字のみ４桁です。デフォルトでソフトウェアキーボード使用を推奨されますが・・・
心配するところ、そこじゃないだろ？十八銀行！！！キーロガーとか入ってないよ。。。お願いですから英数記号で１０文字以上にしてください。＃どこの会社だよ、こんなクソ仕様を提案したの
SMBCもだよorz預金少な目にしたよ。
某ネットバンキング 数字４桁某ネットショップ 英数字８桁某ネットゲーム 英数字１２桁秘密のあのフォルダ 256bit AES
SMBCはワンタイムパス無料にした [smbc.co.jp]のでそれ使えばいいのよ？
知らなかった。早速申込んだ。ありがと(^^)そしてSMBCご免なさいm(__)m
ハッシュするのが当たり前っていうけど、某金融機関の仕様書には「暗号化する」って書いてあったんだが
ほ、ほらきっと一方向暗号とかそういうのだから(震え声)
そこで金融機関の名称を書いてくれないと避けられないじゃん。使えねーACだな
お前の口座より、自分の首の方が大事なんだ。すまんな。犠牲になってくれ。
＞パスワードはソルト付でハッシュ化するのが当たり前認証統合（AD LDAP shibboleth など）環境だとそうもいかない場合がある頭が痛い
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
あつくて寝られない時はhackしろ! 386BSD(98)はそうやってつくられましたよ? -- あるハッカー
初期化パスワードは勝手に決められますが……… (スコア:1)
元のパスワードに戻せるので元の木阿弥です(・3・)あるぇ～?
Re: (スコア:2, すばらしい洞察)
それ以前に、いいかげん「英数字のみで10文字まで」って何とかしてほしい……
Re:初期化パスワードは勝手に決められますが……… (スコア:1)
文字数を妙に短く制限するところ、記号を使わせないところって多いけど、どうしてなの?
ウェブアプリのログイン認証において、プログラム上、制限を設けて楽になることって何なのでしょう。思いつかないのですが。
Re:初期化パスワードは勝手に決められますが……… (スコア:2, 参考になる)
記号を使わせないのは、（誤った）サニタイズ [takagi-hiromitsu.jp]によるものではないかな。
Re: (スコア:0)
単純にパスワードは付箋に書いて貼り付けておくものではなく、
記憶することが前提だからではないでしょうか。
記号の方が覚えやすい例もある。たしかに。
おそらく流行するのは顔文字を使ったパスワードの横行が予測できます。
顔文字アタックの脆弱性を突かれた馬鹿ニュースの題材になると・・・
開発する側は普通そこまでは想定するのでは？
# 因果理由が無いものなんてありません
Re:初期化パスワードは勝手に決められますが……… (スコア:1)
昔おバカなプログラマが SQL インジェクション可能な脆弱性を作っていたころの名残かもしれませんね。
「怒れるサル」と同様な現象かもしれず。
Re:初期化パスワードは勝手に決められますが……… (スコア:1)
# 記号や英語がパスワードボックスに入力しにくい
Re: (スコア:0)
入力しにくいのは理解出来ますが、だからといって使用制限するのはどうかと思いますね。
めんどうくさいから英数だけで、というのはユーザーが自分で決めればいいだけですし。
# 逆に最近、セキュリティ意識の高い(?)ウェブサービスだと、パスワードは何文字以上、英数記号をすべてまぜろ、と強制してくるところもある。
Re: (スコア:0)
その両者が混ざると同じ生成アルゴリズムでパスワードを作れないのでマジめんどくさい
Re: (スコア:0)
きっとそう。
中途半端に頭のいい人が仕様に関わってるから。
「パスワードで許容する文字の種類について定義してください」と、
「なんで記号が存在するんですか？理由を述べてください」のコンボ。
返答が面倒な下請け会社は、最初から記号を含めないのではないかと妄想しました。
Re: (スコア:0)
使用可能な記号を羅列するのも面倒だからねぇ。
と思ったが、使用不可にしないとまずい記号ってあったかな。
なんか盲点があるような気がして不安になってきた。
という思考を経て「制限したほうが楽だわ」になります。
Re:初期化パスワードは勝手に決められますが……… (スコア:2)
仕様不可にしないとまずいってわけじゃないけど、
パスワードに記号使ってて101キーボードに換わったときに困ったことはある。
＃ユーザ名は固定でパスワード欄しか入力項目がないシステムにて
Re: (スコア:0)
# 内容が内容なんでAC
それがあるんで自分は101と106で共通になる記号しか使わないようにしてます。
Re:初期化パスワードは勝手に決められますが……… (スコア:2)
「使用不可にしなければならない記号」はないけど、エスケープに失敗したり、
検証を間違えたりすると、どこで下らんバグが発生するか分からんから、
可能な限り記号は入れないことにしてる。動作確認もそんだけ面倒になるし。
ただでさえ人手も開発費も足らんとゆーのに。そんな所に無駄な工数かけられない。
＞ウェブアプリのログイン認証において、プログラム上、制限を設けて楽になることって何なのでしょう。思いつかないのですが。
記号を減らすのは重要。
記号を入れるのはセキュリティ上でもユーザビリティでも必要性はない。
文字数は減らしても増やしてもそんなに影響は無い。（数百文字とか言われたら別だけど）
だから
- 記号は除去。
- 文字はアルファベット大文字／小文字と数字
- 文字数は２０～３０文字
にするのが多かったな。
Re: (スコア:0)
記号の有無で辞書攻撃の成功率は桁違いに変わると思いますが・・・。
ユーザビリティも変わります。カナ打ちなので、ローマ字入力状態でカナ入力って手を使うのですが、“,”、“.”、“;”、“:”、“]”、“-”など、
いくつかの記号が引っかかります。
ユーザビリティに必要ないと決めつけるのはどうかと思います。
Re: (スコア:0)
＞ 記号の有無で辞書攻撃の成功率は桁違いに変わると思いますが・・・。
迷信でしょ。
根拠も無く、こういうこと言う人が多すぎて困る。
Re:初期化パスワードは勝手に決められますが……… (スコア:1)
内部でやりとりする経路(フロントエンドからバックエンドDBまで)でのエスケープとかは、まあ気にはなりますよね。
# それで制限していいかは別なんだけど。
まあ、英数+ASCIIの記号内がいいけど、英数だけでも15以上OKになってれば文句はいわんのだが
# 普段は14字ランダムを生成してる
M-FalconSky (暑いか寒い)
Re: (スコア:0)
羅列された記号を使ったらログインできなくなったことがあるので、「制限してくれたほうが楽だわ」になっています。
Re: (スコア:0)
うわ、分かる分かる。
＃これやっちゃうと、かなり恥ずかしいんだわ。初歩的ミスといえば初歩的ミスなんだけどね。orz
どこかで処理を間違えてると、「特定の記号を使った時だけログインできない」みたいなことも
起こらないとは限らない。記号を入れなければ、どんな阿呆に作らせても（他のバグは出ても）
まずそういうバグは出ないので、記号を入れるのは可能な限り止めた方が良い。
その辺りのリスクも想定できずに、むやみやたらと記号を入れたがるのは、
プログラミングスキルの無い人の場合が圧倒的に多いと思う。
Re: (スコア:0)
そんなバグを入れる奴こそプログラミングスキルがないに決まってるのに何この逆切れ。しかも完全に開発者の論理。
Re: (スコア:0)
普通に考えて、パスワードはソルト付でハッシュ化するのが当たり前になってるので、
入力文字列はなんでもいいはずなんだけどね。もちろん、マルチバイトでも。文字コードは注意が必要だろうけど。
特に日本のお固い業界(銀行などの金融機関)が、文字種・文字数制限が多いイメージ。
一般の人が使用する率が高いからかな？
そう考えると、いまだに銀行のキャッシュカードのパスワードが数字４桁っていうのもね。
Re:初期化パスワードは勝手に決められますが……… (スコア:2)
普通に考えて、パスワードはソルト付でハッシュ化するのが当たり前
チャレンジ/レスポンス認証 [e-words.jp]方式の全否定ですね。
Re:初期化パスワードは勝手に決められますが……… (スコア:1)
設計の新しいチャレンジ/レスポンス認証方式、例えばHTTPのDigest認証などは「「「パスワードのハッシュ」+チャレンジ」のハッシュ」を比較するので、サーバ側に生のパスワードを持っておく必要はありません。
APOPみたいなサーバ側で生のパスワードを保持しなきゃならないような古くさいタイプのチャレンジ/レスポンス方式は、否定しちゃっても問題ないと思う。
Re: (スコア:0)
「パスワードハアンゴウカ」だけを意味もわからず呪文のごとく唱えまくった結果がごらんのありさま。
「サニタイズ」を呪文のように唱えまくった結果パスワードに意味不明な文字種制限がつきましたとさ、とまったく同じ構造の問題なのだが少しは応用力とか抽象化の能力とかないものだろうかね。
Cargo cult security (日本語にすると「鰯の頭セキュリティ?」)もいい加減にしてもらいたいもんだ
Re:初期化パスワードは勝手に決められますが……… (スコア:1)
私が普段使ってる銀行のネットログインパスワードが数字のみ４桁です。
デフォルトでソフトウェアキーボード使用を推奨されますが・・・
心配するところ、そこじゃないだろ？十八銀行！！！
キーロガーとか入ってないよ。。。
お願いですから英数記号で１０文字以上にしてください。
＃どこの会社だよ、こんなクソ仕様を提案したの
破られて困るパスワードほど文字制限がきついって法則でもあるのか？ (スコア:1)
SMBCもだよorz
預金少な目にしたよ。
某ネットバンキング 数字４桁
某ネットショップ 英数字８桁
某ネットゲーム 英数字１２桁
秘密のあのフォルダ 256bit AES
Re:破られて困るパスワードほど文字制限がきついって法則でもあるのか？ (スコア:2, 参考になる)
SMBCはワンタイムパス無料にした [smbc.co.jp]のでそれ使えばいいのよ？
Re:破られて困るパスワードほど文字制限がきついって法則でもあるのか？ (スコア:1)
知らなかった。
早速申込んだ。ありがと(^^)
そしてSMBCご免なさいm(__)m
Re: (スコア:0)
ハッシュするのが当たり前っていうけど、
某金融機関の仕様書には「暗号化する」って書いてあったんだが
Re: (スコア:0)
ほ、ほらきっと一方向暗号とかそういうのだから(震え声)
Re: (スコア:0)
そこで金融機関の名称を書いてくれないと避けられないじゃん。使えねーACだな
そうは言っても (スコア:1)
お前の口座より、自分の首の方が大事なんだ。
すまんな。犠牲になってくれ。
Re: (スコア:0)
＞パスワードはソルト付でハッシュ化するのが当たり前
認証統合（AD LDAP shibboleth など）環境だと
そうもいかない場合がある
頭が痛い