アカウント名:
パスワード:
携帯対応・変なファイヤーウォールを無視できるとして、今回の件では関係ないものもありますが、対策はこんな感じでしょうか。専門家の方もxxはyyが悪いというばかりで、対策をまとめてくれないのでよくわからんのですよね。ベーシック認証、クライアント証明は考慮外です。
step0: ログインIDとパスワードをURLに含めて持ち歩くのをやめるstep1: パスワード送信をPOSTにしてPOSTのみ受け付けるstep2: ログイン画面以外は、パスワードを利用せずにcookieを使うstep3: 全コンテンツでTLS・有効で信頼済みの認証局発行のサーバー証明書を使うstep4: cookieにはsecureフラグを立てるstep5: cookieには基本的にセッションIDのみを保存するstep6: セッションIDをjsessionidやphpsessionidなどでURIに含めない。受け付けない。(NG例:ぐぐる)step7: セッションIDには推測されない一時的に生成されるIDのみを使う(NG例:JVN#07468800)step8: ログイン前後でセッションIDを共有しないstep9: パスワードを変更したら、サーバー側で古いセッションIDを無効にする(NG例:twitterのidのっとり事件)step10: パスワード再確認などを併用してセッションIDのサーバ側有効期間を短くする(例:yahoo)step11: ログインIDとユーザーIDを分離する(例:mixi/ねとげ)step12: ログイン追跡機能をつける(例:unixのlast login/yahooの履歴)その他1: サーバー側のDBでのパスワード保存は、saltつきのハッシュ値などにするその他2: CSSXSS/CSRF/XSS対策、正しいエスケープ処理をするその他3: 簡単ログインを実装しないその他4: メールでのパスワードリセット・確認はメールアドレスの生存期間を考慮した仕様にする(NG例:iTunes)その他5: 脆弱性が公表されているバージョンのソフトウェアを使わない
専門家の方もxxはyyが悪いというばかりで、対策をまとめてくれないのでよくわからんのですよね。
# これはがくっときてしまう人多そう…。
たとえば、IPAではこんなのを用意しています。これで完全だとは言いませんが、指針として目を通しておいたほうがよいでしょう。
安全なウェブサイトの作り方 [ipa.go.jp]
># これはがくっときてしまう人多そう…。確かにIPAの存在も忘れてましたが、法人ではなくて個人を想像したコメントでした。IPAがまとめてくれているので、個人でまとめる必要はないわけですね。プログラミングガイドとかも、そういえばIPAでした。
脆弱性でデータ流出とかは話題になって(個人的には)記憶に残りやすいです。一方「IPAが仕事しました」というのは、内容がおかしかったら話題になるけど、内容がまともすぎて、話題・記憶に残りにくいのかもしれません。blogとかで紹介するときも、「IPAがまとめています→リンク。参考になります。」という感じで触れられるだけですから、後で読もうと思ってリンクをたどらず、つい読み飛ばしてそのうち忘れます。
現場で、「IPAのこれ読んで」とか上に言われて渡されたりするのか、もしくは上の人は、渡したり確認したりしているんでしょうか。
#ここはひとつ、萌えキャラで擬人化してみんなに覚えてもらうというのはどうだろう。
あと利用者側の対策もね。安全なWebサイト利用の鉄則 [aist.go.jp]
その他6:Web屋に任せずカード屋の決済サービスを使う。
ログイン管理というより、管理用のページを誰でもアクセスできる公開サーバに設置したのが問題かなと思えます。
1.公開サーバと管理用のページがあるサーバを分ける。 外から絶対にアクセスできず、 VPN経由等でしかアクセスできないようなサーバにのみ管理用のページを設置する。 (複数代構成ができるならこんな感じ？)
2.それが無理なら、管理用のページをポートを変更したSSLを立ててIPアクセス制限 IPアドレス制限で接続元を縛る。 HTTPで情報をやり取りしたくないので、SSLで暗号化(この場合は暗号化が目的なのでオレオレ証明でも問題ない
オレオレ証明書を使うと暗号化の意味がないと思いますよ。
管理画面にアクセスするPCを制限できるのであれば、意味が無いこともないと思いますよ。アクセスする前にオレオレサーバ証明書なりオレオレCA証明書をそれらのPCにインストールしたり、フィンガープリントで確認する手順を徹底したりできるでしょうから。
パスワードを使わずTLSなんかでクライアント認証
TLS(SSL)クライアント認証は、技術的には理想的な解だと思うんだけど、実用上は問題があるんだよね。まず、仕組みが一般人には理解しにくいこと。なぜそれで安全と言えるのか、ということが理解できないと、正しい利用も難しい。次に、パスワードみたいにこっちのPCでもあっちのPCでも使える、と言うわけにはいかないところ。これは技術的な問題でもあるんだけど。これを解決するために、あっちのPCにもこっちのPCにもクライアント証明書をインストールして回る、という手も無くはないけど、それだと、
パスワードめんどくさい
から、パスワードをあちこちのPC(の認証情報マネージャ)に保存して回る、というのと変わらないんだよね。
2000円程度で標準仕様な簡易スマートキーが量販店で売ってれば良い。
仕組みの理解できないものに、2000円も払うだろうか？電子マネーですら、いろんなポイント優遇なんてものがあって普及が進んだことを考えれば、初期投資2000円で目に見えた(理解できる)メリットが無い、というのはいかにも高い気がする。
しかも、数年に一回程度の更新が必要だし、そのための認証局の運用だってコストがかかる。例えば、VeriSignのBMS証明書・クライアントのが14,385円/3年間。まあ、VeriSignはオーバースペックだろうと思うけど、半分だったとしても、素直にコストをスマートキーに載せれば、2000円/年すら不可能ってことがわかるね。
よほど巧く考えられたビジネスモデルがないと実現不可能なんじゃないかな？
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
あつくて寝られない時はhackしろ! 386BSD(98)はそうやってつくられましたよ? -- あるハッカー
webのログイン管理的なもの (スコア:3, 参考になる)
携帯対応・変なファイヤーウォールを無視できるとして、今回の件では関係ないものもありますが、対策はこんな感じでしょうか。
専門家の方もxxはyyが悪いというばかりで、対策をまとめてくれないのでよくわからんのですよね。
ベーシック認証、クライアント証明は考慮外です。
step0: ログインIDとパスワードをURLに含めて持ち歩くのをやめる
step1: パスワード送信をPOSTにしてPOSTのみ受け付ける
step2: ログイン画面以外は、パスワードを利用せずにcookieを使う
step3: 全コンテンツでTLS・有効で信頼済みの認証局発行のサーバー証明書を使う
step4: cookieにはsecureフラグを立てる
step5: cookieには基本的にセッションIDのみを保存する
step6: セッションIDをjsessionidやphpsessionidなどでURIに含めない。受け付けない。(NG例:ぐぐる)
step7: セッションIDには推測されない一時的に生成されるIDのみを使う(NG例:JVN#07468800)
step8: ログイン前後でセッションIDを共有しない
step9: パスワードを変更したら、サーバー側で古いセッションIDを無効にする(NG例:twitterのidのっとり事件)
step10: パスワード再確認などを併用してセッションIDのサーバ側有効期間を短くする(例:yahoo)
step11: ログインIDとユーザーIDを分離する(例:mixi/ねとげ)
step12: ログイン追跡機能をつける(例:unixのlast login/yahooの履歴)
その他1: サーバー側のDBでのパスワード保存は、saltつきのハッシュ値などにする
その他2: CSSXSS/CSRF/XSS対策、正しいエスケープ処理をする
その他3: 簡単ログインを実装しない
その他4: メールでのパスワードリセット・確認はメールアドレスの生存期間を考慮した仕様にする(NG例:iTunes)
その他5: 脆弱性が公表されているバージョンのソフトウェアを使わない
Re:webのログイン管理的なもの (スコア:5, 参考になる)
# これはがくっときてしまう人多そう…。
たとえば、IPAではこんなのを用意しています。これで完全だとは言いませんが、指針として目を通しておいたほうがよいでしょう。
安全なウェブサイトの作り方 [ipa.go.jp]
Re:webのログイン管理的なもの (スコア:1)
># これはがくっときてしまう人多そう…。
確かにIPAの存在も忘れてましたが、法人ではなくて個人を想像したコメントでした。
IPAがまとめてくれているので、個人でまとめる必要はないわけですね。
プログラミングガイドとかも、そういえばIPAでした。
脆弱性でデータ流出とかは話題になって(個人的には)記憶に残りやすいです。
一方「IPAが仕事しました」というのは、内容がおかしかったら話題になるけど、内容がまともすぎて、話題・記憶に残りにくいのかもしれません。
blogとかで紹介するときも、「IPAがまとめています→リンク。参考になります。」という感じで触れられるだけですから、
後で読もうと思ってリンクをたどらず、つい読み飛ばしてそのうち忘れます。
現場で、「IPAのこれ読んで」とか上に言われて渡されたりするのか、もしくは上の人は、渡したり確認したりしているんでしょうか。
#ここはひとつ、萌えキャラで擬人化してみんなに覚えてもらうというのはどうだろう。
Re: (スコア:0)
あと利用者側の対策もね。
安全なWebサイト利用の鉄則 [aist.go.jp]
Re: (スコア:0)
その他6:Web屋に任せずカード屋の決済サービスを使う。
Re: (スコア:0)
ログイン管理というより、管理用のページを誰でもアクセスできる公開サーバに設置したのが問題かなと思えます。
1.公開サーバと管理用のページがあるサーバを分ける。
外から絶対にアクセスできず、
VPN経由等でしかアクセスできないようなサーバにのみ管理用のページを設置する。
(複数代構成ができるならこんな感じ？)
2.それが無理なら、管理用のページをポートを変更したSSLを立ててIPアクセス制限
IPアドレス制限で接続元を縛る。
HTTPで情報をやり取りしたくないので、SSLで暗号化(この場合は暗号化が目的なのでオレオレ証明でも問題ない
Re: (スコア:0)
オレオレ証明書を使うと暗号化の意味がないと思いますよ。
なぜなら、パケットを盗聴できる状況ではMIM攻撃でパスワードを盗むことも可能でしょうから。
Re:webのログイン管理的なもの (スコア:1)
オレオレ証明書を使うと暗号化の意味がないと思いますよ。
管理画面にアクセスするPCを制限できるのであれば、意味が無いこともないと思いますよ。アクセスする前にオレオレサーバ証明書なりオレオレCA証明書をそれらのPCにインストールしたり、フィンガープリントで確認する手順を徹底したりできるでしょうから。
Re: (スコア:0)
パスワードめんどくさい。
SSHでパスワード認証使ってる? なんで? と考えてみれば。
Re:webのログイン管理的なもの (スコア:1)
パスワードを使わずTLSなんかでクライアント認証
TLS(SSL)クライアント認証は、技術的には理想的な解だと思うんだけど、実用上は問題があるんだよね。
まず、仕組みが一般人には理解しにくいこと。なぜそれで安全と言えるのか、ということが理解できないと、正しい利用も難しい。
次に、パスワードみたいにこっちのPCでもあっちのPCでも使える、と言うわけにはいかないところ。これは技術的な問題でもあるんだけど。
これを解決するために、あっちのPCにもこっちのPCにもクライアント証明書をインストールして回る、という手も無くはないけど、それだと、
パスワードめんどくさい
から、パスワードをあちこちのPC(の認証情報マネージャ)に保存して回る、というのと変わらないんだよね。
Re: (スコア:0)
今なら特にUSBサポートしないマイコンでも力技でUSB信号出せるんだし、マイコン1石なら十分その程度で作れるはずなんだが・・・
Re:webのログイン管理的なもの (スコア:1)
2000円程度で標準仕様な簡易スマートキーが量販店で売ってれば良い。
仕組みの理解できないものに、2000円も払うだろうか？
電子マネーですら、いろんなポイント優遇なんてものがあって普及が進んだことを考えれば、初期投資2000円で目に見えた(理解できる)メリットが無い、というのはいかにも高い気がする。
しかも、数年に一回程度の更新が必要だし、そのための認証局の運用だってコストがかかる。例えば、VeriSignのBMS証明書・クライアントのが14,385円/3年間。まあ、VeriSignはオーバースペックだろうと思うけど、半分だったとしても、素直にコストをスマートキーに載せれば、2000円/年すら不可能ってことがわかるね。
よほど巧く考えられたビジネスモデルがないと実現不可能なんじゃないかな？