アカウント名:
パスワード:
同じくITmediaだけどこちら [itmedia.co.jp]の方が詳しそう？データの構造化はしていただろうから、「パスワードも含まれる」じゃなくて「パスワードも含めてた」だと思われる。もはやパスワードを平文で送信することが脆弱性になりそう。ブラウザの段階で適当にハッシュ化されるようになったりして。
なんでhtmlのformにpasswordのinputを作った時点で何かしらハッシュを送信するようにしなかったのか不思議でならない。まぁ当時ならsaltなしで弱いハッシュ関数を一回分とかになっていただろうけどそうだとしてもhtml5ができた頃には、そこそこまともなハッシュ関数とストレッチングのサポート・セキュリティ警告・多重ハッシュ(サーバー側にはハッシュ化済みのパスワードしかないはずなので)、程度には改良されていたはず。少なくとも平文が漏れ出すとか使いまわしが問題になるとかはかなり少なかったでしょ。
別に今ならJavaScriptでハッシュ関数にかけるくらいできるけどね。
生パスワードが必要なシステムだった場合 => しようがない生パスワードが必要ないシステムだった場合 => 生パスワードが必要ないのに保存してるような馬鹿がハッシュしてから送るとか、気の利いたことを出来るわけがない。
馬鹿を見分けられるじゃないの。「何で生パスワードを要求するんですか」みたいな事になる。
サービスAに認証しているとサービスBでも認証が通る必要がある。サービスBはサービスAの認証から時間が経った後に接続される。サービスBは互換性の問題からパスワードの生の値を受け取る事しか出来ない。
サービスAの認証トークン受け取ればよくね？
サービスBは互換性の問題からパスワードの生の値を受け取る事しか出来ない。
サービスAをわざわざ出したということは、認証主体はサービスAでサービスBは問い合わせてるだけだろ。サービスBに生パスワードを送る必要はなく、サービスBに送った値でサービスAにログインできればいい。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
クラックを法規制強化で止められると思ってる奴は頭がおかしい -- あるアレゲ人
社内の専用アプリケーション (スコア:0)
同じくITmediaだけどこちら [itmedia.co.jp]の方が詳しそう？
データの構造化はしていただろうから、「パスワードも含まれる」じゃなくて
「パスワードも含めてた」だと思われる。
もはやパスワードを平文で送信することが脆弱性になりそう。
ブラウザの段階で適当にハッシュ化されるようになったりして。
Re: (スコア:0)
なんでhtmlのformにpasswordのinputを作った時点で何かしらハッシュを送信するようにしなかったのか不思議でならない。
まぁ当時ならsaltなしで弱いハッシュ関数を一回分とかになっていただろうけどそうだとしてもhtml5ができた頃には、そこそこまともなハッシュ関数とストレッチングのサポート・セキュリティ警告・多重ハッシュ(サーバー側にはハッシュ化済みのパスワードしかないはずなので)、程度には改良されていたはず。
少なくとも平文が漏れ出すとか使いまわしが問題になるとかはかなり少なかったでしょ。
別に今ならJavaScriptでハッシュ関数にかけるくらいできるけどね。
Re: (スコア:0)
生パスワードが必要なシステムだった場合 => しようがない
生パスワードが必要ないシステムだった場合 => 生パスワードが必要ないのに保存してるような馬鹿がハッシュしてから
送るとか、気の利いたことを出来るわけがない。
Re:社内の専用アプリケーション (スコア:1)
馬鹿を見分けられるじゃないの。
「何で生パスワードを要求するんですか」みたいな事になる。
Re: (スコア:0)
サービスAに認証しているとサービスBでも認証が通る必要がある。
サービスBはサービスAの認証から時間が経った後に接続される。
サービスBは互換性の問題からパスワードの生の値を受け取る事しか出来ない。
Re: (スコア:0)
サービスAの認証トークン受け取ればよくね？
Re: (スコア:0)
サービスBは互換性の問題からパスワードの生の値を受け取る事しか出来ない。
Re: (スコア:0)
サービスAをわざわざ出したということは、認証主体はサービスAでサービスBは問い合わせてるだけだろ。
サービスBに生パスワードを送る必要はなく、サービスBに送った値でサービスAにログインできればいい。