They were. It was the _VIEWSTATE thing that ASP.NET sticks into pages. The developers put the full SSN into the _VIEWSTATE object, which is base64 encoded into the pages.

See https://news.ycombinator.com/item?id=28992667

There's a good comment there that the Microsoft ASP.NET help pages specifically call out an SSN as a terrible thing to put into _VIEWSTATE :)

Encoding is not encryption. That’s like if I got the raw bytes of Unicode characters and converted them to legible text. Or another way, that’s like two people talking about me in a language I don’t understand, and then I respond to them in said language.

That’s a terrific analogy. And it’s one that a jury will relate to. Sadly, if it goes to court, the poor guy’s lawyer is gonna have to spend a lot of time explaining how the State’s servers were sending this information in clear text to everyone who requested the page, refuting the false equivalence that the prosecution will make between “hacking” and “view source->decode to ASCII”.

It wasn't encrypted. It was written using Base64 – the computer equivalent of the phonetic alphabet. Anyone can “decode” it by hand, like Morse code, and the practised can read it off directly.

This Base64 was placed inside an HTML document. That's a bit like a Word document, except the formatting (bold, underline, big, small, Comic Sans) is written next to the text, so the computer knows how to display it. HTML is designed to be human-readable; in fact, it's designed for humans to write directly, using a text editor.

Here's an example of an HTML document, and here's a Base64 decoding table. (There's also a printout from Wikipedia, if you want to know how people can do it in their heads.) The jury should be able to read this SSN off, with no prior experience, in about ten minutes.

This was sent, by the State's computers, to every user of the system, due to a programming error.

  <!DOCTYPE html>
  <html>
    <head>
      <title>My Webpage</title>
    </head>
    <body>
      <h1>This is an HTML document</h1>
      <p>
        It might not look like much, but it's a website!
        This is what they look like to computers, and
        web developers. There is usually other code behind
        the scenes, where sensitive data should be stored,
        but this is the public part.
      </p>
      <!-- Internal state (public component).
           Should not contain sensitive data! -->
      <input type="hidden"
             name="__VIEWSTATE"
             id="__VIEWSTATE"
             value="dDwxMjM7dDxwPGw8
                    U1NOOz47bDw5MTIt
                    MzgtNjU0Nzs+Pjs7
                    Pg==">
    </body>
  </html>

There's no mention of any kind of encoding in the delivered HTML. From the newspaper [0]:

> the newspaper found that teachers’ Social Security numbers were contained in the HTML source code of the pages involved.

and later:

> In reality, the Post-Dispatch discovered the vulnerability and confirmed that the nine-digit numbers were indeed Social Security numbers.

[0] https://www.stltoday.com/news/local/education/missouri-teach...

See https://news.ycombinator.com/item?id=28992667

Thanks.

Given this, I think the journalist over-simplified the situation in their story and that the "F12" jokes are unjustified. Recognizing there's a disclosure of private information here requires a lot more technical knowledge beyond the ability to view the HTML source.

The governor is still wrong for pursuing this and what the newspaper did was right, given that they disclosed it to the responsible parties and didn't publish until the problem site was taken down.

I feel like the F12 jokes are fine, since they don't even match the Governor's exaggerated rhetoric about "hacking". Pasting the base64 into one of many online decoders isn't much of an extra step. The Governor kept calling it a complicated 8 step process or something similar to that.

Base64 can be done by hand with two tables: one splitting every character in three times two bits and one that takes four pairs of bits and looks it up in the ascii table. Done.

It's hard to call this encryption.

It can also be done using a few small books, mapping strings of 4 base 64 characters into 3 ASCII characters. With 100 printable characters (according to Python), and assuming you can get 96 per page (4 columns of 24; possible with clever layout), that would fill about 50 books.

Okay, maybe that's not very efficient.

Each pair of Base 64 characters contains a single ASCII character, plus some change. That would take three lookup tables of about 1000 entries each; given that the “change” letters could use character ranges, that would take 3 or 4 sheets of A4 (or A3, if you wanted large print).

I've always imagined that somewhere out there is a dude who has spent time to teach himself how to decode/encode base64 in his head.

Best I've done so far is to recognize that "eyJ" means I'm probably looking at JSON, since `{"` followed by any letter will always begin with that.

  > It's hard to call this encryption.

It's a lie to call this encryption. It is encoding, not encryption.