タグ

authに関するf99aqのブックマーク (9)

  • よくわかる認証と認可 | DevelopersIO

    よく訓練されたアップル信者、都元です。「認証 認可」でググると保育園の話が山程出て来ます。が、今日は保育園の話ではありません。そちらを期待した方はごめんなさい。こちらからお帰りください。 さて、先日のDevelopers.IO 2016において、マイクロWebアプリケーションというテーマでお話させて頂きました。一言で言うと OAuth 2.0 と OpenID Connect 1.0 のお話だったのですが、これらを理解するにあたっては「認証」と「認可」をはっきりと別のものとしてクッキリと認識する必要があります。 まず、ざっくりとした理解 認証と認可は密接に絡み合っている一方で全く別の概念です。正直、理解は簡単ではないと思います。 まず「認証」は英語では Authentication と言います。長いので略して AuthN と書いたりすることもあります。意味としては 通信の相手が誰(何)であ

    よくわかる認証と認可 | DevelopersIO
  • iOSのTwitter統合とAndroidのAccountManager、そしてBrowserIDに見るUser-Centric Identityの再来?について - snippets from shinichitomita’s journal

    最近、自分自身のテクノロジー的な世界観に対して影響を与える刺激がいろいろとあったわけだけど、その中におぼろげながら共通点が感じられたので、最初はGoogle+にLimitedなメモとして書いたのだが、ブログの方に清書する。 - 最初のきっかけは、AppleのiOS5へTwitter APIが組み込まれる、というニュースだった。それはTwitterサービスにiOSの提供するAPIを通してアクセスでき、その際の認証はOSが代行してくれる、というものだ。それが基調講演で発表された時には「なんでそこにOSが絡まなきゃいけないのか、オープンスタンダードなやり方があるのだからいいじゃないか」という理由で否定的に受け取ったわけだけども、よくよく考えてみれば位置情報でもストレージでも、リソースへのアクセス許可に対して承認許可ダイアログをOSが出しているわけだし、それがWebサービスでもまあありかもな、と考

    iOSのTwitter統合とAndroidのAccountManager、そしてBrowserIDに見るUser-Centric Identityの再来?について - snippets from shinichitomita’s journal
  • livedoor Authの運営終了のお知らせ

    livedoor Authの運営終了のお知らせ 2021年3月末をもちまして、livedoor Authの運営を終了いたしました。 長きに渡りご愛顧をいただきまして、誠にありがとうございました。 livedoorホームへ戻る

  • WebService-Livedoor-Auth-0.01 - [One line description of module's purpose here] - metacpan.org

    The Perl Toolchain Summit needs more sponsors. If your company depends on Perl, please support this very important event.

  • まちがった自動ログイン処理

    (Last Updated On: 2018年8月20日)問題:まちがった自動ログイン処理の解答です。このブログエントリは最近作られたアプリケーションでは「問題」にしたような実装は行われていないはず、と期待していたのですがあっさり期待を破られたのでブログに書きました。このブログの方が詳しく書いていますけが「Webアプリセキュリティ対策入門」にも正しい自動ログイン処理を書いています。 参考:自動ログイン以外に2要素認証も重要です。「今すぐできる、Webサイトへの2要素認証導入」こちらもどうぞ。HMACを利用した安全なAPIキーの送受信も参考にどうぞ。 間違った自動ログイン処理の問題点 まず間違った自動ログイン処理を実装しているコードの基的な問題点を一つ一つ順番にリストアップします。 クッキーにランダム文字列以外の値を設定している クッキーにユーザ名が保存されている クッキーにパスワードが保

    まちがった自動ログイン処理
  • HMAC - Wikipedia

    HMAC-SHA1の生成 HMAC (Hash-based Message Authentication Code または keyed-Hash Message Authentication Code) とは、メッセージ認証符号 (MAC; Message Authentication Code) の一つであり、秘密鍵とメッセージ(データ)とハッシュ関数をもとに計算される。 1997年2月、IBMのKrawczykらにより提唱され、RFC 2104として公開されている。また、FIPS PUB 198にも採用されている。 概要[編集] MACは認証及び改竄検出技術の核となるアルゴリズムである。HMACアルゴリズムは、MAC値(タグ)の算出に暗号学的ハッシュ関数を用いる。ハッシュ関数としては、SHA-2やSHA-3など任意の繰返し型ハッシュ関数を適用可能であり、ハッシュ関数Xを用いるHMAC

    HMAC - Wikipedia
  • HMAC: Keyed-Hashing for Message Authentication

    H. Krawczyk IBM M. Bellare UCSD R. Canetti IBM 1997年 2月 HMAC: メッセージ認証のための鍵付ハッシング (HMAC: Keyed-Hashing for Message Authentication) このメモの位置付け このメモは、インターネット・コミュニティに対して情報を提供するものである。このメモは、何らインターネットの標準を規定するものではない。このメモの配布に制限はない。 要旨 この文書では、暗号ハッシュ関数を使用してメッセージ認証を行なう仕組みである HMAC について記述する。HMAC は、MD5 や SHA-1 などの反復暗号ハッシュ関数を秘密の共有鍵と組み合わせて使用する。HMAC の暗号としての強度は、使用しているハッシュ関数のプロパティに依存する。 1.はじめに 信頼できないメディア上を伝送し、蓄積される情報の

  • Kazuho@Cybozu Labs: Hash ≠ MAC

    « Re: はてな認証 API | メイン | 秘密鍵を後置している MAC の危険性 » 2006年05月07日 Hash ≠ MAC ハッシュ関数を MAC (メッセージ認証コード; いわゆる秘密鍵による署名) として使用していけません、という件について。 HMAC の論文を見たところ、様々な攻撃手法について述べてありました。ちなみに、今回のケースは、 Extension Attack です。引用すると、 Consider the "prepend-only" construction: MACk(x) = F(k, x) (i.e., the key k is prepended to the data x and the hash function - with the fixed IV - computed on the concatenated information). Be

  • Kazuho@Cybozu Labs: Re: はてな認証 API

    « はてな認証 API | メイン | Hash ≠ MAC » 2006年05月06日 Re: はてな認証 API naoya さんありがとうございます、ということで、「認証APIのメモについてのレス」への返答です。 2006/5/7 追記: 1) で述べた MD5 による api_sig の偽装が可能であることを確認しました。この偽装を用いた攻撃は、auth.json および auth.xml については、1) に述べたとおり成功しません。認証リンクについては、仕様として任意のパラメータをハンドリングできる必要があるので、攻撃が成立してします (攻撃者がパラメータを追加することができる)。 よって、認証リンクの署名機能は壊れている、と言わざるを得ないように思います。 3) パラメータ指定の手法について 先にこちらから。 パラメータ指定は先日サポートしました。http://auth.ha

  • 1