Welcome to the gallery of secure password shame, brought to you by Cockmobster.com. This series of pages will contain a rant penned by myself, the administrator, as well as screen shots of various offenders, and information specific to each offender, who claim to want you to use secure passwords, but in fact limit your choices to the insecure kind. Please forgive the page, I know the HTML is pretty bleak, but I prefer plain. I'm also trying to get the site fully set up, so over the next few weeks this should become a bit more clean.
First, the rant that began it all:
Why is it that online e-commerce providers attempt to lull us into feeling "Secure" on their web site, but don't actually allow us to utilize secure passwords and confirmation materials?
As many of you know, Blaze and I took a trip to Jamaica this year. In order to set up our butler preferences with Sandals, I was required to set up a login and password combination with them. No poblem right? Until I go to the page and see absolutely no indication that the site is secure. WTF? Sure, the POST method was perhaps over a secure connection. That's possible. But you know what? I'm not going to dig through your fucking HTML to find that out! The coup de grāce of this little fiasco was that the page wanted me to insure my password was secure...but I could only use a regexp for it.[1] Wow, real fucking secure guys. Yeah, let me just jump on my wide-open WiFi connection at Starbucks and send you my personal details entirely in the clear while the asshole next to me runs Wireshark and proceeds to grok my life. Extreme example? Yeah, a bit. Just because I know better than to do anything sensitive on an open AP, though, doesn't mean the average luser doesn't.
Today, I've forgotten my password with Amazon (handy since I'm in the process of changing them all and indexing them offline anyway) and request to reset it. Get the e-mail, follow the secure e-mail and look at it. Yep, SSL page, standard reminders (8 characters, not the same as somewhere else, etc. Not a word about disallowed characters.) I choose a nine character password that fits their criteria as laid down, and it rejects it. Hrm, okay, Maybe they don't like one of the chars. I drop the most suspect and try again. Nope. Okay. Well what the fuck, kids?!
The password is going to be dumped into an encrypted database field. SQL, to my knowledge, doesn't have any verboten characters like /etc/passwd[2]. Why may I not use the most secure password I can think of? Huh? Tell me, oh wise gurus amongst us, which of these two passwords is more secure:
c0c<-$uckk3rS!
-or-
CockSuckersAreAmazonProgrammers!
For those keeping score, or just not entirely sure, the former is more secure than the latter. Why? Because the latter, while long, will be broken quite quickly by a standard dictionary attack[3]. Remember the admonishments your administrators or hell desk always give you about setting your domain password? Yeah, same here.
I will admit that I've become a bit more paranoid since taking my new job, but you know what? Healthy paranoia and not acting like a sheep being led to the slaughter actually helps to keep us safer. Anyway, I'm off to hit up a local bricks and mortar store to pay cash for a book. Sorry Amazon, you fucked up and lost the sale (let's see, that's a CCNA training kit, a Sybex book, and a Iain M. Banks hardcover).
[1] regexp is a programming term meaning "REGular EXPression." Generally this means that the input can be one of the following: capital A through capital Z, lowercase A through Z and the numbers 0 through 9. Most encounters I've had with it specifically EXCLUDE non alpha-numeric characters (i.e. punctuation).
[2] /etc/passwd refers to the *nix[4] password file stored in the /etc directory. This file had a specific maximum chartacter limit (at least on Solaris 8, and older Linux distros. I believe HP-UX and AIX were also susceptible to the issue) of the password and could not contain the ":" character as it was the field separator for the database. Oh, did I fail to mention that? Yeah, it was a flat database.
[3] Exactly what it sounds like. You take a dictionary and throw it against a login prompt. Then your start combining the words in the dictionary and iterate through it again. Very speedy attack. I once hit my domain's SAM (Security Account Manager/Windows NT4) with a dictionary attack and got 20 of 70 accounts within the amount if time it took me to smoke. That would be a bad thing on a network for a start up.
[4] Go away. Seriously. If you can't figure this out, and actually had to read foot note 3, I don't want you reading my blog. It's over your head. Go get a bottle of Elmers with a stick and enjoy it.
So far, we have the following companies found to be offenders of this:
Sandals,
Amazon,
Pizza Hut (requires eight characters minimum, no non-alpha).
Have an example? Shoot me an e-mail, if I can verify it, I'll be happy to include the company on this page. Let's see how many companies really care about the security of their users, and how many only claim to. -The Admin, rickjames at this domain.