パスワードで攻撃は防げない - Your Pa$$word doesn't matter
こんにちは、Azure Identity サポートチームの鈴木です。 本記事は Your Pa$$word doesn’t matter を意訳したものになります。ご不明点等ございましたらご連絡ください。 セキュリティに関して組織の方針を決定できる方との会話の中で 「これまでに漏洩したことがあるパスワードは絶対に再度使用するな」「長いパスワードを使用したほうがいい」「パスワードよりも長いパスフレーズを使えばいい」などなどの話題がでます。実はこれらは、これまでの研究結果と異なっており、マイクロソフトが毎日何億ものパスワードベースの攻撃を防いでいる状況から見ますと正しくありません。多要素認証 (MFA) や脅威の検出の仕組みなど本当に価値のあるものにではなく、パスワード規則に着目しても、気晴らし程度の効果しかありません。 ここでは、パスワードの構成や長さに関しては（ほとんど）意味がないというこ
「二段階認証を知らない」を笑えない理由
「安全意識は事件をきっかけに大きく変化する」といわれています。7payにまつわるインシデントは、ITセキュリティやデジタルに強い人以外にも「二段階認証」というキーワードを浸透させました。ITセキュリティ業界にとって、象徴的な事件になったといえるでしょう。 本連載は7年前、「ITなんかよく分からない、デジタルなんて関係ない」という方に向けて、それでも知ってもらいたいITの基本を伝えるためにスタートしました。連載当初、二要素認証について書きましょうと編集部に提案し、「対象読者には難しすぎる」とボツにされたのを覚えています。 しかし現在、二段階認証は、銀行やキャッシュレス決済システムを中心にさまざまなサービスで利用されています。既に身近なサービスで導入されていたため、7pay事件で初めて二段階認証という言葉を知って、すぐに「ああ、登録した電話番号に数字が送られてくるあれか」とピンと来た方もいたの
Web APIにおける認可の現状確認 2019 春 - 解せぬ日記
最近Web APIの認可について思いを馳せる機会があったのだけど、どの方法で認可を実装するのがスタンダードなのか、そもそもそんなものは最初からないのか、よく分からなくなったので自分なりの考えをまとめることにした。 ファーストパーティのアプリが使うWeb API（プライベートなWeb API）の場合はセッションを使うケースもあるだろうが、セッションを使うケースでは悩むことも少なかったので、ここではアクセストークンを用いた認可にフォーカスして考えてみたい。ケースとしてはユーザー毎にアクセストークンが発行され、Browser-BasedアプリやNativeアプリからWeb APIが叩かれることを想定している。 追記 2019/03/04 認証や認可周りについてよく拝見させてもらっている方にブログで言及していただきました。合わせて読むことをお勧めします。 ritou.hatenablog.com
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
