Qiita上で「ゲームでよくされるチート手法とその対策 〜アプリケーションハッキング編〜」という記事がいいね数を集めているようですが、全セクションにツッコミどころがあるような印象です。私はセキュリティ本職というわけではありませんが、素人の私から見てもひどいと思ったところだけ個別にツッコミを入れてみます。 念のため補足しておくと、誰であろうと情報発信すること自体は大変良いことです。ただ、誤りを含んだ文章がウッカリ注目されてしまうとそれを信じてしまう人も出てくるので、大人げないと思いつつツッコミを入れる次第です。 デコンパイル(逆コンパイル) 2.の詳しい解説として、C/C++で記述されたコードをコンパイルすると機械語に変換されます。これを逆コンパイルしても、逆アセンブラまでにしかなりません。そのため、この状態ではソースコードの中身を解析するのは(人間では)非常に困難なため、ネイティブコードで

『クラウドを支えるこれからの暗号技術』 本書は公開鍵暗号に続く、新しい暗号技術を紹介します。 対象読者 『暗号技術入門』（結城浩）を読んで最先端暗号理論はどうなってるのだろうと興味を持った方 「入門書に載っているRSA暗号は安全ではないので使ってはいけない」ということを知らない方 Hash(secret key||message)で認証してはいけない理由（SHA-2とSHA-3の違い）を知りたい方 楕円曲線暗号の楕円曲線を直感的に把握したい方 最近ちょいちょい聞く「準同型暗号」って何だろうと思っている方 楕円曲線といえばy2 = x3 + ax + bという式が唐突に出てくるけど何故なのと疑問に思った方 EdDSAって何? ECDSAの書き間違い?と思ったらEdwards曲線が出てきて、それ何だろうと思った方 暗号で使われる数学の話をきちんと理解したい方 などなど。 購入 秀和システム 正

はじめに SSL/TLSについて改めて理解を深めたい思い、関連する技術についてまとめました。 本記事はTLSに関すること主題として、HTTPS、暗号化、Apache、OpenSSL等について記載しています。 SSL/TLSの通信は色々なプロトコルや暗号化方式が組み合わされ補いあってできています。暗号化の仕組みはパズルのようで面白いです。一つ一つを読み取り理解が深まるごとで、SSL/TLSって本当によくできると思いました。フレームワークの意味について考えさられます。 HTTPSの通信 HTTPSの通信はTCP/IPプロトコルスイートとして、TCPの上層にSSL/TLSがあり、アプリケーションプロトコルのHTTPプロトコルが載って通信をしています。 コネクションとセッションは通信の概念として別になります。TCPでクライアントからWebサーバに対してコネクション(経路)が確立され、その上でセッシ

安全で堅牢なWebアプリケーションをクラウドで開発するのは 非常に困難 です。それを簡単だと思っているような人は、例えばとんでもない頭脳をお持ちというなら別ですが、遠からず痛い目を見ることになるでしょう。 もし MVP（Minimal Viable Product：必要最低限の機能を備えた製品） のコンセプトを鵜呑みにして、有益かつ安全な製品を1ヶ月で作成できると考えているようなら、プロトタイプを立ち上げる前に一度考え直した方がいいと思います。以下に挙げたチェックリストをご覧いただければ、セキュリティに関するクリティカルな問題の多くをスキップしていることが分かるはずです。あるいは少なくとも、潜在的なユーザに対しては 誠実 であるように心がけ、製品が完全ではないこと、そしてセキュリティが不十分な製品を提供していることを伝えるようにしてください。 このチェックリストはシンプルなもので、決して完

RFC 6749 (The OAuth 2.0 Authorization Framework) で定義されている 4 つの認可フロー、および、リフレッシュトークンを用いてアクセストークンの再発行を受けるフローの図解及び動画です。動画は YouTube へのリンクとなっています。 English version: Diagrams And Movies Of All The OAuth 2.0 Flows 追記 (2019-07-02) 認可決定エンドポイントからクライアントに認可コードやアクセストークンを渡す方法については、別記事『OAuth 2.0 の認可レスポンスとリダイレクトに関する説明』で解説していますので、ご参照ください。 追記（2020-03-20） この記事の内容を含む、筆者本人による『OAuth & OIDC 入門編』解説動画を公開しました！ 1. 認可コードフロー RF

5. • その暗号技術がどのぐらい安全かを表す大雑把な指標 • nビットセキュリティは2 𝑛 回攻撃が必要 • 1回あたりの攻撃コストはあまり気にしない • 𝑂 2 𝑛 という表記 セキュリティビット 𝑛 直線 :𝑂(𝑛) 3次関数 : 𝑂(𝑛3 ) 指数関数 : 𝑂(2 𝑛) 𝑂(log 𝑛) 5 / 21 6. • 第二原像計算困難性（弱衝突耐性） • 𝑚1に対して𝐻 𝑚2 = 𝐻 𝑚1 となる𝑚2 ≠ 𝑚1が分からない • 同じじゃなくてもいいから何か一つ見つけるのが困難 • 𝑂(2 𝑛 )回トライ ; nビットセキュリティ • 衝突困難性（強衝突耐性） • 𝐻 𝑚1 = 𝐻(𝑚2)となる𝑚1 ≠ 𝑚2を見つけるのが困難 • 𝑂(2 𝑛/2 )回トライ ; 𝑛/2ビットセキュリティ • 第二原像を見つけるのは単なる衝突より2

はじめに この文書では、OAuth 2.0 + OpenID Connect サーバーをゼロから一人で実装した開発者（私）が、得られた知見について書いていきます。基本的には「実装時に考慮すべき点」を延々と述べることになります。 そのため、この文書は、「素早く OAuth 2.0 + OpenID Connect サーバーを立てる方法」を探している方が読む類のものではありません。そのような情報をお求めの方は、「Authlete を使って超高速で OAuth 2.0 & Web API サーバーを立てる」を参照してください。そちらには、「何もない状態から認可サーバーとリソースサーバーを立て、アクセストークンの発行を受けて Web API をたたいて結果を得る」という作業を、所要時間 5 ～ 10 分でおこなう方法が紹介されています。 文書のバイアスについて 私は、OAuth 2.0 + Ope

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