Mimsy Were the Borogoves

Mimsy Were the Technocrats: As long as we keep talking about it, it’s technology.

Embarrassing password tricks

Jerry Stratton, September 16, 2011

We waited longer than I would have liked switching from eight-character passwords to sixteen-character ones. By the time we switched, I think everyone else had gone to 24 or more characters. Still, it wasn’t too bad.

Then, September of last year, someone accidentally discovered that they could leave off the ninth and later characters of their password, and they asked about that. I tested on my own password, and sure enough, all I needed were the first eight characters.

I went to our password change page, and it was very clear that passwords should be “a minimum of 8 characters and a maximum of 30”.

Odd. We seem to have reverted to 8-character passwords.

There are a lot of requirements for what makes a secure password, and the password change system will verify that you have a secure password. I’ve tried it, and I tried it again here, and it enforces them:

This is tool allows you to reset your password.1

PLEASE NOTE: The new password will need to adhere to the following conditions:

  • A minimum of 8 characters and a maximum of 30
  • Must contain at least 1 numeric character
  • Must contain at least one of the following special characters: !.%#$^*()_+={}[];:,?&|/"\-@~'
  • Cannot contain < or >
  • Cannot contain username, first name or last name
  • Should not be a common word in the dictionary

But, and here’s the kicker: it does not verify their password’s security based on the first eight characters, it verifies it based on all of the characters. Even though only the first eight matter. In other words, if someone were to set their password to “password4myCollege!” it would pass the tests as a secure password. But their password would be simply “password”.

Given the way that passwords are often generated today, it isn’t unlikely that the first eight characters of a person’s password will be a simple word. The system asks for up to 30 characters. If I use a password-generation scheme of secure but easy to remember on OS X, and I set it to what I (as a non-technical user) think is a more-secure 20 to 24 characters rather than 8, I will get very secure passwords like:

tacked727!differentially

partials413754#agreeable

tabulate1875?loiters

