Beware the Password Limitation That is Not Validated

“You know the phone system is still using the default username and password?” I asked the accountant over my IP phone.

Two and a half years ago a Samsung phone system had been donated to a small non profit that I do some work for. It’s a nice system, at least as far as I can tell. I know very little about phone systems, but from the manuals that I’ve perused and webinars that I sat in on I’ve been generally impressed. I usually leave it alone, though. My only venture into its guts was to add my IP phone to it. In spite of being 600 miles away from the office, I was just an extension away. Ahh, technology.

However, in the last few weeks I’ve noticed an increase in problems with the phones. One problem in particular made me decide to log into the system and see if I could sleuth my way to a solution. An extension suddenly failed and now leaves that line open constantly. Nothing can be dialed in or out. The user switched ports on the wall, but now has someone else’s extension and user information on their phone (one that no longer uses their phone). Logging into the system, which incidentally has a public IP address, made me remember that the default login details were never changed.

“Sounds like that would be a good idea,” he said, reiterating what I knew.

The accountant is my main contact at the business. He’s the one who most understands IT’s importance, which is fortunate since he also approves purchases. I was sharing his screen using Dameware MRC from my home office and we were both looking at the login on the Samsung phone system. My intention was to illustrate to him first hand some of the difficulties I had been having as I tried to track down some of the phone system problems and thus encourage the business to make a call to the real phone technician.

I navigated to the place where the password could be changed.

“What to put… what to put…” I mumbled into the mouthpiece. “It’s got to be something that the phone guy can remember, so none of my infamous 24 character random strings.”

“How about ‘I’m late for a very important date’?” he suggested.

“Not bad, I do prefer pass-phrases to passwords. Let’s mix it up a bit though.”

I typed in “imLATEforAveryIMPORTANTdate”

“That should be secure enough!” I said triumphantly. However, my spidey sense tingled as I looked at the long password. Maybe it’s because I’ve been doing this for less than a decade. Maybe it’s that I don’t think very much of my skills. Whatever the cause, I didn’t say anything about my uneasiness much less act on it.

I’ve been around long enough to know that password fields are sketchy things. Many a bank has scraped their virtual fingernails down my virtual blackboard by making their passwords restricted to a certain length or not including special characters or both. Many old systems on networks can only handle lower case passwords.

“Let’s see if it accepts it.” I clicked the button to save the new password.

No error messages were seen.

The accountant chuckled, “So now how do we test it to see if it works? Log out and try to log in?”

“Pretty much,” my voice gently hued with doubt. I just… I just didn’t feel right.  I logged out and typed the username in but pasted the password just to make sure it was the same one I put into the backend.

I clicked the login button. The page paused for a few seconds and then refreshed. No errors, no complaints. Just a fresh login screen. The bad feeling inside began to hold its head a little higher.

“Let me try this on another computer.” That’s my first troubleshooting technique. Try it on my PC. Maybe it’s everyone else that’s gone crazy.

I switched windows from the remote session with the accountant back to my PC. I wanted to make sure that I had the password on my clipboard and not some other text so I pasted it into the username field so that I could see what the text actually was. It was then that I noticed something… odd.

Username: imLATEforAveryIMPORT

Suddenly, things started making sense, but in a twisted way. I pasted the clipboard into a test document: imLATEforAveryIMPORTANTdate. “Okay, I’ve got the full string in there.” I then pasted it into the password field. I saw nothing but stars, but I arrowed through each of them and counted twenty characters from start to finish. The password was 27 characters. I forlornly hit the login button, but the response was the same. The login page merely refreshed.

On a whim I decided to put the former username and password in; the default set. That time I got an explicit error that whined about the username and password being wrong. That was truly odd. Somehow the 27 character password, even cut down to 20 characters, was not being seen as the wrong password, but yet it wasn’t allowing access. I imagine that it had something to do with hashes that were matching to a point, but still weren’t long enough. I wasn’t sure.

The phone guy will be getting a call in the very near future.

The Moral

First, expect security account management to be terribly implemented. Everywhere.

Second, always know beforehand what the account creation limitations are. Usernames, passwords, keys, whatever.

Third, know before changing anything what the account reset procedures and consequences are. Fortunately, from what I’ve seen so far, the admin account can be set back to default without blanking out the entire system. However, it takes some handset know-how that I think I’ll leave for the true phone tech.

Fourth, expect that limitations are not verified and know that just because the account information was accepted does not mean it was allowed. Test it out. After you test it, be happy that you followed step 2.

Do you have any similar password stories to share? Let me know in the comments below or link me to your story (or you can write it and post it on my blog; just contact me)


  1. Jinks

    July 18, 2011 at 2:31 pm

    One thing you could try is to modify the password entry field in place (via Firefox WebDeveloper Toolbar or some such) and set the length to more than 27 characters. depending on the particular interface you might also need to fiddle with some javascripts.


    • Wesley David

      July 18, 2011 at 2:38 pm

      You know, I had considered that there may very well have been a way to hack this thing to work. I noticed that some PHP scripts are bounced back and forth in the login process. I also am intrigued by the password not being outright rejected like it is when I put something completely wrong in.

      The only thing stopping me is that I think in the long run it would cost them more for me to tweak the stuff than to just get the phone guy in the building and let me get on with other projects. =)


    • Wesley David

      July 18, 2011 at 2:39 pm

      P.S. Thanks for the tip about the WebDeveloper Toolbar! I hadn’t considered that specific tactic.


  2. Jacob

    July 20, 2011 at 5:52 pm

    So, how did you fix the problem?


    • Wesley David

      July 20, 2011 at 6:05 pm

      I wrote a note to call the phone guy sometime in August. =) We’ll see if he can work this out.


  3. […] typically use pass phrases for myself and clients. It’s gotten me into a bit of trouble in the past. In short, I changed the password on a public facing phone system interface to one that was longer […]


Leave a Reply

Follow TheNubbyAdmin!

follow us in feedly

Raw RSS Feed:

Contact Me!

Want to hire me as a consultant? Have a job you think I might be interested in? Drop me a line:

Contact Me!

Subscribe via Email

Your email address is handled by Google FeedBurner and never spammed!

The Nubby Archives

Circle Me on Google+!

Photos from Flickr

Me on StackExchange

The IT Crowd Strava Group

%d bloggers like this: