Clipboards and Passwords and Symantec and Encoding, Oh My!

There's been an interesting quirk in our SEPM server for...months, I think. It's one of those quirks that we find annoying, but our workarounds have been sufficient to the point that we ignored the problem. You know how it is...always something more pressing, and getting this to work was more or less an annoyance, not a showstopper.

We couldn't log into our SEPM server unless the password was pasted in.

Weird, eh?

The thing is that the person who normally logs into it is me. Like, 90% of the time. And we can log into the server itself, just not SEPM.

I'm on a Mac, so I use RDP to connect to our antivirus server. I'll call it AntivirusServer. I enter SuperUser and type in the password. SEPM replies that I have the wrong password.

I open my password manager, running on Windows in a Virtualbox VM, and display the password; it matches. I retype the password in the RDP session.

"WRONG. TRY AGAIN."

Clipboard sharing is enabled for both the VM/host and client/RDP session. I copy the password from the password manager, paste it into the RDP session and hit the enter key.

"GREETINGS PROFESSOR FALKEN."

Okay, maybe it didn't say that exactly, but you get the gist. Every time.

SEPM is basically a web interface to a Tomcat application (Apache/Java on Windows?...yeah, nevermind...) so I began to wonder if it wasn't doing something strange with the encoding of the password string. Maybe what I type in doesn't match the encoding of text pasted in!

So I asked on SuperUser how to determine the encoding of text. The first comment said it's not possible. Basically the encoding takes place within the application at the point where it's exported, saved or transferred, as per this answer on StackOverflow. It turns out that Clipboard does try to maintain some encoding, and from the looks of it an application can accept or translate input from the clipboard to some degree.

It may not inherently be incorrect, but the act of transferring it may cause some interesting side effects. But how can I tell what is happening in Clipboard?

Turns out ClipSpy provides a simple peek into what is in the clipboard.

I copied ClipSpy to the server and the workstation, then opened Notepad on my VM. Here's what happened when I copied it to the clipboard:

No password for you

What happened in the RDP session?

Well, that's different.

The content would look the same, but clearly the content is encoded differently. 

My guess is that somehow the Apache/Tomcat/servlet front-end is translating the pasted text differently from my manually entered password, and when I last changed the password (yet, they get cycled periodically) I must have entered it into the password vault first then pasted it into the change dialog to prevent typos. 

Yes. I introduced an invisible typo in the effort to prevent transcription errors.

I wondered what the application saves text into the clipboard as "natively." I entered some text into the username text box and copied it to the clipboard:

That certainly looks different.

That doesn't definitely mean that this is the type of encoding that the application is expecting or translating, but it does hint to me that it's more of a possibility that maybe the application is trying to be intelligent and accept a different encoding without translating a string to a "base type" when evaluating the password. 

In the end, I think this supports the theory that the application is caring about the inserted encoding, and doesn't force a string to be "just" a string of a particular encoding before comparing it to the stored password; my copy-pasty care may be the vector by which it became screwed up.

Whoops.

If anyone else can weigh in on this or provide a way to definitively prove if this theory is correct, I'd love to hear it!