アカウント名:
パスワード:
> 傍受したパスワードを有効期間中にすかさず使用すると破られてしまうのですが、これは既知の脆弱性なのでしょうか^^;
プレスリリースに
一度認証に成功したパスワードは、その時点で利用できなくなりますので、万が一スパイウェア等によって入力したパスワードを盗まれてしまった場合でも、悪用されるリスクが極小化されます。
とありますが？
パスワードが入力された時点で:
というコードを追加すればいいだけですね。
# それはそれとしてOTP欲しいな
傍受してから60秒以内かつ傍受された人よりも早く 入力して初めて「破られる」。
「傍受」、というのはどういう状態でしょうか？
ユーザからシステムに送信する際のものを傍受、となると、途中経路上でパケットをとめない限り、傍受者の方が早くなることは難しいのではないでしょうか？
逆の経路（システムからユーザ）への送信というのは、場合は存在しないですよね？
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
日々是ハック也 -- あるハードコアバイナリアン
ナマケモノ、じゃなかった (スコア:3, すばらしい洞察)
傍受したパスワードを有効期間中にすかさず使用すると破られてしまうのですが、これは既知の脆弱性なのでしょうか^^;
あと、プレスリリースではRSA SecurID 700を採用とも書いてありますが、入力するパス桁数が６桁と図解されており、RSA SecurID 200やRSA SecurID 520にならないのかなぁ？という気がするんですけど、どうなんですかね？
＃無料でトークン配るとは思えないのだけど「いくらかかる」が書いてないのはナゼ？？
＃無料なら、みずほから乗り換えたいな
Re:ナマケモノ、じゃなかった (スコア:3, 参考になる)
> 傍受したパスワードを有効期間中にすかさず使用すると破られてしまうのですが、これは既知の脆弱性なのでしょうか^^;
プレスリリースに
とありますが？
Re:ナマケモノ、じゃなかった (スコア:2, 参考になる)
(職場で使っているのでAC)
リスクが極小化? (スコア:0)
パスワードが入力された時点で:
というコードを追加すればいいだけですね。
# それはそれとしてOTP欲しいな
Re:リスクが極小化? (スコア:1)
時間は相当かかるだろうけど、法人相手なら使えない手では無い。
Re:リスクが極小化? (スコア:1)
#個人的にActiveXとかでできる気がしてたまらない
##さらに作ってみたいという気がしてたまらない
Re:リスクが極小化? (スコア:0)
どこに？
Re:ナマケモノ、じゃなかった (スコア:2, 参考になる)
ニュースリリースの2ページ目に書いてありますよ．
#最初次のページがあるとは気づきませんでしたが．
初期費用ゼロ，月額105円だそうで．
Re:ナマケモノ、じゃなかった (スコア:1, 参考になる)
デフォルトなのかサーバの設定なのかは知りませんが、今私が使ってるやつでは一度認証を試みたらSecureIDの表示が変わるまで現在表示されているパスワードは無効になります。
要するに1分に1回しか挑戦できず、間違えたら1分待つ必要があります。
Re:ナマケモノ、じゃなかった (スコア:0)
>と破られてしまうのですが、これは既知の脆弱性なのでしょうか^^;
傍受してから60秒以内かつ傍受された人よりも早く
入力して初めて「破られる」。
可能性は０では無いのですが先取りした時点で正規者には
入力しようとしてたパスワードが無効となってしまうので
タイムアウトか傍受されているかのどちらかとわかる。
早めの察知・対処ができるのがせめてもの言い訳となるでしょうか。
トークンの有効期限は60秒ではありません。 (スコア:1, 興味深い)
電波時計と言うソリューションは今後あり得るなぁ
＃絶対AC
Re:トークンの有効期限は60秒ではありません。 (スコア:4, 参考になる)
そのため、サーバ側は 60秒よりも少し余裕を持って、前後のOTPとの突き合わせをしているようです。
また、トークンと認証サーバの同期ずれが広がった場合は、認証サーバが再認証を要求します。
(認証サーバの要求をアプリケーションがどう処理するかは実装依存)
利用者は入力したOTPが変わるまで待ち(最長１分)、新しいOTPを入力することになります。
二回目のPIN、OTPが正しければ、サーバ側でトークンとの時間のずれを調整するようです。
---
(RSAの中の人ではないので調整方法は予想で書いてます)
Re:トークンの有効期限は60秒ではありません。 (スコア:0)
Re:トークンの有効期限は60秒ではありません。 (スコア:0)
Re:ナマケモノ、じゃなかった (スコア:0, 余計なもの)
「傍受」、というのはどういう状態でしょうか？
ユーザからシステムに送信する際のものを傍受、となると、途中経路上でパケットをとめない限り、傍受者の方が早くなることは難しいのではないでしょうか？
逆の経路（システムからユーザ）への送信というのは、場合は存在しないですよね？