Secure electronic signatures

As part of the Esignee project, I have done quite a bit of research on how to improve security of electronic signatures. We are already using W3C XML Signature specification to add integrity and signer identity information whenever document is signed. We also perform rigorous auditing of all user activities while he accesses the document, including collecting originating IP address and access times. However, we saw some room for improvement on the user authentication front, in other words, we wanted to add additional safeguard to make sure that the signer is who he says he is. Typically, an electronic document is sent for signature via a link in an email. A recipient then follows a link that shows the document without any authentication. This presents a few problems:

• Email is not secure and the message can be intercepted (this is referred to as the “man in the middle attack”)
• Recipient may not be the intended recipient of the email. Let’s say a realtor typed in an incorrect email and sent an offer to someone else by mistake.
• Someone else might have access to recipient’s email and they could sign the document without permission of the recipient.

So after learning about Two Factor Authentication (TFA), we decided to take the following approach. First, we wanted to make these feature optional, we figure that the sender knows best whether this document and signatures need additional security. Second, we wanted this process to be as simple as possible for the recipient. We also wanted this process to be inexpensive, we did not want our users to incur additional costs. So, how did we do it?

• We added a checkbox to our “Send document” dialog asking if the sender wants to secure the transaction with a Text message PIN.
• If the sender checks the box, he is required to provide recipients mobile phone number.
• Once the sender clicks send, we generate a random 4-digit pin and send an SMS message to the recipient in addition to the notification email.
• The recipient receives the email with a link and clicks on the link as before, however, for the secured documents he is asked to enter the pin that was sent to his mobile phone.

In the approach described above, user’s ability to access the email is the first factor (aka “something he knows” – his email credentials) and the fact that he has to have his mobile phone is the second factor (“something he has”). This solution meets our goals: it is optional for the sender, it is easy for the recipient as he does not need anything but his mobile phone and it costs us only 1 cent per message. We used Twilio API to implement our outbound SMS messaging. We loved their API: it is very easy to use – great service.