Hacker News new | past | comments | ask | show | jobs | submit login
Ask N.YC: How to import Legacy Users?
7 points by e1ven on Jan 14, 2008 | hide | past | favorite | 2 comments
For the last 9 months or so my partner and I have been working on making a new, web based version of Chron X. Chron X is the originally online collectible card game, first launched in 1997. It's a great game, but the engine is sorely out of date, and we're moving to a new revenue model. When we bought the game we knew there'd be some problems, but we've had to resort to more hacks that we imagined, particularly in getting the data out of the old database.

As we approach beta, one of the problems we're facing is legacy user authentication.

The problem is that Chron X was originally designed as part of a "collectible bits" architecture, where you would receive a file on your machine to authenticate you, rather than a username and password. This worked well enough for the game at the time, but we know that 90% of the old users have most likely lost this file.

We're trying to find a way to let them authenticate without it. The first option is to let them authenticate using their email address on file. We could send a traditional password-reset mail, and let them confirm the account. Unfortunately, since the game has been running for 11 years, I suspect that many of these addresses are no longer valid. We could allow a password-reset sent to their address, if they still have access to it.

As a fallback option, we've discussed allowing users authenticate if they remember their information, such as the address they lived in when they signed up.. We've been doing this manually by talking with them, and comparing against the DB, but obviously this solution won't scale. I'm hesitant to ask them to just type it in, since we've found that so many people don't remember exactly where which address they used, or would run into problems with spelling it, etc. The success rate for people getting the data right without prompting is sadly low. Think errors such as "Elm street", versus "West Elm Ave".

The other problem with this strategy is that many people originally registered under false information.. We have too many 123 Fake Streets- No one is going to remember exactly what they entered under such a scenario.

One idea we had was showing them the city and street for 15 random people from the database, along with their own, and asking the user to pick the correct data. I like this idea, but I can see a few problems with it..

We'd need to use some sort of hash so that we always presented the same 15 addresses, when they asked to reset that account. If we didn't do that, they could just watch to see which address didn't change. The problem is, if we did that, they might be able to just try all 15. If we instead blocked them if they tried more than 2-3, then you could preform a DOS against other accounts, by manually trying to reset their account, just to ensure that they get blocked. ;(

Has anyone had to face a problem like this before? Do you have any clever ways we could try to present data to the users, without being a wretched user-experience?




One thing I have done in a situation like this was to create an artificial hash of the user info. It ended up giving me a 95% hit rate. Something like :

Hash = SoundexOfLastName + SoundexOfStreetName + First3OfZipCode

So Jim Johnson at 123 Fair Oaks Ave in 12345 would hash to:

"J525F620123"

So just let them enter their user data, hash it, and see if you have any hits against that hash column in your data base.

Pretty hard to hack, but pretty easy to hit, even with misspellings, etc., and not a lot of suffering by the user.


A combination should work well enough.

1. Obviously allow password resets to on file email addresses.

2. If the above fails, try geocoding the address with google or geocode.us. If it successfully geocodes, ask the user for the address used to signup for the account, and tell them the zipcode the address was in so they know what address if they moved. Take the address they give you and geocode that. If they are very very close in lat-lon it is the same address (you might call this a geo-hash of the address).

3. No email and fake address? Well, this is a consequence of lying when they signed up, so you might say TFB and let them start a new account.

I can't give you more alternatives without knowing what other info you have on them, but the first two here should cover 90% of your users who didn't lie about their address based on the statistics that I pulled from my butt.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: