パスワード生成コマンド：macOS・Linux・Windows

OS別：すぐ使えるパスワード生成方法

• macOS / Linux：openssl rand -hex 16で128ビットの乱数を32桁の16進数として出力
• Windows：PowerShell 7のRandomNumberGenerator.GetInt32で許可する文字集合から選択
• Python / PHP：標準ライブラリのsecretsとrandom_bytes()が同じ役割を担う
• ブラウザ：コマンドが使えない場合は文字種を指定できるパスワード生成ツールを使用

Chromeの新規登録画面で生成候補が出ない場合は、パスワード自動生成が表示されない時の確認手順で切り分けてください。生成値をコマンド引数、CIログ、共有クリップボードに残さない点はどの方法でも共通です。ダミーのAPIキー風文字列は開発用ランダム文字列生成で作れます。

エントロピーの数え方：符号化は強度を増やさない

本記事の理論エントロピーとは、取りうる値がN通りあり、そのすべてが等確率で選ばれると仮定したときのlog2(N)です。Nバイトの乱数なら8Nビットになります。重要なのは、符号化してもエントロピーは増えないという点です。同じ16バイトの乱数は、16進数なら32文字、Base64なら24文字になりますが、どちらも中身は128ビットです。文字数は、貼り付け先の入力欄の上限に収まるかどうかという実務上の制約に効きます。

文字数から強度を逆算するときは端数に注意が必要です。16進数は1文字がちょうど4ビットですが、Base64は3バイトを4文字に変換する符号化なので、3で割り切れない部分では最後の文字が6ビット未満しか運びません。RFC 4648は、端数で使われないビットを0に固定することを求めています。したがって「Base64の24文字＝24×6＝144ビット」という計算は過大評価で、実際には16バイト＝128ビットです。

コマンド別の出力とエントロピー

各コマンドが何バイトの乱数を返すかは公式ドキュメントに明記されています。それを、検証環境（OpenSSL 3.6.3、Python 3.14、PowerShell 7.6.3／.NET 10.0.9、PHP 8.4.11）で実行して文字数を数えた結果が表1です。

表1：コマンド別の出力長と理論エントロピー

128ビットを得る方法は複数あり、出力は32文字にも22文字にもなります。貼り付け先に文字数制限がある場合は、強度を落とすのではなく符号化を変えるのが基本です。また、GetString(56種, 20)が約116.1ビット（20 × log2(56)）であるのに対し、同じ20文字でも文字集合を90種に広げれば約129.8ビット（20 × log2(90)）です。文字集合の広さは対数でしか効かないため、強度を上げたいときは文字種より長さを増やすほうが効率的です。

Linux / macOSのパスワード生成コマンド

OpenSSLの公式マニュアルは、openssl randが「暗号学的に安全な擬似乱数生成器（CSPRNG）を使ってnumバイトの乱数を生成する」と説明し、乱数はRAND_bytes()で作られ、信頼できるOSのエントロピー源からのシードに成功していれば256ビットのセキュリティレベルを提供するとしています。シードに失敗した場合は非ゼロの終了コードで失敗します。

openssl rand -hex 16

16バイト（128ビット）の乱数を32桁の16進数として1行で出力します。numにはK/M/G/Tの接尾辞を付けられ、2進の倍数（K = 1024バイト）として扱われます。ファイルへ直接書き出す-outもあります。

openssl rand -base64 32 -out /etc/myapp/secret.key

-base64を使う場合は出力長と折り返しに注意が必要です。出力文字数は4 × ceil(N ÷ 3)で、パディングの=もこの文字数に含まれます。実測値が表2です。

表2：openssl rand -base64 N の出力長と折り返し（実測）

表2から実務上の注意が2つ出ます。第一に、Nが49バイト以上になると出力が64文字で折り返されます。openssl rand -base64 64は88文字を2行で返すため、シェル変数へ代入すると値の途中に改行が混入します。変数に入れる用途ではNを48以下に抑えるか、改行を除去してください。第二に、パディングの=と、標準アルファベットの+と/は、URL・設定ファイル・シェルの引用規則と衝突しやすい文字です。URLやファイル名に埋め込むなら、Pythonのtoken_urlsafeのようなURL安全なアルファベットを使うか、16進数のまま扱うほうが安全です。

