🔰 絶対に忘れない！？ちょっと強いパスワードの作り方！

👨‍💻「社内アカウント発行するので、パスワードを設定してね」

🐣「はい」ｶﾁｬｶﾁｬ

👨‍💻「あ、`password`とか`123456`とか`qwerty1234`みたいな簡単すぎるパスワードは危険だからやめてね」

🐣「そっか…じゃあ1つの複雑なパスワードを作ります！全部これにすれば安心ですね！」

👨‍💻「パスワードの使いまわしも危険だよ」

🐣「でも、10文字以上の複雑なパスワードなんて、たくさん作っても覚えられないですよ…」

👨‍💻「ブラウザに記憶させる機能とかあるから、そういうのも合わせて使ってみてよ」

🐣「うーん、やってみますね…」

（後日）

🐣「あ、だめだログインできない…パスワード忘れました…」

👨‍💻「うーん、仕方ないから再設定メール送ってみたら？」

🐣「再設定認証を受け取るメールのパスワードも忘れてログインできない…終わった……」

👨‍💻「……」

-----

どうにか使いまわしにならず、簡単に覚えられる10文字以上のパスワードを作れないか…ということを考えてみました。
お急ぎのかたは「[📝 まとめ](#-まとめ)」からお読みください。

:::note warn
**この記事はざっくり記事です**
なお、暗号化・復号・ハッシュ化などについて正確に記述することを目的したものでもありません。
詳細については別途お調べいただくようお願いいたします。
:::

:::note warn
**強いパスワードを作るだけで満足しない**
ブラウザに生成させてブラウザに覚えさせる方法などもありますが、あえて自分でパスワードを考える場合を想定しています。[SSO](https://ja.wikipedia.org/wiki/%E3%82%B7%E3%83%B3%E3%82%B0%E3%83%AB%E3%82%B5%E3%82%A4%E3%83%B3%E3%82%AA%E3%83%B3)などが使えるならそのほうが良いと思っています。

二要素認証など、できることがあるなら普段からしっかり対応しておきましょう。
:::

## 💭 本題の前に、なぞなぞです

```
暗号「たきゅたーたりのたつたたけたもたの」ってな～んだ？
```

**ヒント：たぬき**

…………

………

……

<details>
<summary>答えはこちら</summary>

🥒「きゅーりのつけもの」
</details>

### 🔐【前提知識】暗号化と復号

暗号文に添えてあったヒントの「たぬき」は、「“た”を抜いて読んでね」という意味です。
このような暗号の解き方のことを「**鍵**」と呼びます。

鍵に従って**暗号**を処理すると、読める状態「**平文**」になりましたね 👀🥒
その鍵を使って、暗号を読める状態に戻すことを**復号**と言います。
逆に、鍵を使って平文を読めない状態にすることを**暗号化**と言います。

|言葉|意味|
|:--|:--|
|平文|意味が分かる文。|
|鍵|文を暗号化・復号するときのルール|
|暗号文|一見意味が分からなくなった文。|
|暗号化|鍵に従って平文を内容がわからないようにすること|
|復号|鍵に従って暗号文を平文に戻すこと|

#### 暗号化の例

平文：こんにちは
鍵：（1）文字を逆順にして（2）「た」を1文字ずつ挟む

```
1. こんにちは
2. はちにんこ
3. はたちたにたんたこ
```

#### 復号の例

暗号文：はたちたにたんたこ
鍵：（1）文字を逆順にして（2）「た」を1文字ずつ挟む
つまり… （1）1文字ずつ挟まれた偶数の「た」を削除して（2）逆順にする

```
1. はたちたにたんたこ
2. はちにんこ
3. こんにちは
```

## ⚖️ 鍵、もといルールを作ってみる

:::note
**💡 パスワードの材料に使う文字列の考え方**
まずは安全のため、**10文字を超える[^1]ように**パスワードに何の文字列を使うかを決めましょう。
パスワードを忘れても大丈夫なように、**半永久的に変わらなさそうなもの**を材料にしてください。
[^1]:総務省内閣サイバーセキュリティセンターによると「英大文字・小文字＋数字＋記号の混在で 10 桁」を推奨。
<https://www.nisc.go.jp/security-site/files/handbook-01.pdf>
:::

Qiitaのアカウント用パスワードをお題に、ルールを考えてみましょう！💭

:::note alert
**ルール＝マスターパスワードのようなもの**
パスワードを作るルールは**どのパスワードよりも秘密にするべき情報**だということを覚えておいてください。
:::

今回は**試しに**、この4項目を挙げてみました。

- サービス名：`Qiita`
- 自分の誕生日：`0918`
- 自分の名前：`Kawarabe Ecma`
- 業務用かプライベート用か等の目的：`Private`

これらを単純に組み合わせるとこうなります。
文字数としては十分すぎる長さですが、単純すぎる割にちょっと長すぎますね…。

```
Qiita0918KawarabeEcmaPrivate
```

ここで重要になってくるのは、それぞれの文字列たちの**組み合わせ方**です。



### 🙈 文字列の組み合わせ方 その1

いったん**あえて**「ちょっと難解なルール」を考えて組わせてみます。

1. サービス名を「子音だけ」：Qiita → `Qt`
2. サービス名を「母音だけ」：Qiita → `iia`
3. 自分の生年月日を「すべての数字（18=0+9+1+8）にサービス名の文字数（5=Qiita）を足す」：0918（18+5） → `23`
4. 自分の名前を「姓は子音・名は母音だけの組み合わせにする」：Kawarabe Ecma → KwrbEa
（2）の文字をすべて足した数（3=2+1）の文字番目から始めて前半もくっつける（rbEa + Kw） → `rbEaKw`
5. 目的を「@＋単語のイニシャルを小文字」：Private → `@p`

これらを組み合わせるとこうなります。

```
Qtiia23EaKwrb@p
```

このルールでパスワードを考えてみた他の例はこのようなものになりました。

```
Pvii23EaKwrb@p     // Private目的のPixivアカウント
Dlnguoio26KwrbEa@p // Private目的のDuolingoアカウント
Gglooe24aKwrbE@b   // Bussiness目的のGoogleアカウント
Slcka23EaKwrb@b    // Bussiness目的のSlackアカウント
```

これだけ複雑なことをしたのにも関わらず、こうしてみると登場するパターンは似通っていることがわかりますね。

```
[いくつかの子音][いくつかの母音][2桁の数字][KwrbEaの並び替え]@[pかb」
```

1つのIDパスワードの組み合わせが万が一他のパスワードと同時に流出すると、次のようなパターンであることがわかってしまいます。

```
[サービス名の子音][サービス名の母音][2桁の数字][KwrbEaの並び替え]@[pかb」
```

これに気づいた攻撃者から総当たり攻撃を受けると、せっかく10桁以上あって解析に52年かかる[^2]はずが、**2日もかからずに突破されてしまう**かもしれません。

[^2]: 今までの常識は通用しない？安全なパスワードの桁数などの条件とは | セキュマガ | LRM株式会社が発信する情報セキュリティの専門マガジン「パスワード桁数は最低でも10桁以上で英数字と記号の組み合わせが必要」
<https://www.lrm.jp/security_magazine/secure_password/>

それにもかかわらず、パスワードの入力の度にこのルールを頭の中で処理するのはちょっと大変ですね…。

### 🐵 文字列の組み合わせ方 その2

今度はちょっとだけ簡単に考えてみましょう。

1. サービス名を「母音だけ」：Qiita → `iia`
2. 自分の生年月日を「すべての数字を足す」：0918（0+9+1+8） → `18`
3. 自分の名前を「子音だけ」：Kawarabe Ecma → `kwrbcm`
4. 目的を「@＋単語のイニシャルを小文字」：Private → `@p`

```
iia18Kwrbcm@p    // Private目的のQiitaアカウント
ii18Kwrbcm@p     // Private目的のPixivアカウント
uoio18Kwrbcm@p   // Private目的のDuolingoアカウント
ooe18Kwrbcm@b    // Bussiness目的のGoogleアカウント
a18Kwrbcm@b      // Bussiness目的のSlackアカウント
```

今回はすべて単純で`18Kwrbcm@`が使いまわしになっているルールなのに、**単体の強度**は「その1」とあまり差がなさそうです。
それでいてこれでも十分、本当の意味での使いまわしや、単純な単語のつなぎ合わせよりも強固なパスワードと言えそうですね。

:::note
**💡 ルールが難しすぎたら覚えられない**
WebサービスやそのURLを見ただけで、パスワードを「自分だけ」が「簡単に」わかるような仕組みを考えるのがポイントです。
処理が簡単なのに「10文字以上、大文字小文字・記号・数字を含む」複雑なものにするにはどうしたらいいかを考えるようにしてみましょう。

とはいえ、単純すぎても使いまわしと変わらなくなってしまうところに気を付けなければなりません。
:::

## 😱 パスワードの定期変更にはどうやって対応すればいいですか！？

今回の例では「`@`」の記号を使っていますが、こういう記号をいくつか候補を作っておくといいかもしれません。
たとえばQiita用のパスワードの場合、次のようにローテーションしてみるのはいかがでしょうか。

- `iia18Kwrbcm@p`
- `iia18Kwrbcm#p`
- `iia18Kwrbcm!p`

ご自身でルールを作る際に、パスワードがローテーションにも耐えうることも要件に含めてみるといいかもしれませんね！

:::note warn
**記号の候補は3種類までがおすすめ**
誤入力でロックがかかるような場合、たいてい３回は許されることが多い気がします。
記号は3種類にとどめたほうがいいかもしれません。
:::


## 🛡️ パスワードからサービス名やルールを推測されないようにしよう

「ルールとパスワードを知っていれば、どのWebサービス用のパスワードなのかが想像できる状態」を避ける必要があります。
そのためには素材にした文字列を一部削ったりして、**自分でもパスワードからは元の素材に戻せない**ような処理を考えるようにしてみてください。

万が一2つ以上のパスワードが流出してしまったときに、そこから**ルールを推測されてしまう**恐れがあるためです。
ルールがばれてしまえば、**同じルールで作ったすべてのパスワードがばれてしまう**ことになります。

:::note
**💡 どうしてルールがばれることにつながるの？**
<details>
たとえば、次の情報が何らかの事情で流出したとします。

- `5qtiia@23`というパスワードと**QiitaのID**
- `6gglooe@33`というパスワード

1つ目はIDまでバレていて、パスワードを見比べてみると2つ目もなんとなくどこのサイトで使われているか予測できそうですね。

🕵️‍♂️「このパスワードから察するに…」

- 先頭の文字はアルファベットの文字数に一致してそう？
- @は意味がないかも？
- 最後の数字は母音と子音に関係してそう
- 母音と子音で分けてくっつけたぽいから、アナグラムで出てくるサービスで使われそう
- QiitaからTwitterたどったらGmailアドレス出てきたし、gglooeってGoogleぽいな…試してみるか…
- お、行けたぞ。ということは、このユーザが利用している他のサービスも同じルールでパスワード作ったらログインできるのでは…
</details>
:::

パスワードの作成ルールを作るときは、パスワードができるだけ元になった文字列から遠くなるように、暗号化ではなく**ハッシュ化するイメージ**を持つようにしましょう。

:::note
**💡 ハッシュ化とは？**
復号できない暗号化みたいなものです。
暗号化の場合ある程度は規則的な文字列になりますが、ハッシュ化は不規則な文字列になるイメージです。
:::

たとえば「[🐵 文字列の組み合わせ方 その2](#-文字列の組み合わせ方-その2)」でQiita用のパスワードとして`iia18Kwrbcm@p`を作りました。
`iia`を含むだけでは元の文字数もパスワードから拾えないので、作り方のルールを知った状態でも何のWebサービス用なのかを想像するのは難しいでしょう。

もっと復号を難しくするなら、パスワードを入力するときに元のサービスの文字数分だけ、入力するキーを右にずらすなどの発想なども使えるかもしれません。

```
iia18Kwrbcm@p  > Qiita（5文字なので）    >  qqh6\Auo/,zre
ii18Kwrbcm@p   > Pixiv（5文字なので）    >  qq6\Auo/,zre
uoio18Kwrbcm@p > Duolingo（8文字なので） >  etrt93Fp[x\vuy
ooe18Kwrbcm@b  > Google（6文字なので）   >  uuo71Sip\.xt\
a18Kwrbcm@b    > Slack（5文字なので）    >  h6\Auo/,zr/
```

こうしてしまえば、サービス名とともに流出しても他のサービスまで不正アクセスされる可能性を下げることができそうですね。
パスワードの作り方がわかっていたとしても、そもそもサービス名が使われていることに気づくこと自体が難しいことから、攻撃者が「キーボード上で何文字右にズレているのか」を特定することも難しそうです。
パスワード単体で流出しても、すぐに不正アクセスの被害にあう可能性は下げることができるかもしれません（実用的はないですが）。

## 📝 まとめ

- Webサービスのトップページまたはログインページを開くだけで、自分だけは確実にパスワードがわかる
- Webサイトやサービスの更新で変わることがない文字列を材料に使う
- パスワードが漏れてしまっても、パスワードからはサービス名が特定しづらくなるよう配慮する
- 複数のパスワードからでもルールが推測しづらくなるよう配慮する
- 10文字以上になるように配慮する

上記の項目を守りながらハッシュ化のイメージを持って**パスワードを作るルール**を作れば、単純に考えるよりも強固なパスワードも作れるでしょう。
同時に「パスワード忘れた…」という悲劇を起こすことがなくなるかもしれません。

記号が使えないWebサービスや、定期的に更新を求めてくるようようなパターン、同一サービス上で別アカウントごとにパスワードの設定が必要なケースは別途検討が必要ですが、ご自身でパスワードを考えるシーンの参考にしていただければと思います 🥒

:::note alert
パスワードには、システム上使わないほうがいい記号などもあるのご注意ください。
特に、**記号から始まるパスワードができてしまうルールは避けるべき**です。登録ができてもログインできない不具合に遭遇する可能性があります。
:::

:::note warn
誕生日は、そのままの数字が含まれると弾かれる場合があります。
たとえば9月18日の場合、0918や918などは登録できないことがあるので、誕生日を使うなら違う文字列になるようなルールの採用がおすすめです！
:::

以上、河童式パスワードの作成方法でした！🥒

-----

なお、世の中にはランダムでパスワードを作ってくれるサイトもあります。
Google Chromeにもパスワードを自動で作って同期管理してくれる機能もあったりします。

https://support.google.com/chrome/answer/7570435?hl=JA&ref_topic=7439541

https://www.luft.co.jp/cgi/randam.php

普段の生活に取り入れられそうなものから、パスワード周りを見直してみてはいかがでしょうか。
他にも、二要素認証を一元管理してくれる便利なアプリもありますので、併せてチェックしてみてくださいね 🥒

- [Google Authenticator | App Store](https://apps.apple.com/jp/app/google-authenticator/id388497605)
- [Microsoft Authenticator | App Store](https://apps.apple.com/jp/app/microsoft-authenticator/id983156458)
- [Google 認証システム | Google Play](https://play.google.com/store/apps/details?id=com.google.android.apps.authenticator2&hl=ja&gl=US)
- [Microsoft Authenticator | Google Play](https://play.google.com/store/apps/details?id=com.azure.authenticator&hl=ja&gl=US)

---

短縮動画版も公開しました🥒

https://www.youtube.com/shorts/gxc1YWxbBV0