アカウント名:
パスワード:
パスワードという機微情報にあれこれ口出しされるのは良い気分がしない。プライベートゾーンにぺたぺた触られる感じ。いくらブラウザ上で照合しているから安全だと言われても、それを開発者ツールで毎回確認するなんて手間は取れないし。不正利用補償の義務を負う金融機関ですらここまでやる例は聞かないのに、pixiv程度の少額決済サービスでここまでやる必要性って？悪意のある利用者を弾くならわかるけど、善意の利用者を弾く仕組みだよね、これ。「パスワードリスト攻撃でアカウント情報が漏洩したらブランドイメージに傷が付きます」とでも言って上を説得したんだろうか。昨年、度重なるUI改悪で炎上 [twitter.com]したのもそうだけど、社内で仕事にあぶれた技術者が余計な仕事を作り出してる気がする。
> 不正利用補償の義務を負う金融機関ですらここまでやる例は聞かないのに、pixiv程度の少額決済サービスでここまでやる必要性って？大多数の金融機関は昔っから二要素認証してるしダメなパスワードを登録・更新時に弾いてるから既存パスワードの棚卸は必須ではないPixivは最近まで弾いてすらいなかったから棚卸の必要性もある比較要素の解像度が悪いから必要性に気が付けないだけだと思うよ
> 悪意のある利用者を弾くならわかるけど、善意の利用者を弾く仕組みだよね、これ。善意の利用者であれば事故・事件に合わない、なんてことはないまた善意だの悪意だのはシステム的には判断しようがない悪意のある利用者とやらを弾くためには、一策として脆弱なパスワードを廃止するというのは、普通に分かることだと思うよ
> 大多数の金融機関は昔っから二要素認証してるしダメなパスワードを登録・更新時に弾いてるから既存パスワードの棚卸は必須ではない
金融機関が脆弱なパスワードを弾き出したのも割と最近のことじゃないですかね。データベースの拡張に制限があるのか記号は使えませんとか長さは数十文字までとか安全対策が遅れがちな印象。
そういえばpixivも多要素認証対応検討しますみたいなことを昨年1月に言ってて結局まだ実装されてないんですよね。この調子だと実装した途端に多要素認証必須とかにしてきそうで怖いな。
> 悪意のある利用者とやらを弾くためには、一策として脆弱なパスワードを廃止するというのは、普通に分かることだと思うよ
悪意をもって脆弱なパスワードでサインアップする利用者なんていませんし、いたとしても配慮する必要なんてないでしょう。
s/数十文字/十数文字/
記号が使えないのはデータベースのせいじゃなくて、記号が入力できないデバイスからログインする可能性を考えてのことだったりしないのかな。
「データベースの仕様で」なんてのが理由だとすると、それは平文のパスワードを保存していることを意味するんだから全く問題外だし。
データベースというか連携システムも含めたの入出力の都合ですかね。一昔前のネットバンキングは紙ベースでパスワードの申請・郵送をしてたので、どこかの段階で平文のパスワードを扱う必要があったはず。データベースへの保存はハッシュ化じゃなくて可逆暗号でヨシ！
CHAPは可逆な形でパスワードを保存しなければならない(その代わり通信路上ではハッシュ化されている)定期
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
日々是ハック也 -- あるハードコアバイナリアン
やりすぎでは？ (スコア:0)
パスワードという機微情報にあれこれ口出しされるのは良い気分がしない。プライベートゾーンにぺたぺた触られる感じ。
いくらブラウザ上で照合しているから安全だと言われても、それを開発者ツールで毎回確認するなんて手間は取れないし。
不正利用補償の義務を負う金融機関ですらここまでやる例は聞かないのに、pixiv程度の少額決済サービスでここまでやる必要性って？
悪意のある利用者を弾くならわかるけど、善意の利用者を弾く仕組みだよね、これ。
「パスワードリスト攻撃でアカウント情報が漏洩したらブランドイメージに傷が付きます」とでも言って上を説得したんだろうか。
昨年、度重なるUI改悪で炎上 [twitter.com]したのもそうだけど、社内で仕事にあぶれた技術者が余計な仕事を作り出してる気がする。
Re: (スコア:0)
> 不正利用補償の義務を負う金融機関ですらここまでやる例は聞かないのに、pixiv程度の少額決済サービスでここまでやる必要性って？
大多数の金融機関は昔っから二要素認証してるしダメなパスワードを登録・更新時に弾いてるから既存パスワードの棚卸は必須ではない
Pixivは最近まで弾いてすらいなかったから棚卸の必要性もある
比較要素の解像度が悪いから必要性に気が付けないだけだと思うよ
> 悪意のある利用者を弾くならわかるけど、善意の利用者を弾く仕組みだよね、これ。
善意の利用者であれば事故・事件に合わない、なんてことはない
また善意だの悪意だのはシステム的には判断しようがない
悪意のある利用者とやらを弾くためには、一策として脆弱なパスワードを廃止するというのは、普通に分かることだと思うよ
Re:やりすぎでは？ (スコア:0)
> 大多数の金融機関は昔っから二要素認証してるしダメなパスワードを登録・更新時に弾いてるから既存パスワードの棚卸は必須ではない
金融機関が脆弱なパスワードを弾き出したのも割と最近のことじゃないですかね。
データベースの拡張に制限があるのか記号は使えませんとか長さは数十文字までとか安全対策が遅れがちな印象。
そういえばpixivも多要素認証対応検討しますみたいなことを昨年1月に言ってて結局まだ実装されてないんですよね。
この調子だと実装した途端に多要素認証必須とかにしてきそうで怖いな。
> 悪意のある利用者とやらを弾くためには、一策として脆弱なパスワードを廃止するというのは、普通に分かることだと思うよ
悪意をもって脆弱なパスワードでサインアップする利用者なんていませんし、いたとしても配慮する必要なんてないでしょう。
Re: (スコア:0)
s/数十文字/十数文字/
Re: (スコア:0)
記号が使えないのはデータベースのせいじゃなくて、
記号が入力できないデバイスからログインする可能性を
考えてのことだったりしないのかな。
「データベースの仕様で」なんてのが理由だとすると、
それは平文のパスワードを保存していることを意味するんだから
全く問題外だし。
Re: (スコア:0)
データベースというか連携システムも含めたの入出力の都合ですかね。
一昔前のネットバンキングは紙ベースでパスワードの申請・郵送をしてたので、どこかの段階で平文のパスワードを扱う必要があったはず。
データベースへの保存はハッシュ化じゃなくて可逆暗号でヨシ！
Re: (スコア:0)
CHAPは可逆な形でパスワードを保存しなければならない(その代わり通信路上ではハッシュ化されている)定期