/dev/urandom | tr | headの短い例も見かけますが、終了時のパイプエラー、文字の除外方法、環境差を説明しにくいため、秘密情報の標準手順にはOpenSSLなど意図が明確なAPIを推奨します。

Windows PowerShell 7のパスワード生成コマンド

PowerShell 7（.NET）では、公式ドキュメントが「暗号学的に強い乱数生成器を使用して」値を返すと説明するRandomNumberGeneratorのAPIを使います。許可する文字集合から1文字ずつ選ぶ基本形は次のとおりです。

$chars = 'ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz23456789'
-join (1..20 | ForEach-Object {
  $chars[[Security.Cryptography.RandomNumberGenerator]::GetInt32($chars.Length)]
})

この文字集合は56種なので、20文字なら約116.1ビットです。ただしGetInt32の適用範囲は公式ドキュメント上で.NET Core 3.0以降・.NET Standard 2.1・.NET 5以降とされており、.NET Frameworkは含まれません。したがってWindows PowerShell 5.1ではこの静的メソッドは使えません。古いGet-Randomの例へ置き換えず、PowerShell 7へ更新するか、OpenSSLまたは組織で承認された秘密情報管理ツールを使用してください。公式ドキュメントはGet-Randomについて「暗号学的に安全な乱数であることを保証しない」と明記しています。

PowerShell 7.4以降には、文字集合を自分で書かなくて済むAPIがあります。.NET 8以降で利用できるGetHexStringとGetStringは、いずれも「暗号学的にランダムな文字」で埋めた文字列を返すと記載され、GetHexStringは16進文字を指定したGetStringと同じ挙動で16進に最適化されていると説明されています。PowerShell 7.4は.NET 8.0ランタイム上に構築されているため、この2つは7.4以降で使えます。

[Security.Cryptography.RandomNumberGenerator]::GetHexString(32)
$chars = 'ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz23456789'
[Security.Cryptography.RandomNumberGenerator]::GetString($chars, 20)

7.4ではGet-SecureRandomも追加されました。公式ドキュメントは、これがRandomNumberGeneratorクラスを使って暗号学的に安全な乱数を生成すると説明しています。文字列ではなく数値を扱うcmdletなので、文字列生成にはGetString系を、テストデータの生成にはGet-SecureRandomを使う切り分けが分かりやすくなります。検証環境では、GetHexString(32)が32文字、GetString(56種, 20)が20文字を返すことを確認しました。GetHexStringは既定で大文字を返し、第2引数に$trueを渡すと小文字になります。

Pythonのパスワード生成コード

Pythonの公式ドキュメントは、secretsモジュールを「パスワード、アカウント認証、セキュリティトークンなどの管理に適した暗号学的に強い乱数」を生成するものと位置づけ、シミュレーション向けのrandomより優先して使うべきだとしています。

• token_bytes(nbytes)：nbytesバイトの乱数バイト列を返します。
• token_hex(nbytes)：各バイトを2桁の16進数に変換した文字列を返します。16バイトなら32文字です。
• token_urlsafe(nbytes)：Base64で符号化したURL安全な文字列を返します。公式ドキュメントは「1バイトあたり平均およそ1.3文字」と説明しており、これは4 ÷ 3 = 1.333に一致します。

引数を省略するかNoneを渡すとDEFAULT_ENTROPYが使われ、公式ドキュメントはこの値が変更され得ると注記しています。検証環境では32バイトでした。同じページには、2015年時点の判断として「32バイト（256ビット）のランダム性が、secretsモジュールに期待される典型的な用途には十分と考えられている」と記載されています。

import secrets
print(secrets.token_hex(16))
print(secrets.token_urlsafe(16))
print(secrets.token_urlsafe(32))

実測ではtoken_hex(16)が32文字、token_urlsafe(16)が22文字、token_urlsafe(32)が43文字でした。出力に=・+・/が含まれないことは200回の試行で確認しており、設定ファイルやURLへ貼る用途では、この点がopenssl rand -base64との実用上の差になります。

文字種を指定したい場合は、secrets.choiceで文字集合から1文字ずつ選びます。次の例は大文字・小文字・数字・記号を最低1文字ずつ含むまで生成し直すものです。

import secrets
import string

symbols = '!#$%&()*+,-./:;<=>?@[]^_{|}~'
alphabet = string.ascii_letters + string.digits + symbols

while True:
    password = ''.join(secrets.choice(alphabet) for _ in range(20))
    if (any(c.islower() for c in password)
            and any(c.isupper() for c in password)
            and any(c.isdigit() for c in password)
            and any(c in symbols for c in password)):
        break
print(password)

この文字集合は英小文字26・英大文字26・数字10・記号28の合計90種で、制約を課さなければ20文字で約129.8ビットです。制約を課したときの実際の値は次の節で計算します。

PHPのパスワード生成コード

PHPの公式マニュアルは、random_bytes(int $length)を「要求された長さの、一様に選択されたランダムバイトを含む文字列を生成する」関数として説明しています。引数は1以上でなければならず、満たさない場合や乱数源を確保できない場合はRandom\RandomExceptionが投げられます。WindowsではPHP 7.2以降はCNG-APIが使われると記載されています。

文字として読める必要がある場合は、バイト列をbin2hex()やbase64_encode()で符号化します。検証環境（PHP 8.4.11）では、random_bytes(16)が16バイト、bin2hex()で32文字、base64_encode()で24文字（パディング2文字を含む）になりました。OpenSSLの表2と同じ関係です。文字集合から選びたい場合は、公式マニュアルが「暗号学的に安全で、一様に選択された整数を返す」と説明するrandom_int()を使います。

function generatePassword($length = 16) {
    $chars = 'ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789';
    $password = '';
    for ($i = 0; $i < $length; $i++) {
        $password .= $chars[random_int(0, strlen($chars) - 1)];
    }
    return $password;
}
echo generatePassword(16);

この例の文字集合は62種なので、16文字なら約95.3ビット（16 × log2(62)）、20文字なら約119.1ビットです。random_bytes()より1文字あたりの情報量が少ないのは、62種のプールから選ぶためです。なおrandom_bytes()とrandom_int()はいずれも暗号学的に安全ですが、rand()やmt_rand()は秘密情報の生成に使えません。

文字種の構成規則は、エントロピーをどれだけ減らすのか

「大文字・小文字・数字・記号を最低1文字」という規則を課すと候補が絞られて弱くなる、という説明をよく見かけます。そこで前節のPythonの例（90種、4種類すべて必須）について、条件を満たす文字列の個数を包除原理で数え、理論エントロピーを厳密に計算しました。条件を満たす文字列は一様に選ばれるため、条件付きの理論エントロピーは「受理される個数のlog2」になります。

表3：90種の文字集合で4種類すべてを必須にしたときの理論エントロピー

結果は直感に反するかもしれません。20文字では、制約による減少は0.15ビットでした。20文字の時点で各文字種が1文字も現れない確率がもともと低いため、条件付きの分布はほぼ一様のままです。一方、8文字まで短くすると減少幅は1.07ビットに広がり、生成し直しになる割合は52.3%に達します。同じ規則でも、短いほど影響が大きくなります。構成規則そのものが強度を大きく損なうわけではありませんが、長さを削る言い訳にはなりません。

また、これは生成側の都合の話であり、サーバー側が構成規則を強制することは別問題です。NIST SP 800-63B-4は、検証者とCSPに対し、文字種の混在を要求するような他の構成規則を課してはならない（SHALL NOT）と定めています。OWASPも、文字種の制限を設けず、上限を少なくとも64文字にしてパスフレーズを許容するよう求めています。生成器で文字種をそろえるのは貼り付け先に合わせる調整であり、認証システムの設計要件とは切り分けてください。

Basic認証用パスワードの生成

Apacheの公式ドキュメントによると、htpasswdはbcrypt、Apache用に改変されたMD5、SHA-1、システムのcrypt()のいずれかでパスワードをハッシュ化します。既定はMD5（2.2.18以降）で、SHA-1とcrypt()の形式は現在の基準では安全でないと明記されています。bcryptを選ぶ-Bは「現在は非常に安全と考えられている」とされ、計算コストは-Cで4から17（既定5）の範囲で指定します。

htpasswd -c /etc/apache2/.htpasswd ユーザー名

コマンド実行時に対話形式でパスワードの入力を求められます。ここで注意したいのが-bです。公式ドキュメントは、-bを使うとパスワードがコマンドライン上ではっきり見えるとして推奨していません。スクリプトからは、標準入力から読む-iが使えます。

openssl rand -base64 18 | htpasswd -n -i -B ユーザー名

18バイトを選んだのは、表2のとおり24文字・パディングなし・1行に収まる（144ビット）からです。Nが49以上だと改行が混入し、パディングや+・/を避けたい場面でも扱いやすくなります。検証環境で実行すると、$2y$05$で始まるbcryptハッシュが得られました（05は-Cの既定値5）。-iを使ってもコマンド自体はシェル履歴に残りますが、パスワード文字列は残りません。記号を減らす場合は、当サイトの記号なしパスワード生成ツールなどで作成した文字列を入力し、長さで補ってください。

用途別の使い分け

生成コマンドは乱数を供給するだけで、その値が何に使われるかは関与しません。目標値の根拠として、NIST SP 800-57 Part 1 Rev.5はセキュリティ強度を80・112・128・192・256ビットの集合で示し、80ビットはもはや十分とみなされず、112ビット未満の組み合わせは連邦政府情報の保護には承認されないとしています。前掲のPython公式ドキュメントが示す「32バイト（256ビット）で典型的な用途には十分」という判断とあわせると、機械生成の秘密情報は128ビットを下限、256ビットを余裕のある水準として考えるのが実務的です。

表4：用途別の目標とコマンドの使い分け

最も重要なのは最後の行です。生成コマンドが作れるのは乱数であって、資格情報ではないという区別です。パスワードは利用者が入力し認証側が照合する値なので、乱数源と長さが主要な関心事になります。一方、APIキーやトークンは機械が提示する資格情報であり、権限範囲、有効期限、ローテーション、失効、利用記録という属性が必要です。ローカルで生成した文字列をそのまま本番キーとして使うと、漏洩時に失効させる手段がなく、利用記録も残りません。OWASPのSecrets Management Cheat Sheetが、パイプラインが自前で秘密を作る場合に安全な乱数と適切な長さを求めたうえで監査とログの要件まで挙げているのは、この属性の部分が生成だけでは埋まらないからです。

生成後に残る履歴・ログ・クリップボード

安全な乱数で生成しても、値がどこかに残れば意味がありません。生成コマンドの出力が残りやすい経路と、公式ドキュメントに記載されている対策を整理します。

表5：生成値が残る経路と対策

PowerShellの履歴ファイルは、Windowsでは%APPDATA%配下、非Windowsでは~/.local/share/powershell/PSReadLineに置かれます。公式ドキュメントのフィルタは文字列と構文に基づくため、機密を示す語を使わずに値を代入すれば対象外になります。フィルタを安全網として当てにせず、AddToHistoryHandlerで自前の除外規則を足すか、そもそも対話シェルで生成値を扱わない運用にしてください。自動化では、生成値を標準出力に出さず、ファイルや秘密情報ストアへ直接書き込み、ログのマスキングを有効にします。

コマンドと専用ツールの使い分け

コマンドやコードを都度書くのは手間がかかります。当サイトのパスワード生成ツールはcrypto.getRandomValuesというブラウザ標準の暗号学的乱数APIを使用しており、複数個必要な場合は一括生成ツールも便利です。ただし、乱数源が適切でも、出力の保存場所や端末が侵害されていれば安全とは限りません。

コマンドを使うべきなのは、値が端末の外へ出てはいけない場合です。サーバーの設定ファイルへ直接書き込む、CI/CDの秘密情報ストアへ投入する、といった用途では、ブラウザを経由せずそのホストの上で乱数を作るほうが露出経路が少なくなります。逆に、利用者が自分のログイン用パスワードを作る場面では、生成した値をそのままパスワードマネージャーへ保存できるツールのほうが、値をどこにも残さずに済みます。

記号なしのランダムな文字列（APIキー風のダミー値やテストデータ）にはランダム文字列生成ツールを利用できます。テストデータは秘密ではないので、強度そのものより本番の資格情報と誤認されないことを優先し、test_のような接頭辞を付けます。実際のAPIキーは、サービスまたはサーバー側の秘密情報管理機能で発行してください。

