Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

I'm in charge of IT at a students' organization. Let's call it FratA. FratA has ties to sister-organizations in other university cities in my country. Let's call those FratB through FratZ. These inter-organizational ties are formalized by an umbrella organization, of which FratA-FratZ are members. Let's call it SuperFrat.

SuperFrat is planning an event for all the student members of FratA-FratZ, and wants to sell tickets to the event using a web store provided by TicketSellingCorp. However, the sale of tickets should be limited to members of the organizations FratA-FratZ.

TicketSellingCorp has approached me with an unusual inquiry:

We want users to type in their username and password to the FratA-website,
 so our web store can log in behind the scenes, scrape their personal/contact information
 from their normally protected profile page and use this information for ticket sales.
Don't worry about security, we won't store passwords, and our backups are encrypted.

The main problem is that once logged in, our members can not only access their own information, but also a lot of information about other people. So if member Alice does not agree with TicketSellingCorp's proposed implementation, her information would still be exposed to TicketSellingCorp if Bob does agree.

I told TicketSellingCorp that I think this is a bad idea that conflicts our members' interests, and I offered them an openID provider (including an OSS sample client implementation) for the FratA-website; one that only tells the openID client that authentication was successful or not. It does not even share any information, such as an email address. My motivation for that is that TicketSellingCorp can ask users for that themselves, so users are responsible for sharing their own information.

TicketSellingCorp's response to this was:

We cannot implement openID in our sales process.

Is there another way to cooperate with TicketSellingCorp that does not involve exposing all our members' personal information?

share|improve this question
5  
Use another TicketSellingCorp. They clearly have no clue about security and no interest in protecting your users. –  Luc Sep 10 '13 at 7:45
    
Exactly my thought. Sadly, SuperFrat is calling the shots regarding which company to work with. –  derabbink Sep 10 '13 at 7:47
    
@derabbink - I don't see a lot of options if the company refuses to work with you. –  Ramhound Sep 10 '13 at 14:25

2 Answers 2

up vote 3 down vote accepted

How about generating a special code for each user that can be entered on TicketSellingCorp's website? You can give TicketSellingCorp a list of valid codes. TicketSellingCorp can ask users for their name and other personal info when registering, and this could optionally be checked against your own database later.

The codes should be generated randomly to prevent people from guessing other people's code (impersonating them). 128 bits of randomness should be more than enough to make sure they can't be guessed. For example an easy way to get codes is to get 16 bytes of output from a secure pseudo-random number generator (/dev/urandom or in PHP openssl_random_pseudo_bytes), then convert it to hexadecimal and store it somewhere in the database.

If TicketSellingCorp is really set on logging in with the user's account, you could make the codes work as secondary passwords that only give out certain information. Also if they're so set on doing that, I'd trust them even less.

share|improve this answer
    
That's a nice angle! I'd go even further and give each user a secondary (random) user name as well. Each secondary username is only valid for one successful try, and five unsuccessful tries, after which a new one will be generated. –  derabbink Sep 10 '13 at 8:15
2  
@derabbink Who said they need a username anyway ;). The codes are random and unique for everyone. –  Luc Sep 10 '13 at 9:05
    
I was thinking about usability: if the username is shorter than 128b (and based on dictionary entries), users might be able to spot copy-paste errors earlier. That way they'd only need to re-paste the password if the made a mistake. –  derabbink Sep 11 '13 at 8:48

We found another way of doing things: When users are signed into our website, they'll find a link that takes them to the company's "become a customer form". Part of this link are two request parameters: one (pseudo)randomly generated number, and an encrypted version of that number (a digital signature). The encryption happens asymmetrically (with our private key), and we gave the company our public key. If they can decrypt the second value, they know that the user came from us.

It's not very elegant, imho, but it works well enough.

The reason we did not opt for Luc's answer is that we suspected that our users would not understand the procedure. Also, after some back and forth with TicketSellingCorp, it turned out that they were more flexible than they initially presented themselves.

share|improve this answer
    
I've seen plenty of actions that had a code that a user needed to enter on the website. Tell them it's an "invite code" to the event? Well the case is solved so I guess it doesn't matter anymore now, I just don't see why users wouldn't understand it. –  Luc Sep 11 '13 at 9:12

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.