アカウント名:
パスワード:
どこの段階で防ぐべきだっただろうか。
・cookieを盗まれない → 未知の脆弱性もあるだろうし、ここで100%防衛は無理。・チャットでITサポート担当者に携帯電話をなくしたとメッセージを送って多要素認証トークンを入手 → やっぱここか。
「携帯電話無くしたんだけど」ってオレオレ詐欺ばりの手口にひっかかるのがダメってことか。うちの会社だと、社内で受け取りか、社内システムに事前登録した住所への送付しか選択肢が無い。
cookie（トークン）の期限を短くするのは？
短期間で何度も客にログインさせると客離れ増えるからそれはできないんだよな
再アクセス時に再発行でいいんじゃないかな？有効期限は3日ぐらいにすれば週末あっても大丈夫3連休あると期限切れになるけど
それ犯罪者も3日ごとに再発行を受けて半永久的にcookieの期限延ばせちゃうから逆に危険じゃね正当な利用者だけが割を食うことに
短期間にしておくは基本。今回みたいなケースだと十分有効だろ。それに長ければ延々使われる状態になるのは変わりはない。
OAuth 2.0みたいに、再発行には隠し持っている別の認証情報（リフレッシュトークン）を要求するというのはどうだろうか。
盗まれてから3日以内にアクセスすることが出来ればだがノートPCから抜きとって、ネットで販売して購入されて使われての期間が3日だと凄く厳しいかと
クッキーに再発行の回数記憶するとかもちろん再発行時の情報（IPアドレスやエージェントなど）を記録しておいてチェックするなどやり方はあるかと
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
吾輩はリファレンスである。名前はまだ無い -- perlの中の人
どこで防ぐべきか (スコア:1)
どこの段階で防ぐべきだっただろうか。
・cookieを盗まれない
→ 未知の脆弱性もあるだろうし、ここで100%防衛は無理。
・チャットでITサポート担当者に携帯電話をなくしたとメッセージを送って多要素認証トークンを入手
→ やっぱここか。
「携帯電話無くしたんだけど」ってオレオレ詐欺ばりの手口にひっかかるのがダメってことか。
うちの会社だと、社内で受け取りか、社内システムに事前登録した住所への送付しか選択肢が無い。
Re: (スコア:0)
cookie（トークン）の期限を短くするのは？
Re: (スコア:0)
短期間で何度も客にログインさせると客離れ増えるからそれはできないんだよな
Re: (スコア:0)
再アクセス時に再発行でいいんじゃないかな？
有効期限は3日ぐらいにすれば週末あっても大丈夫
3連休あると期限切れになるけど
Re:どこで防ぐべきか (スコア:0)
それ犯罪者も3日ごとに再発行を受けて半永久的にcookieの期限延ばせちゃうから逆に危険じゃね
正当な利用者だけが割を食うことに
Re: (スコア:0)
短期間にしておくは基本。
今回みたいなケースだと十分有効だろ。
それに長ければ延々使われる状態になるのは変わりはない。
Re: (スコア:0)
OAuth 2.0みたいに、再発行には隠し持っている別の認証情報（リフレッシュトークン）を要求するというのはどうだろうか。
Re: (スコア:0)
盗まれてから3日以内にアクセスすることが出来ればだが
ノートPCから抜きとって、ネットで販売して購入されて使われての期間が3日だと凄く厳しいかと
クッキーに再発行の回数記憶するとか
もちろん再発行時の情報（IPアドレスやエージェントなど）を記録しておいてチェックするなどやり方はあるかと