Many years ago, I worked for a company that mandated that information like user credentials should never be stored "as plain text". It had to be "encoded". One of the internally-developed HR applications interpreted this as "base64 is a kind of encoding", and stored usernames and passwords in base64 encoding.

Steven recently encountered a… similar situation. Specifically, his company upgraded their ERP system, and reports that used to output taxpayer ID numbers now outputs ~201~201~210~203~… or similar values. He checked the data dictionary for the application, and saw that the taxpayer_id field stored "encrypted" values. Clearly, this data isn't really encrypted.

Steven didn't have access to the front-end code that "decrypted" this data. The reports were written in SSRS, which allows Visual Basic to script extensions. So, with an understanding of what taxpayer IDs should look like, Steven was able to "fix" the reports by adding this function:

public function ConvertTaxID(tax_id as string) as string
	dim splitchar as char = "~"
	dim splits() as string
	splits = tax_id.split(splitchar)
	dim i as integer
	for i = splits.length-1 to 0 step -1
		if isnumeric(splits(i)) then
			ConvertTaxID = ConvertTaxID & CHR(splits(i) - 125)
		end if
	next i
	

end function

We can now understand the "encryption" algorithm by understanding the decryption.

~ acts as a character separator, and each character is stored as its numeric ASCII representation, with a value added to it, which Steven undoes by subtracting the same value. To make this basic shift cypher more "secure", it's also reversed.

Steven adds:

Normally, this software is pretty solid, but this was one case where I was left wondering who got encryption advice from their 6 year old…

Sure, this is certainly an elementary school level encryption algorithm, but could a six year old have reverse engineered it? Of course not! So this is very secure, if your attacker is a six year old.