acrobats21[enchantment

The system will let me do it, and I think I’m being secure, but my passwords are really:

tacked72

partials

tabulate

acrobats

As the system currently stands, an 8-character password is probably more secure than a longer one, because an 8-character password is less likely to be a simple word.

I suggested not only that we need to think about upgrading our systems to support longer passwords, but that more immediately we needed to change the form text and ensure that the verification process only looked at the first eight characters.

The response was “the organization won’t be changing the infrastructure for several months”. A reiteration of my suggestion to truncate the password before running the secure password check instead of afterward received no response.

Well, I have no control over that. But this September, when I realized that several months had gone by and the infrastructure remained unchanged, I decided I had better check the passwords that our webmasters are using. I don’t have any control over passwords in general, but I do manage that server.

I dumped the LDAP entries to a file, and ran a very simple password security verifier. All it did was check whether the password was “password”, “Password”, or “PASSWORD”, or the account’s username.

When I did this, it was easier to dump the full LDAP instead of filter just the webmaster group. Fortunately, only one of the webmaster accounts was this bad (it had its username as the password). But forty-six general accounts had “password” as their password and twelve had “Password”. Seven had their username as their password.

The account owners almost certainly had no idea their password was so insecure, because the password system won’t let them set a password to “password”, “Password” or even their username. It will, however, let them set their password to “password” and some random, unused characters, without telling them that those characters are unused.

I fear what a dictionary attack would yield. I ran a very simple one just on the webmaster group, and three accounts fell. It was a very simple dictionary attack. All it did was use /usr/share/dict/words, truncating each entry to the first eight characters.

I reported this just over two weeks ago. That actually received a response and a promise to at least change those passwords, but it hasn’t happened yet. As far as I know, we still have about 65 accounts with what are likely the first three passwords checked against an account when trying to hack it. They don’t know it, though, because we’ve told them that their passwords are secure.

April 26, 2013: Shared uidNumber? You have got to be kidding me!

I was just about to do some work on the student life web account, and I had to sudo into it:

[jerry@files ~]$ cd /var/www/html/studentlife/
-bash: cd: /var/www/html/studentlife/: Permission denied
[jerry@files ~]$ sudo -u studentlife -s
[sudo] password for jerry:
[randomstudent@files ~]$

Wait, what? How could I sudo to “studentlife” and end up as “randomstudent”? I did a check in LDAP, and sure enough, the studentlife web account and randomstudent (yes, name redacted, it wasn’t their fault) share the same uidNumber. For those of you who aren’t familiar with Unix account systems, the uidNumber determines what the account has access to; two accounts with the same uidNumber are for all practical purposes one account. They can each do whatever they want to the other account: view its files, modify its files, run its software, etc.

I created a high priority security ticket, then realized I’d better see if any other conflicts exist.

One thousand, five hundred, fifty-five shared uidNumbers.

This went beyond a minor glitch in account creation. I went to talk to the guy in charge of identity management.

“Yes, we know, we’re waiting to move to the new system.”

The old system they’re waiting to move from is the same system I’ve been complaining about that silently truncates passwords.1 No wonder they don’t care that our students’ passwords are easily guessed. Some of them don’t even need passwords to hack someone else’s account. Four of them potentially have access to accounts on the main web server, and at least one has access to an IT developer’s account.

Read the full post and comments

October 15, 2012: Odd rash of brute-force hacks…

A year to the day that I wrote the last update to our insecure password saga, we still haven’t fixed the password change code to at least run the security check on the first eight characters rather than run the security check on the 30-character password and then silently discard everything after eight characters.

This morning, during our weekly network meeting, the help desk reported that they’d been getting a large number of hacked account passwords over the last week sending spam. Oddly, the hacks didn’t appear to be the result of phishing attempts. “It looks like a brute force attack on passwords,” they said.

“Just a note,” I said, “our password system is extremely easy to brute-force, because we truncate secure passwords to 8-character insecure passwords without telling them. If a user sets their password to, say, password4Me at USD exclamation, and some random characters, we tell them it’s secure and then we truncate it to just ‘password’. There are several people who have very simple passwords like that.”

“We’ll be switching to a secure version of LDAP very soon,” said the person who is, in fact, doing a great job at bringing our new LDAP system online.

About a minute later, after another person described the process when an account is hacked, and how they’d been working hard to block the accounts and let the account owners know that their account had been hacked—

“And maybe now they’ll change their password.”

Guys, this time it ain’t necessarily the user’s fault.

Read the full post and comments

October 15, 2011: The most popular passwords at school

So, two months later we’re still lying to our community about the security of their passwords. We tell them that up to 30 characters are fine, and we tell them that we are checking the security of their password. But we’re not: we check the security of the password they chose, then we truncate it to eight characters.

This ends up meaning that the most popular password among our users is “password”. It’s so bad that hackers wouldn’t even need to automate getting into our system.

We have people using all of the common really bad passwords, even though the password would be rejected if the system truncated first.

  • 12345678
  • password
  • iloveyou
  • princess
  • abcdefgh
  • abcd1234

Every one of these passwords would have been rejected if entered like that. The people who have them entered longer passwords, the longer passwords were verified as relatively secure, and then the password was truncated, without telling the account owner, to eight characters.

The top ten are:

  1. password
  2. baseball
  3. football
  4. princess
  5. sunshine
  6. californ
  7. softball
  8. basketba
  9. lacrosse
  10. tie: superman, volleyba, universi, and chocolat

I’m a little disappointed that chocolate scores so low.

Out of 26,609 accounts, a total of 948 accounts fell to a simple dictionary search1; of those, 58 were “password” and eight were the account’s username. And the users aren’t to blame: they think they have a longer, more secure password, and we’ve gone out of our way to let them believe it.

Read the full post and comments

  1. Yes, I reported the typo right about the same time, a year ago. It makes this look like a phishing page.

    ↑
  1. <- Esmerelda and me
  2. JavaScript alert blocks ->