Bad planning causing weak passwords

Question

The athletic department at my university has a facebook page and on it they said "the first 500 people to register for this event will get free t-shirts". When registering one has to create an account with a password, so that all programs they register for (now and in the future) will be billed to it. Since everyone is in such a rush I'm sure there's tons of weak passwords. Is this a viable target for an attacker? What could be done differently? Promoting to "register quickly!" is a real bad idea I realized.

Answer 1

There are two strong options:

1. Strong password requirements. This negates the problem, by forcing the user to use a strong password. It will, however, reduce conversion rates if people get frustrated.
2. Single sign-on. This involves using a 3rd party service (e.g. Facebook, Twitter, Google, OpenID, etc.) as a login service, meaning you don't actually need to create a new account.

Since the competition is being ran from Facebook, I think a single sign-on is the best choice.

However, please make sure that you're requesting the absolute minimum number of privileges necessary from the user's account. Whenever I use an app that wants to use my Twitter or Facebook account, and it says "Can post Tweets for you" or "Can see your liked pages" when all I want to do is post a comment, I don't bother. It's an unnecessary intrusion.

Answer 2

Rely on Facebook for authentication. (I.e. use single sign-on exclusively.)

Weak passwords aren't your major concern, actually. People can always change their password later. (They won't, of course, but so what? Who'd bother to use a strong password for an athletic department, even if it's for more than a free T-shift?)

The real problem is that people will reuse an existing password. The application was probably thrown together in a hurry, and looks poised to be used more and more over time. How much do you bet it's never going to leak passwords? I wouldn't bet my T-shirt on it. The less you store passwords the better.

_{(Expanding on CodesInChaos's advice (and to some extent Polynomial's), because they haven't given the real reason to use SSO.)}