よくある質問

まとめ

コマンドを選ぶときは、まず何バイトの乱数が返るかを公式ドキュメントで確認し、次に出力形式と出力長を用途に合わせます。openssl rand -hex 16もsecrets.token_urlsafe(16)も128ビットですが、出力は32文字と22文字で異なります。逆にopenssl rand -base64 16の24文字を「24 × 6 = 144ビット」と数えるのは誤りで、実データは22文字、強度は128ビットです。

文字種の構成規則は、長さを十分に取っていれば理論エントロピーをほとんど減らしません（20文字で0.15ビット）。強度を上げたいときは文字種より長さを増やすほうが効率的です。ただしサーバー側が構成規則を強制することはNIST SP 800-63B-4が禁じており、生成側の調整と認証側の設計要件は分けて考えます。そして最も見落とされやすいのが生成後の扱いです。履歴、コマンド引数、CIログ、クリップボードのいずれも、値が残れば強度は関係なくなります。

本記事の調査範囲と限界

• エントロピーは理論値であり、乱数源の品質を保証するものではありません。表1・表3の数値は「出力が独立かつ一様に選ばれた」と仮定した上限側の計算です。OpenSSLの公式マニュアルも、OSのエントロピー源からのシードに成功した場合に256ビットのセキュリティレベルが得られると条件付きで説明しています。
• NISTの留保は「人が選んだパスワード」に対するものです。OWASPは、NISTが「利用者が選んだパスワードのエントロピー推定は困難である」としていることを紹介し、エントロピー計算を絶対的な強度指標として扱わないよう求めています。本記事が扱うのは機械生成の値なので仮定は成り立ちますが、人が自分で考えるパスワードに同じ計算を当てはめることはできません。
• 出力長と折り返しの実測値は検証環境のバージョンに依存します。表1・表2はOpenSSL 3.6.3、Python 3.14、PowerShell 7.6.3（.NET 10.0.9）、PHP 8.4.11で確認したものです。openssl rand -base64が64文字で折り返す挙動は公式マニュアルに明記されていないため実測に基づく記述であり、将来変わる可能性があります。
• PowerShellのバージョン対応は、公式ドキュメントの適用範囲の記載に基づきます。GetHexStringとGetStringは.NET 8.0以降、GetInt32は.NET Core 3.0以降・.NET Standard 2.1・.NET 5以降と記載されています。実行検証はPowerShell 7.6.3で行ったもので、7.4や7.5の実機では確認していません。
• htpasswdの検証はmacOS付属の実装で行いました。bcryptハッシュが$2y$で始まることと-Cの既定が5であることは確認しましたが、他のOSやディストリビューションで同一の挙動になることは保証できません。
• 表3は特定の文字集合に限定した結果です。英小文字26・英大文字26・数字10・記号28の合計90種を前提としており、文字集合や必須にする種類を変えれば数値は変わります。本番のAPIキー・トークンの発行要件も各サービスの仕様に依存するため、本記事では一般的な水準を示すにとどめています。

参考資料

• OpenSSL・openssl-rand マニュアル
• Python 3・secrets モジュール
• PHP・random_bytes()
• PHP・random_int()
• .NET・RandomNumberGenerator.GetInt32
• .NET・RandomNumberGenerator.GetHexString
• .NET・RandomNumberGenerator.GetString
• PowerShell・Get-Random
• PowerShell・Get-SecureRandom
• PowerShell 7.4 の新機能（.NET 8.0 ランタイム）
• PSReadLine・コマンド履歴の保存先とフィルタ
• Apache・htpasswd リファレンス
• OWASP・Secrets Management Cheat Sheet
• OWASP・Authentication Cheat Sheet
• NIST SP 800-63B-4
• NIST SP 800-57 Part 1 Rev.5
• GNU Bash リファレンス（HISTCONTROL・HISTFILE）
• RFC 4648（Base16/Base32/Base64 符号化）

著者・編集：passwordgenjp.com 情報セキュリティ研究チーム。公開資料の確認日：2026年9月17日。