Security & Privacy Tools

What people come here to do

Most visitors arrive with one small job. Make a password that is not the old one with a 2 on the end. Take the hidden details out of a photo before sending it, since a picture can carry the camera, the date and sometimes the place. Check that a download matches the checksum printed beside it. The Password Generator, EXIF Metadata Viewer & Remover and Hash Generator each do one of those and then stop.

Others need something heavier. File Encryption and Text Encryption put a password in front of something before it travels by email or on a memory stick. Redact a Document is for taking passages out before you pass the file on. Secure Notes, Diceware Passphrase, the Two-Factor Code Generator, Random Number Generator and Certificate Decoder cover the rest: keeping, choosing, signing in, and reading what a certificate actually says.

Why the browser matters more here

For most kinds of tool, running in the browser is a convenience. In this category it is the whole point. A password sent to a server to be scored has already been seen by someone else. A file uploaded to be encrypted was plain text on the way up. The only encryption worth doing is the kind where the secret and the software sit in the same place.

You can test that rather than trust it. Load a page, switch the network off, and keep working. These tools carry on, because there is nothing for them to fetch. The honest limit is what a browser tab cannot see. It has no idea whether your machine is already compromised, whether someone is reading over your shoulder, or whether the file was copied last week. A local tool protects the step in front of you, not the room you are in.

Choosing well, and one common mistake

Two of the password tools look alike and are not. The Password Generator makes long random strings, which suit a password manager that remembers them for you. Diceware Passphrase makes a run of ordinary words, better for the two or three passwords you must type from memory: the device login, the manager's own master password. Use the Password Strength Checker to understand a password, not to bless it. No checker can tell whether it has already turned up in a leak.

Two things are worth knowing before you start. Covering words with a black rectangle in an ordinary editor often leaves the text sitting in the file underneath, so real redaction has to remove the content rather than hide it. And there is no account here, which means there is no reset link. Encrypt a file, lose the password, and the file stays shut. Store the password somewhere safe first, then encrypt.

Why the SPF, header and CORS tools ask you to paste

Several tools here talk about things that live out on the network, and not one of them sends a request. The SPF & DMARC Checker reads a record you paste in. The Security Header Auditor grades headers you paste in. The CORS Preflight Simulator takes a call you describe plus a response you paste, then runs the browser's own decision rules over the pair. The security.txt Builder writes a file, and checks one you paste. The SSH Key Inspector reads the key text and nothing else.

The reason is that a page cannot do the lookup. A browser gives scripts no way to ask DNS for a TXT record, so a live SPF check is off the table. Reading another site's response headers is blocked too, by the very rule the CORS tool exists to explain. Any site that offers to fetch your headers is doing it from a server of its own. That may be fine, but the work is no longer happening in your browser.

So it helps to know which half of the job you are getting. The SPF checker counts DNS lookups against the limit of ten set in RFC 7208. The include, a, mx, ptr and exists mechanisms and the redirect modifier each cost one; ip4, ip6, all and exp cost nothing. Paste several records together and it will follow the includes between them. When a chain runs off the end of what you gave it, the missing part counts as one and the total is reported as a floor, not a final answer. In the same spirit, the Lookalike Domain Generator invents names but never checks whether any of them is registered, and the security.txt Builder cannot tell you whether your file is really being served.

Inside the files the two encrypters write

Both encrypters use AES-256-GCM. The key comes from your password through PBKDF2 with SHA-256, at 600,000 iterations. That is the same figure the Hash Identifier quotes as current OWASP guidance for stored passwords. A fresh 16-byte salt and a fresh 12-byte IV are drawn for every run, so encrypting the same words twice gives you two different results.

What they write differs, because the jobs differ. The Text Encrypter gives you text: the tag OLENC1, then the salt, the IV and the encrypted body, each in base64 and split by dots. It is wrapped every 76 characters so that email cannot mangle it. The File Encrypter writes a binary file. It opens with the seven bytes OLFILE1, then holds the salt, the IV, a two-byte length, the original file name and the body, and it is saved with .olenc on the end. Because the name sits inside the file, decrypting hands back the name you started with. Drop a .olenc file on the page and it switches to decrypt on its own.

Two limits are worth knowing before you start. A file over 300 MB is refused rather than attempted, because GCM encrypts in one go and the whole thing has to sit in memory. And GCM checks the data as well as hiding it, so a wrong password and an edited file fail in exactly the same way. The message names both causes on purpose. It is not hedging; it genuinely cannot tell which of the two happened.

Where the bit counts and the crack times come from

Every random choice in the password tools comes from crypto.getRandomValues. Math.random is never used, because its output can be worked out from a few samples. Each draw also throws numbers away. A 32-bit value is drawn again if it falls in the short tail that would leave some words likelier than others. With the 1,391-word list that means 243 of the 4,294,967,296 possible values are discarded.

The Passphrase Generator shows that list length beside every result, because it is what sets the strength. 1,391 words is about 10.4 bits per word. A full Diceware list of 7,776 words gives 12.9. The figure here is worked out from the list actually in use rather than borrowed from Diceware, so four words come to roughly 41.8 bits, which it calls reasonable. Six words reach about 62.7 bits, and that is where it starts saying strong. You can ask for anything from two words to twelve.

A crack time is half the search space divided by a guess rate. Half, because a search finds the answer halfway through on average. The rate is the part people argue about, so the Password Strength Checker quotes three of them rather than one: 100 guesses a second against a login form that slows attackers down, 100,000 against a stolen database hashed with bcrypt, and 10 billion against one kept as plain SHA-256 on consumer graphics cards. The same password can be safe for years on one row and gone on the next. Nothing about the password changed, only the way the site stored it. Before quoting any of that, the checker also docks bits for keyboard runs, common words and leetspeak, and swapping 0 for o costs six bits on its own.