![なりすましメール対策にドメイン認証技術「DMARC」導入を、日本では85%が未導入 ウイルス添付の迷惑メールを防ぐ工夫をIIJが解説](https://cdn-ak-scissors.b.st-hatena.com/image/square/4489e5a50dd885e6e1a6d1495f5b95ddfcf9e6fe/height=288;version=1;width=512/http%3A%2F%2Finternet.watch.impress.co.jp%2Fimg%2Fiw%2Flist%2F1025%2F270%2Fiij00.jpg)
【これは約 16 分の記事です】 (2015年の投稿のため、リンク切れや情報が古くなっている部分が一部ございます) 定期的なパスワード変更を奨めるサービス提供者や行政 ID・パスワードが流出する事件を受け、提供者や行政提供者側からユーザに対してセキュリティ対策の実施を喚起しています。 IDとパスワードの適切な管理 :警視庁(リング切れ) この中で、「パスワードの定期的変更」がうたわれています。このパスワードの定期変更については、セキュリティ対策として余り有効ではないという方は結構いらっしゃいます。 パスワードの定期的変更に関する徳丸の意見まとめ http://tumblr.tokumaru.org/post/38756508780/about-changing-passwords-regularly 実際、パスワードはどれくらいの頻度で変えるべきですか? | ライフハッカー[日本版] ht
■背景 自社のサーバと通信する自社アプリについて、本来不要であるにも関わらず他社であるCAに認証情報の管理を委託することが多いわけですが、CAが証明書を誤発行した結果情報漏洩が発生したとして、その責任は自社にはないと主張できるのか、もう一度考えなおしたほうがいいんじゃないかと思うんです — Kazuho Oku (@kazuho) July 15, 2014 .@ockeghem @smbd @ando_Tw スマホアプリの提供においてはコードの署名鍵を安全に管理することが求められますが、その前提において通信相手の認証管理をCAに委託することにどれほどの意味があるんでしょう — Kazuho Oku (@kazuho) July 14, 2014 ■他社CAは信頼できるのか 特定のCAにpinningするのはしないより安全だけど、そもそも誤発行しないCAなんてあるのかという議論は重要。見知
ものすごく遅いレポートですが、先日、ゆるふわ勉強会こと さしみjp ささみjpの#ssmjp 2014/06 に参加させて頂きました。 この中で、@togakushiさんの発表「OpenSSH User EnumerationTime-Based Attack と Python-paramiko」が面白かったのでそのメモです。 osuetaとは何か OpenSSHでは、パスワード認証の際に長い文字列(目安で数万文字)を与えると、存在するユーザと存在しないユーザの場合で応答速度が変わってきます。環境によりこの時間差は結構違うようですが、私の試した範囲では、 存在するユーザの場合は数十秒 存在しないユーザの場合は数秒 で応答が返りました(この応答速度は目安です、もちろんマシンスペックによって違うでしょう)。これにより、複数のユーザでsshログイン試行をおこない、その応答時間を計測することでユー
*追記*:こちらは2013年の記事であり、現在のサービスではSMS認証を回避できない場合が多いです。ご使用の際はご注意ください。 最近ではウェブサービスやアプリを使う際のアカウント登録で、『SMSで認証』が必要なことがあります。SMSの電話番号を入力し、そこへ認証コードが送られてくる、という物ですね。 ただこの方法では、電話番号を持っているのが前提であり、iPod touchやiPadのみしか持っていない場合には使用出来ません。それに、いくら信頼出来る企業だったとしても、電話番号を一瞬でも渡すという事もあまり気持ちの良い物ではありませんよね。 私もちょうどYouTubeのアカウント確認でSMS認証が必要になってしまいましたので、自分の電話番号を使わない別の解決策を行ってみたいと思います。 ということで、無料で出来る「SMS用の電話番号」を取得する方法!を見ていきたいと思います。(ほぼ私用の
Webサイトのパスワード認証を狙った攻撃が大きな脅威になっています。 Tサイト(プレスリリース) goo(プレスリリース) フレッツ光メンバーズクラブ(プレスリリース) eBook Japan(プレスリリース) My JR-EAST(プレスリリース) これらの事例のうちいくつか(あるいは全て)は、別のサイトで漏洩したIDとパスワードの一覧表を用いた「パスワードリスト攻撃(後述)」であると考えられています。パスワードリスト攻撃を含めて、パスワードを狙った攻撃が成立してしまう原因は、利用者のパスワード管理に問題がある場合が多く、攻撃を受けたWebサイト側には、直接の責任はないケースが多いと考えられます。 しかしながら、 大半の利用者はパスワード管理に興味がない パスワード認証を採用している理由は、コスト上の理由、すなわちサイト側の経済的な事情 インターネットが「とても危険なもの」となるとネット
このエントリでは、Webアプリケーションにおけるログアウト機能に関連して、その目的と実現方法について説明します。 議論の前提 このエントリでは、認証方式として、いわゆるフォーム認証を前提としています。フォーム認証は俗な言い方かもしれませんが、HTMLフォームでIDとパスワードの入力フォームを作成し、その入力値をアプリケーション側で検証する認証方式のことです。IDとパスワードの入力は最初の1回ですませたいため、通常はCookieを用いて認証状態を保持します。ログアウト機能とは、保持された認証状態を破棄して、認証していない状態に戻すことです。 Cookieを用いた認証状態保持 前述のように、認証状態の保持にはCookieを用いることが一般的ですが、Cookieに auth=1 とか、userid=tokumaru などのように、ログイン状態を「そのまま」Cookieに保持すると脆弱性になります
もう面倒なユーザ認証機能は1から作らなくてよいかも?PHPのOSS「AuthManager」 2012年08月13日- AuthManager - StitchApps もう面倒なユーザ認証機能は1から作らなくてよいかも?PHPのOSS「AuthManager」。 ユーザ認証型のサイトを1から作るとなると面倒な上に、もう誰かが良い物を作ってるんじゃないかという事を誰もが作り直してる気がします。 こういうもの自体をオープンソースにしちゃって誰もが使えるっていうのは素晴らしいですね。 Facebookによる認証やreCAPTCHAによるスパム防止、メールアドレスの認証機能といった標準で必要な機能が入っており、便利に使えそう。 で、ユーザ登録できるのはいいんだけど、肝心の制限はどうやってかけるの?というところは、次のように簡単にやってね、ということらしくお手軽。 ($sesslife自体がどこか
(UPDATE1) Yahoo! Voice と Yahoo! Voices は別のサービスらしいので、そこをUPDATEしました。なお、結論は変わりません→ってことは、Yahoo! Voice も気をつけて対処したほうが良いってことですよ…。 米 Yahoo! からパスワードが流出したと大騒ぎである。 米Yahoo!は長らくビジネス的問題を抱えていて、多くの人材が流出していてシステムメンテに手が回らなくなっているので、「あー、ついにやってしまったか」と最初にニュースに接した時には思った。最近は、認証は専門部隊を持っているところに任せましょうという講演をあちこちでして回っているのだが、認証プロバイダ(Identity Provider, IdP) もやっている Yahoo! がこれをやってしまったというのは、個人的にも非常にインパクトが大きい[1]。 実際、この分野に造詣の深い Evolu
In some of the feedback I have gotten on the openID Connect spec, the statement is made that Connect is too complicated. That OAuth 2.0 is all you need to do authentication. Many point to Identity Pro… 英語読みたくないという人のために簡単に解説すると… OAuth 2.0 の implicit flow を使って「認証」をしようとすると、とっても大きな穴が開きます。 カット&ペーストアタックが可能だからです。 OAuth 認証?は、図1のような流れになります。 図1 OAuth 認証?の流れ 一見、問題なさそうに見えます。しかし、それはすべてのサイトが「良いサイト」ならばです。 Site_A
これまでTwitterのOAuth認証にはアクセスレベルが「Readのみ」「ReadとWrite」という2段階しかなく、認証を許可してしまうとダイレクトメッセージの内容までアプリケーション側から読めてしまうという問題がありましたが、ようやくこの問題が解決するようです。 Beginning today, we’re giving you more control over what information you share with third-party applications. Apps that you use to access your direct messages will ask for your permission again. » Twitter Blog: Mission: Permission 公式にアナウンスされているように、Twitterアプリケーションのア
昔から、「OpenIDは認証でOAuthは認可だ」などということが言われます。しかし、その言語の意味を取り違えている方が結構多い気がしています。「もうOpenIDなんていらね。OAuthだけでいいじゃん」というような言説がよく流れてくるのがその証拠だと思います。OAuth認証というのもその類ですね。 そこで、今日はOAuthとOpenIDの違いを考えてみたいと思います。 Youtube版 OpenIDは紹介状、OAuthは合鍵 まずはOpenIDの概要の復習です。「OpenIDは認証」という言葉の内容をまずは復習してみましょう。 「認証」とは大変広い言葉でいろいろな場面で使われますが、「OpenIDは認証」という使い方の時は、「OpenIDは、いま来ている人の身元を認証」(ユーザ認証)という意味です。図にすると図1のような流れになります。 この例では、有栖さんがお客としてサービス提供をして
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く