Surviving the Byte of the Cobra, part 1

Shibboleths and Shinola

As you may know, I spent years computer consulting for major corporations. I developed low regard for the so-called security found in many businesses, banks and brokerage houses, and lesser government agencies. Many so-called safety ‘features’ introduce unintended vulnerabilities.

Stick with me today and tomorrow. I’ll show you a method or so to help plug one or two security holes and help protect yourself.

Just Say No

Recently, I found myself unable to create an on-line account with my insurance company. The business published no password restrictions, so I started with something like §103NádražníBeržųStraße – I’m not kidding – I take the security of my most critical sites seriously. The system didn’t accept that, a big clue that password and privacy isn’t a high priority with them. I whittled away diacriticals and then the leading special character §, but still nothing. After reduction to a plain vanilla password, and still no access I contacted customer service, asking how to solve the problem.

Naturally the customer service lady wouldn’t put me in direct touch with IT, the people who should know. She spent roughly 15 minutes piecing together the requirements: no more than ten characters from a measly set of the 62 alphanumeric characters plus underscore and hyphen.

“You’re kidding,” I said.

“What do you mean?”

“Those are the weakest password requirements I’ve come across in a long time.”

“Oh no, sir. We’ve never been hacked, so we’re very pleased.”

“You mean you haven’t drawn the attention of hackers.” The more restrictions placed on passwords, the easier for miscreants to breach the walls.

I could feel her bristle through the phone line. “Our staff understands our needs very well, I’m sure.”

Uh-huh. I thought dryly. They could withstand a concerted attack for, well, hundreds of seconds.

The only safe solution was not to use their on-line ‘service’ at all. In the future, what little information I might need will come by telephone and US mail.

It’s 1980, No Pasting Allowed

Ever encounter a web site that won’t allow you to paste in your password? Sure you have, and it’s frustrating as hell. Worse, it adds vulnerabilities rather than resolves them.

Years ago, some misguided ‘expert’ decided password paste prevention sounded pretty cool, and lo, he advised others about his really cool hypothesis. It turned out wrong, dead wrong.

Preventing pasting discourages visitors from using long, complex passwords, prevents utilizing password managers, and makes it easy for cracking hardware and software ‘keyloggers’– to monitor what you type in. Even the task group within NIST, the US National Institute of Standards and Technology, advises against disabling password pasting.

Clearly a number of corporations didn’t get the memo. What can a trapped user do? A few suggestions come to mind.

The web page may disable pasting keyboard shortcut but not disable the menu paste entry. This occurs often enough, it’s worth trying first.

A second possibility is to temporarily disable JavaScript. After doing it a couple of times, it doesn’t take long, certainly less time than blindly typing in a long string. Simply bring up the web page. When you reach the field that won’t let you paste, disable JavaScript by invoking Preferences, click Disable JavaScript in the Security or Privacy tabs, paste your password, and immediately re-engage JavaScript. (Note: This doesn’t work with Firefox, which won’t let users disable JavaScript.)

If that fails, try to resist using a short and simple password, one reason why this disagreeable ‘feature’ is so dangerous.

When It’s All About Length

I came across a bug in a popular web site. The registration web page happily accepted my lengthy password, but would not allow me to sign on.

I learned the site used an unadvertised maximum limit of 20 characters. Further investigation concluded it didn’t limit or validate the length of the password string. The registration page stored a function of the first 20 characters, no matter how many were entered. The sign-on page also didn’t check the limit of characters, but simply compared its value with the stored value, resulting in a mismatch.

In other words, I tried to register AbCdEfGhIjKlMnOpQrStUvWxYz, but the program stored AbCdEfGhIjKlMnOpQrSt. When I tried to sign on, the page compared the stored AbCdEfGhIjKlMnOpQrSt with the sign-on value of AbCdEfGhIjKlMnOpQrStUvWxYz and failed, a stupid programming error. (Engineers will note I’m grossly simplifying a hash encryption function.) Bad, bad program design.

© BBB

Mine’s Smaller Than Yours

A web site’s failure to validate the length of a password allowed me to pull off a silly little trick of questionable value. In the early days of the Web before it came under attack by Russian crackers and North Korean ransomware, I’d registered at a particular web site with a short password.

Years later, alarmed at attacks occurring worldwide, the site instituted stricter registration policies, including using lengthy password minimums double the length of mine. They validated new password lengths at registration, but not during sign-on.

The site wasn’t critical for me, which led to an idiosyncratic decision to keep my old, deprecated password. A brute-force attacker would likely note updated site rules that passwords must run at least twelve characters in length. If so, my dinky little password ought to sail under their radar. (And if not, I could live without the site.)

Tomorrow… Cobras and those pesky and perilous personal mystery questions.