Jump to content

[SOLVED] Really tricky app- confidentiality/authentication -- Gurus?


Donny Bahama

Recommended Posts

As the CEO of a very cool new startup, I need to approach certain "people of notoriety" about a rather important business matter and make some highly confidential/extremely valuable data (docs) viewable to them. To protect my intellectual property, I have to convince them to sign an online confidentiality agreement (NDA). To that end, my General Counsel has drawn up a very simple yet bulletproof NDA that's written in plain English. This makes it very easy and clear for them so that they don't feel a need to consult with their attorney before "signing" it.

 

The problem is, these "people of notoriety" are the kind of people that you can't just call and schedule a meeting with. Nor can you email them directly because they keep their @ddress secret. They *can* be reached, but they have to be approached via their assistants, agents, representatives, etc.

 

My intitial contact with them is an email, generated by a web form. I enter their name, a "distinction" (i.e. a bit of text such as "Founder and CEO of Apple, Inc." that describes him and distinguishes him from some other "Steve Jobs") and whatever @ddress I have for an administrative assistant, etc. (OK, bad example, I actually have Steve Jobs @ddress. :D) I use checkboxes to specify which docs he gets to see, customize the text, then submit the form.

 

The code stores his first name, last name, "distinction" and @ddress to a database. An md5 hash is created from this data and appended to secure.domain.tld/nda.php Another hash is created and includes the current date and time along with appended and prepended random-length salt from a known source string. This is also stored in the database. (The point here, is being able to recreate the hash in a court of law, thus proving who the email was sent to and on what time and date. This is in addition to the blind copy that's sent to me when the email is sent.) This second hash is sent within the email as a single use "digital signature".

 

If the nda.php file is accessed without the querystring, the user is redirected (after logging IP and hostname details and alerting me via email to the access violation.) Likewise, if the hash doesn't match a record in the database. If it does match, though, the NDA is displayed, with the user's personal info all filled out.

 

They are asked to paste the "digital signature" from the email into the NDA form in order to "sign it". (There's also a couple checkboxes and a submit button to "Accept All Terms and Continue".)

 

Once they've signed the NDA and been authenticated, (and all of this is still theoretical due to the issues below,) they are linked to a menu page (created on-the-fly with symlinks to the actual documents (which are stored outside the public_html structure)) The documents are presentations and are protected from being cached. The final "next" button returns them to the menu page, at which point the date and time are logged and that particular symlink is destroyed.

 

OK. That's the background. Now for the issues...

 

Problem #1: Before getting to the intended person, the email will pass through one or more other people who are definitely NOT authorized to view the goods. Any of them could click the link and impersonate Jeffrey Zucker by pasting the "digital signature" from the email into the NDA, checking the checkboxes and clicking the submit button. Mr. Zucker then has plausible deniability. "I did not authorize my secretary to view that information and I never saw it. You can't prove I stole a multi-billion dollar idea from you."

 

Problem #2: Obviously these people are important and busy people. I can get their attention with my initial email. (The statements I make are very bold, and all true.) BUT, the more cumbersome I make it for them to click through, sign the NDA and view the documents, the more likely they are to decide that they are "far too busy for this crap".

 

One possible solution to #1 is to require the user to authenticate himself via email (in much the same way as we all signed up for this forum) -- with a transparent interim step of sending it to me for approval. If the email says "mark.cuban at hdnet.com" is signing your NDA, I click the approve link and Mr. Cuban gets an email with a personalized link to the presentation menu page. But if it says, bob.jones at hotmail.com, I click deny (and Bob Jones gets an automated nastygram with a lot of threatening legalese.)

 

I thought about making the initial email take them to a page that explains why I need to authenticate them (along with a warning to would-be impersonators and a mention of their IP address and hostname). They fill in their email address and click submit, I regenerate their session ID, hash it, and include it as the querystring in the url of the link to the NDA page. They click the link, I match their session ID - now they're authenticated and there's no longer any need to copy and paste any sort of "digital signature".

 

Of course, all of that adds complexity that conflicts with problem #2! (Plus, there are probably issues with session ID security that may come into play, here.)

 

I think that describes the problems (and my approach) in the necessary detail. I'm really hoping someone has some good creative ideas for making this simpler and better. If you made it this far, thanks for taking the time to read my novella!

Link to comment
Share on other sites

This thread is more than a year old. Please don't revive it unless you have something important to add.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.