Tell me more ×
User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It's 100% free, no registration required.
up vote 4 down vote favorite
1

I'm in the process of planning a web app which will offer an advice service to people who earn above a certain salary threshold. The thinking is that the new users will be procured through their banks.

So far I see two different ways of allowing signup to the app.

  1. Batches of one-use random codes (10 digit hex or similar) are handed to the banks on printed cards or similar to give out to eligible users. The user then enters the code on the landing page of the site which will look this up against a database of valid codes and allow access if valid.

  2. I think the above option will work fine, but then I got thinking "Well an email address is a unique identifier that we all have". If the bank could somehow submit the eligible users email to the app this would remove the need for the cards (and associated printing costs etc). The only issue here is creating a separate api (albeit a simple one), for the banks to use and creating logins for each user.

I'd really appreciate some opinions on the above 2 options in terms of which presents a better UX and a more sensible approach. Even better if anybody has a solution to this that hasn't crossed my mind, that'd be great too.

share|improve this question
Why are you restricting access to your site in the first place? Is there a reason you're not going wit the standard sign up page, with a standard login (including oAuth)? If you want to identify which bank a user is using, or coming from, ask them for that information during the login process – blueberryfields Apr 14 '12 at 15:42
Thanks for your reply. The choice to restrict access based on user's salary isn't my choice but the reason for it is the following: Registered users will be granted free telephone consultations with financial professionals. These hand-picked professionals (the best in their respective fields) are seeking quality leads and ultimately paid work and they believe users who earn £40K+ will be more likely to earn them more in fees. The user's salary is validated by the bank prior to referring them to the service. – Matt Harrison Apr 14 '12 at 17:22
1  
Note that if you go the one-use codes, people can sell them. – Ben Brocka♦ Apr 14 '12 at 20:46

1 Answer

up vote 4 down vote accepted

There are pros and cons to each method.

  1. As Ben points out the one-use codes could be sold on (or given away) to people who don't qualify.

  2. Using the customer's e-mail address could well be seen to be intrusive. The bank would have to ask the customer's permission to sign them up for the service - after all they are passing the customer's details (their e-mail) to a 3rd party (you).

A better approach might be to allow the bank to e-mail the customer with a code that's generated from the customer e-mail address - but you don't store the e-mail address. Basically use a password hashing type algorithm. You can then use the e-mail address the customer uses to sign up with to regenerate the code to validate that it's the same person.

share|improve this answer
That's an interesting solution Chris and one that I hadn't considered. It seems to solve all of the above issues in a creative way. It also means no in-person contact needs to be made with the banks customers. They could simply email everyone who passes the criteria and there would be no concerns about selling on codes etc. – Matt Harrison Apr 14 '12 at 21:45
If a smart user figures out (or tries all the obvious) hashing functions with their own email address they could potentially sign up couldn't they? I guess the solution to that would be salting the hash with a closely kept secret salt (obviously this would have be shared with the bank). – Matt Harrison Apr 14 '12 at 22:23
@MattHarrison - Yeah, there are draw backs with my solution. You wouldn't need to share the salt with the bank. They give you the e-mail, you return the code and throw away the e-mail. – ChrisF Apr 14 '12 at 22:24
I don't see how generating a unique ID and emailing it to the customer is any different to just using their email address and informing them (by email) that their email is their login ID. Both options use the clients email address, why add extra complications? – JonW♦ Apr 15 '12 at 0:26
This would be true Jon. But this would mean anybody could then signup with their email address who had a link to the registration page. The whole point is about restricting access to eligible users. The one-way cryptographic hash is a good way of doing this because both the bank and me agreed on an algorithm and they never have to share any of their customers sensitive information with me, the users come willingly and I have a method on hand with which to validate them. – Matt Harrison Apr 15 '12 at 9:06

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.