Bulk generation is for seeding a test environment, provisioning a fixed set of partner credentials, or migrating a system onto a new key format. It is a legitimate need with a dangerous artefact: a file containing many live secrets in plaintext.
Include a fingerprint column
The last4 column is the most useful thing in the export. It lets you build a dashboard that shows sk_live_…7f2a, lets support confirm which key a customer is using, and lets you correlate a log line with a record — none of which requires storing the secret itself.
Pair it with a stable label and you have everything an operational system needs. The key column is the only one that must be destroyed after distribution.
What to do with the file
Treat the export as radioactive from the moment it exists:
- Load it into your system immediately. The SQL output exists so the file can go straight into a database and then be deleted.
- Hash before storing. Never store the plaintext column. These keys already have full entropy, so SHA-256 is the right hash — bcrypt and Argon2 solve a problem these keys do not have.
- Distribute once, through a channel that does not retain. Not email, not a shared drive, not a ticket. The encrypted secret link generator splits a secret across two channels if you have no better option.
- Delete the file, then verify it is gone — including from your Downloads folder, your Trash, your editor's recovery cache, and any backup that ran in between.
Expiry from the start
The export includes an expires column because a key with no expiry stays valid in every backup and log it ever touched. Ninety days is a reasonable default for provisioned keys. Setting it at creation is nearly free; retrofitting expiry onto keys already in production is a migration.
Generate per consumer, not per system
If ten services need access, generate ten keys rather than sharing one. It costs nothing at generation time and it means a compromise of one service can be contained by revoking one key, rather than requiring a coordinated redeploy of all ten. The blast radius analyzer quantifies the difference.
Frequently asked questions
Can I generate more than 1,000 keys?
Not in one pass. The limit keeps the page responsive and, more usefully, discourages generating far more keys than you can safely distribute. If you need tens of thousands, generate them in your provisioning system where they can go straight into storage.
Should I store the plaintext keys anywhere?
No. Store a SHA-256 hash plus the prefix and last four characters. If a customer loses their key, issue a new one — the inability to recover a key is a feature, not a limitation.
Why is SHA-256 recommended when password advice says to use bcrypt?
Password hashing is slow deliberately, to compensate for passwords having perhaps 30 bits of entropy. These keys have 256. There is nothing to slow an attacker down against, and a slow hash on every API request is a real performance cost for no security gain.
Does the CSV get uploaded anywhere when I download it?
No. The file is assembled in your browser from a Blob and saved by your browser's download mechanism. No network request occurs.