アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
私はプログラマです。1040 formに私の職業としてそう書いています -- Ken Thompson
パスワードは読取れてはいけない (スコア:5, すばらしい洞察)
パスワードって復号できない様にしておくものじゃないのかい?
内部犯行を防止する為にも可能なハードルはできるだけ置いておくものだろうに。
#暗号化したものが一致すれば良いので復号する必要は無い。
Re:パスワードは読取れてはいけない (スコア:5, 参考になる)
どうやら音声パスワードらしい。
オペレータが音声パスワードを聞いてそれを入力・検証するとか。
それとは別の認証も同時に行う必要があるらしい。
今回の事件の一番の問題は
勝手にパスワードを変えられてしまったことなんじゃないかと。
Re:パスワードは読取れてはいけない (スコア:2, おもしろおかしい)
> オペレータが音声パスワードを聞いてそれを入力・検証するとか。
「それって、普通は『合い言葉』と言うんじゃ、、、」
「おーっ、それ password [excite.co.jp] のことネ!」
Re:パスワードは読取れてはいけない (スコア:1)
>They staff has to be able to see it to verify it. It isn't a computer password.
このくだりですかね。それにしてもパスワードでの認証に第3者が必ず介在するってのはどうなんでしょ。
別のコメでもありましたが、銀行員が顧客の残高を閲覧するためにその顧客のパスワードを知る必要性はないし。
仕組みそのものもあまりセキュアでない印象。
Re:パスワードは読取れてはいけない (スコア:4, 興味深い)
>内部犯行を防止する為にも可能なハードルはできるだけ置いておくものだろうに。
もちろんその方法がベストなのですが、昔大手のWebサイトの会員管理のシステムにかかわったことがありますが、
パスワードはプレインテキストでしたよ。
まぁ世の中そんなもんです・・・。
Re:パスワードは読取れてはいけない (スコア:4, 興味深い)
平文を送ってこれるということは、まず間違いなくそのものをDBに格納しているわけで…。
# 逆(平文保存していても一方向ハッシュで保存しているように振舞わせることはできる)はわかりませんけど
うっうー
Re:パスワードは読取れてはいけない (スコア:3, 興味深い)
あるというより、パスワードの再設定を煩わしいと思う顧客も多いんですよ。サポートに「元に戻しておいてくれ」とかね。
Re: (スコア:0)
Re:パスワードは読取れてはいけない (スコア:1)
残高照会はそもそもあまりセキュアじゃなくてもいいということでは?
よく考えると、銀行の窓口の中からなら行員が悪意をもてば入出金も残高照会
もできるわけで、たとえばそれが会社の業務用口座で、会社内の複数の人物に共通の
パスワードを教えてしまうならば銀行内部でセキュアにしてもあまり効果がない。
19世紀から続くロイズ銀行が昔から伝統的に合言葉で電話ごしや窓口でも残高照会に
応じていたならばサービスを落としてセキュアにするのはメリットが少ない。
Re:パスワードは読取れてはいけない (スコア:1, 興味深い)
ただ、設計・開発・運用保守の包括的な視野が無いと形骸化しちゃったり。
・ハッシュ値の計算方法を知っている内部攻撃者
・パスワードは必ず数字4桁と決まっている
・誰でも全てのデータをエクスポート出来る
という条件だと、ハードルらしいハードルにならなかったりする。
(さすがに極端な事例だろうけど)
だから
・開発情報を知る人間と、本番データを知る人間を分ける
・運用者自体の認証、権限切り分け、引き出し範囲の制限
・事故時のトレーサビリティ、ログの保全
・上記を最初から考慮した設計がなされている
単に「セキュリティを高める」「ハードルならなんでも置け」ではなく、
「具体的リスクを減らす」場合によっては「リスクを受容する」という、
コストや利便性との折り合いをつける視点が必要だよね。
Re: (スコア:0)
不可逆暗号を掛けて、認証時にユーザが送って来た平文を暗号化してから認証ってのは
掲示板の投稿削除機能とかでは普通だけど、平文(若しくは可逆暗号)を送受信しない為の仕組み
APOPとかダイジェスト認証とかを使う場合は、サーバが平文を知ってる必要がありますよね。
#まぁ、可逆暗号で保存しとけば良いんでサーバ管理者が平文を目にする必要は無いんだけど。