Packing up my "Second Life" store.

Yes, the moment has finally arrived.  I started experimenting with the "Second Life" platform in 2005, become moderately in successful in 2006 but since then, after the 2007 boom, interest and traffic has kept decreasing at a steady rate.

When my latest hosting bill came in, the profit number finally fell below zero and turned red.

It's been a good run, but I have a first life to deal with. If anybody of the SL crowd is interested in any of the systems I have built in the past, drop me a line.

Hall of shame: Western Digital

When setting up my otherwise pretty nifty NAS, I stumbled on this error message when setting up the administrator password.  This leads me to the usual questions:

1. Why limit to 16 characters?  Are you storing this in plaintext, and is that the size you allocated for it?
2. Why do "double quotes"?  Are you not trusting your own input validation and escaping routines?
3. What's up with the double errors? Does your system have a stutter?
4. Why not let me know before I enter my password, what the requirements of said password are?

 

 

Hall of shame: Ticketmaster.com

There are many reason why I despise Ticketmaster, such as their ridulous "because we can" fees, "convenience fee for using the website", "fee for printing your own tickets on your own paper, using your own printer, with various ads on it", etc. 

But this series is about security worst practices, so here goes another password FAIL. 

Extra points for having a timer that gives people 90 seconds to fill in the form, come up with a secure password, and read the T.O.S. and privacy policy (each a couple dozen pages).

Hall of shame: Priceline.com

When creating an account, I'm asked for my "preferred internet password". 
Seriously?Sound like marketing-speak for "Go ahead and reuse the password here that you use on facebook and bofa.  We don't mind!".

Shame on you for encouraging bad behaviour!

One extra point for "default opt-in"ing the user to the marketing spam. 

Hall of shame: Mediafire

Let's see:
You have a nice "password strength" meter, but once one submits the form, it repeats back the password in the clear, complains that its too long, and can't have any "special" characters.

Why would that matter, since the password hash would be the same regardless of length? You are securely hashing the passwords, and not storing them in the database as plain-text, right? Right?





Also, can you tell me exactly what the difference is between a special character and a non-special one?  Is it "special" when it causes a SQL Injection vulnerability (which of course you would defense against by properly escaping database inputs), when storing it in the password in plain-text (which of course you don't do) ?

BTW: I don't think I will be trusting you with access to my Facebook account just yet. Hope you don't mind.

Update:
I have proof that they store password "in the clear": The password test is case-insensitive!
You can try this out yourself:
If your password is "joshua", you can log in using "JOSHUA" or "JoSHuA".    This is only possible if the site doesn't use any password hashing at all.   Security 101 FAIL!