はじめに
普段はWeb開発を生業としている おりばー(@oliver_diary) です。
今年の4月から情報処理安全確保支援士として、社内のセキュリティ向上に努めているのですが、その取り組みの一つとして社内Slackに毎週セキュリティトピックを公開しています。
毎週続けて3ヶ月が経過しましたが、社内だけに閉じておくのは勿体ないと思ったので、記事としてまとめて投稿します。みなさんのセキュリティ意識向上の助けになればと思います。
またセキュリティ研修用に使用したアプリケーションの記事も公開しているので、そちらも併せてご覧ください。
Gitの脆弱性（2020/04/23）
みなさん、既にバージョンをあげている方もいると思いますが、Gitにとても深刻な脆弱性が発見されました。
http://www.security-next.com/114201
https://github.com/git/git/security/advisories/GHSA-qm7j-c969-7j4q
脆弱性にはCVEという共通脆弱性識別子がつけられるのですが、今回の識別子は「CVE-2020-5260」です。
CVEは米国のMITRE社が採番しているセキュリティ業界では有名な識別子です。
詳しく知りたい方は、以下の記事をみましょう。
https://www.ipa.go.jp/security/vuln/CVE.html
また脆弱性にはCVSSという共通脆弱性評価システムが存在します。
これは簡単に説明すると「脆弱性の深刻度のスコア」です。現在の最新はv3です。
詳しく知りたい方はこちらから
https://www.ipa.go.jp/security/vuln/CVSSv3.html
様々な評価基準があるのですが、今回の脆弱性のCVSSは「9.3」で「クリティカル」です。
これがどのくらいヤバいかというと、数値は 0.0 ~ 10.0 の範囲で 9.0 以上は「緊急」 と評価されるため、今回の脆弱性はめちゃくちゃヤバいです。
**PoC（Proof-of-Concept, 概念実証）**も公開されており、単にリポジトリをCloneするだけで、攻撃者のサイトにGitのパスワードが送信されてしまう可能性があります。
詳しくはここのサイトを見ると理解が深まると思います
https://at-virtual.net/securecoding/%E3%80%90poc%E3%81%82%E3%82%8A%E3%80%91cve-2020-5260-xcodemac%E7%89%88%E3%81%ABgit%E3%81%AE%E8%AA%8D%E8%A8%BC%E6%83%85%E5%A0%B1%E3%82%92%E5%8F%96%E5%BE%97%E3%81%95%E3%82%8C%E3%82%8B%E8%84%86/
今回のGitの脆弱性は、Git使う人全員が対象だと思ってください。必ずバージョンを上げてください。
ここでは念のためMacでのバージョンアップ方法を記載しておきます。
バージョンの確認方法（厳密には違うが、version 2.26.1以上ならOK、下はアウト）
$ git --version
git version 2.24.1 (Apple Git-126) # これはアウト
- MacOS Catalinaを使ってる人
Xcodeのバージョンを上げる
- brew経由でGitを使ってる人
$ brew upgrade git
- MacOS Catalina以外の人
Xcodeのバージョンを上げてみて、パッチバージョンが下記のいずれかであることをチェック（ここ詳しく調べきれてなくてすみません）
git 2.17.4, git 2.18.3, git 2.19.4, git 2.20.3, git 2.21.2, git 2.22.3, git 2.23.2, git 2.24.2, git 2.25.3, git 2.26.1
そのほかの方法でGitを使っている人は各自調べておいてください。よろしくお願いします。
URLリンク偽装（2020/04/30）
先日「Slackで認定されたURLリンク偽装の脆弱性」という記事（ https://akaki.io/2020/url_link_spoofing.html ）が上がっていて、とても面白い内容であるとともに、みなさんの身にも降りかかる可能性がある内容であり、また今後の開発において、もしかしたら皆さんも直面するであろう脆弱性だと思ったため、是非参考にしてみてください。
まず挙動を説明します。下記のリンクをクリックしてみてください（決して攻撃サイトに飛ばすわけではないので安心してください）
<ここにslack上に表示されているURLと、実際にクリックして飛ばされるURLが別のものを表示していた>
おそらく、最新版のSlackを使っている場合は、警告が出たと思います。
この警告は、表示されているURLと実際に飛ばされるURLが異なる場合にポップアップとして表示されます。
見た目のURLと実際に飛ばされるURLが違うというのが今回のキモですが、このような手法は**「Link Manipulation」**と呼ばれています。
詳しくはこちら
https://www.phishing.org/phishing-techniques#:~:text=Link%20Manipulation
HTMLで表現するなら以下のようなイメージ
<a href="https://minakawadaiki.com/">https://example.com</a>
Slackでも昔はポップアップや警告ダイアログが出ないで攻撃のリンクに飛ばされていた時期があり、当初Slack側は「ワークスペース内のメンバーの対立が前提」と延べ、脆弱性を認めていなかったが、外部からのメールの注入などで起こりうる可能性があるとして、脆弱性と判断した背景があります。
やりとりはこちら
https://hackerone.com/reports/481472
我々は、日々開発していく中で、URLを扱うことはとても多いです。
それこそ、**<サービス名>**などでも今後、URLに自由な表示文字を設定できるようになる仕様が出てくるかもしれないです。
新しいサービスを作る時に要件が上がってくるかもしれないです。
そうなった時に、今回のような脆弱性のパターンを思い出してもらい、回避することで安全なサービスを作っていきましょう。
二要素認証（2020/05/14）
みなさん、**二段階認証（2-Step Authentication）と二要素認証（2-Factor Authentication）**の違いを説明できますか
二段階認証は例えば
- 「IDとパスワード」で認証後、「秘密の質問」を入力
- 「IDとパスワード」で認証後、「SMSで送られてくるコード」を入力
など、ある認証をした後もう一回認証を行う。すなわち**「1回認証した後、もう1段階認証」**することを二段階認証と言います。
次に二要素認証の例に入る前に、認証要素について説明しておきます。認証要素は以下の３つのカテゴリに分かれます。
- 知識要素（パスワードや秘密の質問などあなたが知っていること）
- 所持要素（スマホアプリやICカードなどのあなたが持っているもの）
- 生体要素（顔認証、指紋認証などのあなた自身のもの）
そして、これらを踏まえた例えば
- 「IDとパスワード」での認証に加えて、「指紋」で認証する
- 「顔」での認証の後、「ワンタイムパスワード」で認証する
など、**「2つの認証要素を用いて認証」**することを二要素認証と言います。
では、問題のある二段階認証を例としてあげてみます。
- IDとパスワードで認証後、「秘密の質問」を入力
- スマートフォンでSMS認証後、同じスマートフォンで認証コードを入力
これらは二段階認証であるが、要素数は１つです。
世界的な情報セキュリティに関するガイドラインでは、**「一要素の複数段階認証は強力でない」**とされ、価値を否定しているほどです。
なので重要なのは段数ではなく要素数であることを肝に銘じておきましょう。
みなさんは一要素の二段階認証で満足してしまっていませんか
改めて認証方法を確認し、複数要素で認証できているかチェックしましょう。
セキュリティの問題は自分自身だけでなく周りにも影響を与えるので、時には面倒臭い部分もあると思いますが、積み重ねが大事です。小さいところから、やっていきましょう
また余談ですが、海外では2段階認証という言葉はあまり使われていないらしく、日本では「秘密の質問」型式が多かったためよく使われていると言われています。
そして「Google Authenticator」が設定エクスポートに対応したらしいので、機種変更時の移行も簡単にできます。積極的に使っていきましょう
https://japanese.engadget.com/jp-2020-05-07-google.html
ネット上の誹謗・中傷・デマ（2020/05/21）
「ネット上の誹謗・中傷・デマ」はセキュリティと関係ないのでは？と思ったそこのあなた、関係大アリです
️
どのくらい関係があるのかというと、IPAが公開してる**「情報セキュリティ10大脅威 2020」の【5位】**にランクインしているくらい、大きな問題になっています
興味がある方はここから詳細を見てみてください
https://www.ipa.go.jp/security/vuln/10threats2020.html#download
セキュリティの観点から、攻撃者は
- 情報モラル、情報リテラシーが低い人
- 悪意を持っている人
被害者は
- 個人
- 組織（教育機関、公共機関、企業）
と定義され、対象が非常に身近ですね。
では、**「ネット上の誹謗・中傷・デマ」がなぜセキュリティに関係するのかという根本的な部分ですが、情報セキュリティは
「情報の機密性、完全性および可用性を維持すること。さらに、真正性、責任追跡性、否認防止および信頼性のような特性を維持することを含めてもよい」
と定義されています。（小ネタですが「機密性、完全性および可用性」のことは「セキュリティのCIA」**と呼ばれています。）
今回は特に「真正性」を脅かすのが「ネット上の誹謗・中傷・デマ」だと思っています。
**「真正性」は「エンティティは，それが主張するとおりのものであるという特性」**と定義されていますが、簡単にいうと「その情報は本人であって、なりすまされてないこと」です。
今回重要なのは**「悪意を持っていなくても、攻撃者になってしまう」**というところです。
なんとなくデマを公開してしまった場合に、それが単なる嘘情報だけでなく、会社に対する攻撃となってしまう可能性が大いにあります。
最悪のケースだと訴えられてしまうケースもあります。
そうならないようにするためにも、日々の情報モラルやリテラシーの向上
は欠かせません。
最近だと下記の記事のような、コロナによる陰謀論など、迂闊に信じないリテラシーも大事です。
https://jp.techcrunch.com/2020/04/12/2020-04-10-coronavirus-5g-covid-19-conspiracy-theory-misinformation/
このように、やってはいけない理由を掘り下げ、理由づけをしっかりと行っていくことにより、皆さんのセキュリティ意識の向上になればと思います。
より一層、SNSなどの利用には気をつけて、攻撃者にならないようにしましょう。
認証と認可（2020/05/28）
みなさん、**「認証と認可」**の違いを説明してくれって言われた時に即答できますか？
まず、それぞれの英語表記ですが、認証は**「Authentication」認可は「Authorization」と書きます。
また「AuthN」「AuthZ」**と表記することもあります。
認証と認可は、お互いが非常に絡み合ってはいますが、別の概念と捉えてください。
- 「認証」は**「相手が誰であるかであること」**
- 「認可」は**「とあるリソースに対してアクセスの権限を与えること」**
と理解してください。
ここで以前のコンテンツの振り返りですが、認証には以下の3つの要素が存在しています。
- WHAT YOU ARE (生体要素)
- WHAT YOU HAVE (所持要素)
- WHAT YOU KNOW (知識要素)
これらのいずれか（or 複数）を用いて認証します。
認証は相手が誰であるかを検証するのであって、そこに権限の文脈は出てきません。
次に認可ですが、認可では**「誰が、誰に、何の権限を与えるか」**という3つの要素が出てきます。
この「誰が」を決める処理が「認証処理」であるため、話がややこしくなっていますが、重要なのは、権限を与えるという部分です。
（「誰が」は「ユーザー」、「誰に」は「アプリケーション」と捉えると分かりやすいかもしれないです。）
ですので、認証は「誰であるか」を調べ、認可は「権限を与える」と言うことを念頭に置いておきましょう。
別の視点では、HTTPレスポンスのステータスコードでも「認証と認可」の違いはあります。
- ステータスコード**「401 Unauthorized」は「認証失敗」**（パスワード認証のエラーなど）
- ステータスコード**「403 Forbidden」は「認可失敗」**（そのリソースに対するアクセス権限が無い）
このように、認証と認可の違いをしっかりと把握し、適切な実装をしましょう。
また余談ですが、よく話題になっていたのは**「OAuth認証」**です。
本来「OAuth」は認可するのであって、認証は範囲外です。リソースに対する権限を与えるだけです。
と言われているケースが多いですが、実際、認可処理の「誰が」を決める部分には認証処理が含まれてます。
ですのでOAuth認証とは、この認可処理に使用した認証処理をもってして、サービスの認証としてしまおう、という作戦です。
ですが、それをサービスの認証として用いると、認証のレベルがとても下がってしまうことに問題があります。
OAuthを用いて認証することが何故認証のレベルが下がってしまうのかを詳しく知りたい方は下記リンクを見てみてください
https://tech-lab.sios.jp/archives/13002
そして、その認証のレベルの低いOAuthに、まともな認証を設けたい場合に**「OpenID Connect」**という「OAuth2.0規格の拡張仕様」が出てくるわけです。
「OpenID Connect」に興味のある人はこちらを見ると良いでしょう
https://qiita.com/TakahikoKawasaki/items/498ca08bbfcc341691fe
セキュリティソフト（2020/06/11）
以前**「ランサムウェア被害に見る、日本の「危うい」セキュリティ意識」**という記事が公開されました。
https://www.itmedia.co.jp/enterprise/articles/2006/02/news035.html
この記事には「日本はセキュリティに関して大きな被害を受けている」と書かれており、
その理由として**「セキュリティ対策ソフトの過信」**を挙げています。これを掘り下げていきます。
まず前提として、セキュリティ業界では、悪意のある(malicious)ソフトウェアでのことをマルウェアといいます。
マルウェアの一種であるランサムウェアは**「Ransom（身代金）」と「Software（ソフトウェア）」**を組み合わせた造語です。
他のマルウェアは、ウイルスやトロイの木馬、ワームなどが存在します。それぞれの特徴を見ていきましょう。
- ウイルスは**「自己繁殖する」「宿主が必要」**、例えばExcelのマクロ機能を悪用し増殖するマクロウイルスに感染する
- ワームは**「自己繁殖する」「単体で活動」**、例えばボットネットとして感染PCがDDos攻撃の踏み台に利用される
- トロイの木馬は**「自己繁殖しない」「無害ファイルになりすまして活動」**、例えば感染PCがバックドアとして利用される
これらのマルウェアは紐づいており、組み合わせて利用される場合が多いです。
また、スパイウェアというユーザーの個人情報などを収集するマルウェアも存在します。キーロガーなどがその例です。
（余談ですが、マルウェアは一般的な用語ではないため、これらを含めてコンピュータウイルスと呼ばれたりもします）
ここら辺の話は無限にできてしまうので、またの機会に紹介します。
参考:
https://www.ntt.com/business/services/network/internet-connect/ocn-business/bocn/knowledge/archive_19.html
https://saas.gmocloud.com/service/websecurity/threat/malware-step.html
これらの紹介したマルウェアは先述のランサムウェアに利用されることが多いです。
本題のセキュリティソフトに戻すと、セキュリティソフトは基本的に**「パターンマッチングでマルウェアを判定してブロック」しています。
これは「シグネチャに基づくマルウェア検知」**と表現されます。
簡単に説明すると、「ウイルス判定されたプログラムコードと似てるコードがあったらそれはウイルスだ！」という検知方法です。
これだけでは全てのウイルスには追従できないので、もちろん異常などの挙動をチェックするセキュリティソフトも存在しますし、最近のは大抵そうです。
だからと言って、みなさんならもちろん**「セキュリティソフトが謎のすごい技術で謎に全てのマルウェアから守ってくれるはず！」**だとは思っていないですよね？
プログラムを普段書いてればわかるように、アプリがインストールされた相手PCから、自分のところに自動的に機密ファイルを転送するコード、書けそうですよね？キーロガーなんて、プログラムの演習で書く場合だってあります。
記事にもある通り、「セキュリティ対策ソフトを入れているんだから安心、なんでも守ってくれるはず」と思うのはとても危ないです。日本は対策ソフトを入れているのに被害に遭うという状況が多いです。
これは、日頃のセキュリティに関するリテラシーが薄いことに他ならないです。特にエンジニアのみんなは開発時に自分のPCのセキュリティを緩めるケースが出てくると思います。
そうなったときに、守れるのは自分だけです。いつ被害に遭うかわかりません。セキリュティソフトだけで慢心せず、「安心」ではなく「安全」を意識しましょう。
ソーシャルエンジニアリング（2020/06/18）
皆さんは**「ソーシャルエンジニアリング」**という言葉を聞いたことがありますか？
パスワードなどの重要な情報をインターネットなどの情報通信技術を使用せず、盗み出す方法のことを言います。
その多くは、人間の心理的な隙や行動のミスにつけ込んで秘密情報を入手するパターンです。
参考： https://www.soumu.go.jp/main_sosiki/joho_tsusin/security/business/staff/12.html
一言で例えるなら**「心理的攻撃」**ともいわれています。
前回紹介したウイルスなど、条件が揃わなければ中々実現できない技術的な攻撃とは違い、身近で悪意のある人間が、善良な会社などを陥れる時に、まず行われる攻撃です。
そんな**「ソーシャルエンジニアリング」**ですが、攻撃手法は様々です。
例えば**「友人のスマホのパスワードをのぞき見た」**。これは歴とした「ソーシャルエンジニアリング」です。
みなさんも無意識に攻撃に加担している可能性があるので、日頃から注意しましょう。
特にPCやスマホなどで、パスワードを入力する時に、のぞき見られてしまったり、トイレに行く時にPCのロックをかけ忘れてしまって他の人に触られてしまうなどの**「ショルダーハッキング」**の類は、日々のセキュリティ意識が欠如していると起こりやすいです。
オフィスには社員以外の人も出入りしますよね？皆さんのPCは会社の機密情報がたんまりと入っている大事な端末です。
オフィスだから大丈夫、ではありません。日頃からの癖が出ないように意識しましょう。
他のソーシャルエンジニアリングの例でいうと、電話でパスワードを聞き出す方法です。
**「なりすまし電話」**とも言われていますね。流石に皆さんはあり得ないと思いますが、本当かどうかの謎のAWSの人から電話がかかってきて、パスワードを教えてしまうなど。
相手の身元をしっかりと確認し、特にパスワードなどは電話越しでは絶対に話さないようにしましょう。
※パスワードを聞き出す行為は電話に限らず、本来絶対あり得ません
他には**「トラッシング」**と言うゴミ箱を漁る方法も存在しています。
機密情報を含んだ紙媒体はシュレッダーに必ずかけましょう。誰がそのゴミ箱を漁るかわからないので。
と、ここまでソーシャルエンジニアリングについて少し紹介しましたが、これ以外にもたくさんの手法が存在しますし、その脅威は意外と身近に存在します。
何がヤバイかって、気付いたら機密情報漏れているケースがあることです。実際、実例もめちゃくちゃ出ています。
仕事場には常に他人もいると言うこと、悪意を持った人も存在することを念頭において、
こういった**「心の隙」**にも対応できるよう、日々の警戒とセキュリティ意識を高めていきましょう
有名な攻撃手法を紹介（XSS編）（2020/06/25）
日々の開発において、最近はあまりセキュリティを意識しなくても、ライブラリなどのおかげで、ある程度はセキュアな開発ができるような状態にはなってきています。
しかし、いざ調査が必要な場面に直面した時に、用語を知らないってなると、原因究明にも支障が出ます。
有名な攻撃手法を知っておくことで、よりセキュアなコードを意識して書けるようにもなります。
今回は初回として、とても有名な攻撃手法であるXSSを紹介していきます。
合わせてIPAの資料なども参考にすると良いでしょう。
https://www.ipa.go.jp/files/000062612.pdf
XSSは**「クロスサイトスクリプティング」**と読みます。
XSSはユーザーの入力データを処理するアプリにおいて、JavaScript等の脆弱性を悪用し、ユーザー上のPC上で不正なスクリプトを動作させる攻撃手法のことを指します。
この攻撃が実現してしまうと、対象ユーザーの個人情報やセッションなどが盗み取られてしまう可能性があり、とても危険です。
再現方法は簡単で、ユーザーの入力データに対しサニタイジング（エスケープ）せずに画面にレンダリングされる場合、攻撃が可能になってしまいます。
例えば**<サービス名>**の投稿表示がサニタイジングされていない場合はXSSは大きな脅威となります。
とても有名な攻撃手法なので、ブラウザが標準でブロックしている場合もあります。（が、個人的にはブラウザの機能に乗っかるのはそのブラウザに依存してしまいがちなので、しっかりとアプリケーション側でも対応してください。みんながChromeを使ってるとは限りません。特にIEとか）
https://developers-jp.googleblog.com/2020/04/chrome-83-xss-cors.html
そんなXSSですが種類は結構あります。それらを軽く紹介します。
反射型XSS（Reflected XSS）
これは、ユーザーの入力値を確認ページなどでそのままレンダリングした際に発火してしまうパターンのXSSです。例えばお問い合わせページの確認画面などが挙げられます。
蓄積型XSS（Stored XSS）
これは、ユーザーの入力値がDBに一度格納され、それをブラウザでレンダリングされるときに発火するパターンのXSSです。例えば掲示板などが挙げられます。このXSSは特に被害が甚大です。
DOM Based XSS
これは、JavaScriptから動的にHTMLのDOMを操作する際に発生する種類のXSSです。例えば、urlにscriptが埋め込まれてた場合、それをjavascript側で取得して、処理する際に発火してしまうパターンです。以下のようなコードが挙げられます。
const div = document.getElementById("test");
div.innerHTML = location.hash.substring(1);
// 上記のコードが存在していた場合、
// http://example.jp/#<img src=1 onerror=alert(1)>
// がリクエストされた時に発火してしまう。
上記の例はChromeなどでは、フィルターによってブロックされるケースはありますが、基本的にDOM Based XSSはXSSフィルターを回避して攻撃が成立しやすい傾向があるので注意しましょう。
また、DOM Based XSSはIPAに良い資料があるので是非参考にしてみてください。（ちょっと古いが）
https://www.ipa.go.jp/files/000024729.pdf
ここからは余談ですが、最近のSPAフレームワークでは、ある程度サニタイジングされていて、あまりXSSを気にしないと思います。
ですが、いつSPAフレームワーク側で脆弱性が起きるか、またアプリケーション側で引き起こしてしまうか、そうなった場合責任を問われるのは我々です。
なので、入力フォームなどはしっかりとテストなどでチェックすることを心がけましょう。
こういったXSSが発火する可能性のある入力値がまとまってるサイトもあるので、是非参考にしてみてください。（実際に試すときは Chrome のXSSフィルターを無効にしてください）
http://nootropic.me/site/web/xss.html
いろいろな種類のDDoS攻撃を知ろう！（2020/07/02）
DDoS攻撃を知る前に、DoS攻撃の説明をします。DoS攻撃は**「Denial Of Service」の略で、要するに「サービス不能攻撃」**と訳されます。
その名の通り、サービスを停止させるような攻撃のことを言います。
昔だと、F5連打とか流行りましたよね？
今は1人が頑張ってF5連打したところで流石に停止しませんが、昔はそれで落ちていたサイトもありました。
そしてDDoS攻撃ですが、「Distributed Denial Of Service」の略で**「分散型サービス不能攻撃」**と略されます。
その名の通り、分散してDDoS攻撃してくるので、IPアドレスの制限などでは防げず、とても厄介です。
そんなDDoS攻撃、どんな種類があるかご存知ですか？
要するに「分散して相手のサービスを不能」にすればそれはDDoS攻撃ですので、結構種類があります。
有名なところでいうと、フラッド（flood）系です。意味は洪水を表します。
例えばSYNフラッド攻撃。これは**「3ウェイ・ハンドシェイク」**を悪用しているのですが、簡単にノリを説明すると
- ユーザが対象（サーバ）に「繋ぎたい！」的なSYNパケットを送信
- サーバは「OK！じゃあ繋ぐぜ？」的なSYN/ACKパケットを返信
- ユーザは「接続開始！」的なACKパケットを返信せず待機
このように接続要求してるのにユーザは、最後の接続開始する前に離脱してしまい、サーバを待たせリソースを枯渇させる技です。現実でこんな感じなことされたらムカつきますよね。
そのほかにも先ほどのACKを大量に送りまくる**「ACKフラッド攻撃」や、UDPの仕様を利用し、偽ったIPアドレスからDDoS攻撃をする「UDPフラッド攻撃」**などが挙げられます。
またフラッド系以外のDDoS攻撃でいうと、HTTPリクエストを大量に送り付ける「HTTPフラッド攻撃」や、DNSの名前解決の仕組みを利用して負荷をかける**「DNSフラッド攻撃」、pingを攻撃対象に大量に送り続ける「ICMP echoフラッド攻撃」**など、様々な種類が存在します。
上記で紹介した以外にも様々な攻撃方法があります。興味のある方は是非検索してみてください。
ともあれ、DDoS攻撃を完全に防ぎ切るのはとても難しいです。
ですが最近のクラウドではDDoSに対し、守ってくれているケースが多いです。例えばGCPでは**「Google Cloud Armor」**という、セキュリティサービスや、Cloud Functionsなどはデフォルトである程度のDDoS攻撃に対処していると言う話もあります。
https://stackoverflow.com/questions/47948561/are-google-cloud-functions-protected-from-ddos-attacks
またAWSは**「AWS Shield」**がそれに該当し、我々がものすごく気を使わなくても良い世界になってきています。
我々もDDoS攻撃と向き合わなければ行けない日はやってきます。その時は是非とも検討してみてください。
ちなみに余談ですがDDoS攻撃で面白かったのは**「Mirai」です。まず動機が「Minecraft」のライバルホストを攻撃をするため**という理由。
そして、数百Gbpsにも達する通信料を発生させたという凄さ。是非とも興味がある方は調べてみてください。
パスワードの今までとこれから（2020/07/16）
パスワードは一昔前まで「8文字以上の大文字小文字英数字記号」を含むようにするのが主流でした。
ですが、**今のPC性能だと1日以内に破られてしまいます。**もはや論外と言っても過言ではないです。
そこから最近では12文字以上が主流となりブルートフォースするにあたって、単純計算でも数万年計算が必要と言われています。
ですが大体の人は覚えやすい単語の組み合わせなどを利用してしまい、桁数の効果を無駄にしてしまうでしょう。
開発者はそこまで意識しなければいけません。
また、日々のPCの計算能力は向上し続けているので、文字数ではカバーし切れなくなる未来が来るのは確実でしょう。
それこそ機械学習からある程度推測されるケースも出てくる可能性もあるでしょう。
実際、2017年におけるハッキングの81％は、弱いパスワードや盗まれたパスワードが原因だったそうです。
https://developers.google.com/web/updates/2018/05/webauthn
パスワードに限界が来た時（もう来ているのですが）に大事になってくるのが多要素認証です。
そして多要素認証を実装する上で注目されているのが **FIDO （= Fast IDentity Online, 「ファイド」）**です。
認証器を用いて二要素認証を実現するための認証技術です。
FIDOの何がすごいかって、公開鍵暗号を使った所有認証と生体認証を組み合わせることで、単体で二要素認証を実現している点です。
ユーザーからの見え方は**「パスワードが不要で指紋のみの認証で二要素認証が完了している」**状態になります。
12桁のパスワードよりも強力だと断言できます。（なぜならFIDOが二要素認証なので）
認証器は、外部接続の物や、スマホやPCに組み込まれているものなど、様々な種類があります。皆さんのMacについているTouch IDも、認証器として使うことが可能です。
また、現在では、普及と利便性が追求されたFIDO2が主流になっています。ブラウザから認証器を扱うためのWebAuthnもその一つです。
最近ではGooglePayなどでMacのChromeから指紋要求されるケースがあると思いますが、これからどんどん普及していくことでしょう。興味のある人は検証してみるのも良いでしょう。
https://forest.watch.impress.co.jp/docs/serial/yajiuma/1257630.html
開発者としてパスワードのあり方は今後、変わってくることを念頭に入れておいて損はないでしょう！
終わりに
今回は社内で取り組んでいるセキュリティ向上の施策の一つを公開しましたが、それでもやはり、エンジニア社員全体のセキュリティ意識の向上はとても難しく感じています。
セキュリティはお金に直結します。できるだけセキュリティインシデントが起きるリスクを減らしつつ、それでもセキュリティインシデントが起きてしまった場合に、対処できるだけの能力が我々には求められています。
**「セキュリティは苦手だからやらない」で済む時代はもう終わっています。**全員でセキュアなコードを書き、できるだけセキュリティインシデントのリスクを減らすことが今後より一層求められます。
是非みなさんもこの記事をきっかけにセキュリティにより興味を持ってもらい、普段の開発に役立ててくれればと思います。