This blog has been updated with new information for 2020.
This came up a few times during the last round of security reports we at Denim have been writing, so I wanted ensure everyone understood the distinction. Granted, it is a subtle distinction, but it does exist even thought it sounds like a Dr. Seuss book at times.
- Cleartext is readable data transmitted or stored “in the clear” (i.e. unencrypted)
- Plaintext is the input to an encryption algorithm
- Ciphertext is the unreadable output of an encryption algorithm
- Plain text means its text that hasn’t been formatted (i.e., a plain text file)
- And clear text… well, this is just text that is easy to comprehend (added to be thorough)
- Something that is cleartext may be in plain text, could be used as plaintext, but definitely isn’t ciphertext.
- Something that is plaintext should be in plain text, could be cleartext, and will become ciphertext.
- Something that is ciphertext should be in plain text, could be used as plaintext, but definitely isn’t cleartext.
To non-security folks, this makes about as much sense as “key encryption keys” and “ticket granting tickets” (They’re real, look them up!), but the distinction comes down to when you are describing the text in question. Let’s use the scenario of storing credentials in a database, which is where I came across during our security reports.
If you store a password in a database, you would store it as either cleartext or ciphertext, usually in plain text, meaning the password is either encrypted or unencrypted, usually without formatting. Since while just sitting in a database it isn’t an input to an encryption algorithm, it is not plaintext.
Now you can correctly say something like “The cleartext password was queried from the database and used as plaintext by the encryption method to produce ciphertext, protecting our proprietary clear text formula.”
One last important distinction to understand is that plaintext is not necessarily readable, as you could take the ciphertext from one algorithm, feed it to another (i.e., plaintext), and produce more ciphertext.
Since this post is an older one but still gets a lot of traffic, we wanted to link to some additional material that might be of use to people reading the page. When we work with organizations to help them design and implement authentication and authorization systems, we get a lot of questions about encryption. Our standard out-of-the-box advice is to use the AuthX capabilities provided by your language and/or platform unless you have really specialized requirements. There are just too many things that can go wrong trying to roll your own AuthX system. If you do need to work on storing passwords, the Password Storage Cheat Sheet is a fantastic resource. (And, honestly, the OWASP Cheat Sheet series in general is a tremendous and very consumable set of resources for all manner of questions about secure design and coding).