I'm planning on using an online contract form where customers will agree to certain terms and conditions and sign with an electronic signature (using the mouse to spell their name). I'm wondering if this type of signature should be encrypted or if this information doesn't really need the extra layer of protection. Ideally I think having the extra layer of protection would be a good choice, but I'm a little strapped on cash.
You can get certificate for free from Let’s Encrypt. Its better than nothing.
Related
First of all, a bit of background - the actual questions are at the bottom.
I'm currently working on a web-based app (sort of SaaS) which allows users to send forms to their own customers.
These forms are simple, small contracts for small jobs where their customers say "Yeah sure, I'll do this and here's my confirmation".
The sort of thing that is being "signed" does not require a fully qualified digital signature and an electronic signature will suffice.
While, in this case, a simple checkbox saying "Yeah, I'll do this" would legally be sufficient, I'm keen to implement it with a signature pad. To be honest, it's just for the factor of being seemingly more binding and, well, "neat".
The current workflow looks like this:
User's customer opens web-form (the party being asked to sign is the only person in the universe to know the direct link)
Ticks a few boxes and enters text
Clicks "Sign" which opens an HTML5 signature pad (mobile) or a simple input (PC) to type their name
Clicks "Accept"
A PDF is generated for download and stored on the server (along with timestamp, IP, and a couple of other bits of information)
As you can see, the agreement in its entirety constitutes a simple electronic signature - even without the bells and whistles.
What I would like to do
As with any simple electronic signature, it's easy for any party to say that a document may have been tampered with.
So what I did is properly sign the PDF according to the specifications (using tcpdf): that entailed first generating the PDF and then adding the signature to the /Sig dictionary, then generating a digest across all byte-ranges (excluding the signature), linking it up with a .crt file and voilá: the document is signed with the lovely benefit of the signature becoming invalid if even a single byte is changed.
Now to the questions:
Is it possible to benefit from the "tamper-validation" without using a certificate? Like I say, these are not supposed to be digital signatures but rather simple, electronic signatures. Still, I'd like to benefit from any post-signature changes being highlighted.
Alternatively, I could also simply use a proper certificate for the signing process. But this certificate would be mine rather than my users' or even my users' customers'. In that sense, would it do more harm than good? I.e. the certificate belongs to the wrong party and therefore becomes meaningless; I, rather than the signatory vouches; "The document was changed and re-signed after I signed"; etc.
Is it possible to benefit from the "tamper-validation" without using a certificate? Like I say, these are not supposed to be digital signatures but rather simple, electronic signatures. Still, I'd like to benefit from any post-signature changes being highlighted.
No, at least as long as you want to do this in an interoperable way.
You can of course invent your own security system, create a PDF viewer or at least plugins for the commonly used PDF viewers to support your system, and roll these programs out to your users.
But if you want existing Adobe Reader as-is to verify the signature, you've got to go the X509 PKI way.
Alternatively, I could also simply use a proper certificate for the signing process. But this certificate would be mine rather than my users' or even my users' customers'. In that sense, would it do more harm than good? I.e. the certificate belongs to the wrong party and therefore becomes meaningless; I, rather than the signatory vouches; "The document was changed and re-signed after I signed"; etc.
When using your own certificate for signing, don't forget to properly fill the reason field so it indicates that your signature is applied as a counter signature to guarantee validatability.
With that in place I don't see your signature doing any harm.
The question is how much good it does, though.
Obviously the user still can claim that he signed something different... because he did! He signed the web form, not the PDF. Thus, you might have to provide proof that the PDF reflects exactly what the web form showed anyways, that the user signed something equivalent.
If you want actual non-repudiation by the user, you need to make him sign personally in a manner that is commonly accepted to not allow tampering. In other words, your user needs to apply proper digital signatures himself. Everything else is open to claims of forgery.
You can use trusted time-stamp (defined in RFC3161) instead of signature created by the customer or by your server. Time-stamp protects document integrity and proves that your document existed before a particular time. Technically speaking it is a digital signature created by a trusted 3rd party.
I am currently working on a project that deals with sensitivity customer data, and we are being recommended to use Digital Signatures as appose to Electronic Signatures due to its new scale and the sensitive nature of the customers' data.
I personally don't know what the legal issues are with Digital Signatures, but I know that sometimes a Certificate Authority are needed?
This program is being written in C# visual studios if that matters, but I don't really know where to start with this process. I know it works like a public and private key encryption , a Public Key Infrastructure, but I have been informed that you must "buy" a certification from a Certificate authority. You could also create your own?
I was also informed that I need to make sure this would also allow documents created by our program to be legally binding in the USA. That certain laws and procedures are different in different countries so I need to make sure these are in order before I even start coding.
I'm sorry if this sounds more like a legal question then a coding question. My searches aren't helping and I can't start coding until I know what I can and can't do.
SSL encrypts the data channel. It can be broken by the NSA and perhaps others but it is considered quite hard to do so.
I certainly think it is a reasonable and appropriate level of data security for many uses, but that is merely my personal opinion.
Digital Signatures do not encrypt your data. Digital signatures sign your data, assuring you and the recipients that the data was not changed en route, and giving you confidence that you know who signed the data.
You can use a digital certificate purchased from a certificate authority to sign data. Or you can create a self-signed key for your organization and then use subordinate signer keys. We have many many customers who do this.
Documents signed with digital signatures are legally binding everywhere in the world. In some jurisdictions, for some purposes, you need a qualified digital signature. That means that the certificate was issued to the signer by a recognized national certificate authority.
I suggest that you are a ways from coding--you need to better understand your business requirements first.
With digital signatures, protecting the security of the signers' private keys is extremely important. These days, centralized hardware-hardened appliances are often used.
Here are some APIs which make it easy to digitally sign documents and data while managing the keys via an appliance.
Disclosure: I work for CoSign.
I'm just wondering if I should encrypt user contact information when I store it in the database?
E.g. emails, phone numbers etc...
Normally you only encrypt sensitive information, and this depends on your project requirements. If the user email or phone number is sensitive, encrypt it. On the other hand, as you will need to get the contact information from database, you will use symetric encryption, and it is easy to desencrypt, so your "security" in this case is only ofuscating data and is not strong enough.
Anyway, you should always encrypt the sensitive data such as password, and I suggest assymetric encryption with hash.
In my projects I never needed to encrypt any contact information, and only passwords are encrypted on the database. If you are implementing web application, I suggest you to use security tokens (claim based security) and make all contact information to be encrypted while travel on the net (by using message or transport security) so there are very low risk to disclose any contact information to the third party.
I'm going to address the broader question: Should I encrypt?
In my VERY humble opinion, if the information is in any way associated with a person's identity and there is public access to your site or network, the answer is a resounding YES. I'll ignore the technical complexities of indexing and searching encrypted information and just give you the following to think about:
Identity and credit-card thieves and are not likely to get all your information from one source.
Information they are likely to pursue in pieces are broad. Name,
address, phone, CC number and expiration date, etc...
Once a person possesses fragmented records, all that information can
be used in an attempt to associated one fragmented record with
another. IE, John Smith in Garland, TX is likely to be J Smith at
1111 Some Dr, Garland, TX.
Once successfully associated, fragmented records from YOUR data
combined with fragmented records from MY data become a complete
record, then OUR customer's life is a wreck.
This is a very simplified path, and lots of information is public record so in one sense protecting it is a moot point. However, if you are slapped with a lawsuit, and it DOES happen, that may be of little comfort when you're coughing up $500 a hour to your attorney.
Encrypting contact information only makes sense if you expect your security to be compromised or know that untrustworthy people will have direct access to your database.
One-way encryption (hashing) will render your data useless since there is no way to retrieve it so you'll have to use some form of reversible encryption.
Encrypting contact info in your database will have a couple of downsides, most notably:
Encryption is not free, it takes time to process the data
You cannot search the encrypted data based on partial data like a partial contact name
Note that the weakness of reversible encryption lies with the key required for decryption. Don't store that in the same database.
Using transport layer security (like SSL) makes more sense.
I have been following a couple of articles regarding RESTful web services with WCF and more specifically, how to go about authentication in these. The main article I have been referencing is Aaron Skonnard's RESTful Web Services with WCF 3.5. Another one that specifically deals with HMAC authentication is Itai Goldstiens article which is based on Skonnards article.
I am confused about the "User Key" that is referenced to in both articles. I have a client application that is going to require a user to have both a user name and password.
Does this then mean that the key I use to initialise the
System.Security.Cryptography.HMACMD5 class is simply the users
password?
Given the method used to create the Mac in Itai's article
(shown below), am I right is thinking that key is the users
password and text is the string we are using confirm that the
details are in fact correct?
public static string EncodeText(byte[] key, string text, Encoding encoding)
{
HMACMD5 hmacMD5 = new HMACMD5(key);
byte[] textBytes = encoding.GetBytes(text);
byte[] encodedTextBytes =
hmacMD5.ComputeHash(textBytes);
string encodedText =
Convert.ToBase64String(encodedTextBytes);
return encodedText;
}
In my example, the text parameter would be a combination of request uri, a shared secret and timestamp (which will be available as a request header and used to prevent replay attacks).
Is this form of authentication decent? I've come across another thread here that suggests that the method defined in the articles above is "..a (sic) ugly hack." The author doesn't suggest why, but it is discouraging given that I've spent a few hours reading about this and getting it working. However, it's worth noting that the accepted answer on this question talks about a custom HMAC authorisation scheme so it is possible the ugly hack reference is simply the implementation of it rather than the use of HMAC algorithms themselves.
The diagram below if from the wikipedia article on Message Authentication Code. I feel like this should be a secure way to go, but I just want to make sure I understand it's use correctly and also make sure this isn't simply some dated mechanism that has been surpassed by something much better.
The key can be the user's password, but you absolutely should not do this.
First - the key has an optimal length equal to the size of the output hash, and a user's password will rarely be equal to that.
Second, there will never be enough randomness (entropy to use the technical term) in those bytes to be an adequate key.
Third, although you're preventing replay attacks, you're allowing anyone potentially to sign any kind of request, assuming they can also get hold of the shared secret (is that broadcast by the server at some point or is it derived only on the client and server? If broadcast, a man-in-the-middle attack can easily grab and store that - height of paranoia, yes, but I think you should think about it) unless the user changes their password.
Fourth - stop using HMACMD5 - use HMAC-SHA-256 as a minimum.
This key should at the very least be a series of bytes that are generated from the user's password - typically using something like PBKDF2 - however you should also include something transitory that is session-based and which, ideally, can't be known by an attacker.
That said, a lot of people might tell you that I'm being far too paranoid.
Personally I know I'm not an expert in authentication - it's a very delicate balancing act - so I rely on peer-reviewed and proven technologies. SSL (in this case authentication via client certificates), for example, might have it's weaknesses, but most people use it and if one of my systems gets exploited because of an SSL weakness, it's not going to be my fault. However if an exploit occurs because of some weakness that I wasn't clever enough to identify? I'd kick myself out of the front door.
Indidentally, for my rest services I now use SCRAM for authentication, using SHA512 and 512 bits of random salt for the stretching operation (many people will say that's excessive, but I won't have to change it for a while!), and then use a secure token (signed with an HMAC and encrypted with AES) derived from the authentication and other server-only-known information to persist an authenticated session. The token is stateless in the same way that Asp.Net forms authentication cookies are.
The password exchange works very well indeed, is secure even without SSL (in protecting the password) and has the added advantage of authenticating both client and server. The session persistence can be tuned based on the site and client - the token carries its own expiry and absolute expiry values within it, and these can be tuned easily. By encrypting client ID information into that token as well, it's possible to prevent duplication on to another machine by simply comparing the decrypted values from the client-supplied values. Only thing about that is watching out for IP address information, yes it can be spoofed but, primarily, you have to consider legitimate users on roaming networks.
I've been given the task of finding and evaluating some authentication libraries for use in one of our products and one of the selling features being pushed by some solutions is "two-factor authentication".
What is this method and how does it work? Are there better methods (such as three-factor authentication, I guess)?
Two factor authentication is using two factors to authenticate a person (or sometimes a process).
This might be a PIN number (something you know) and a debit card (something you have).
There are many authentication factors that might be used:
Authentication factors apply for a
special procedure of authenticating a
person as an individual with
definitively granted access rights.
There are different factor types for
authentication:
Human factors are inherently bound to the individual, for example
biometrics ("Something you are").
Personal factors are otherwise mentally or physically allocated to
the individual as for example learned
code numbers. ("Something you know")
Technical factors are bound to physical means as for example a pass,
an ID card or a token. ("Something you
have")
From wikipedia.
Which factors you choose depend on the type of access required, security needed, cost, and especially what people are willing to put up with.
People get irritated with strong passwords that change every 4 months, so you might find employees happier with laptops that have fingerprint scanners and they can use a weak password and a fingerprint - two factor authentication may be easier for users.
But others might not like the privacy implications of biometric security and would rather carry around a keychain device that produces numbers which are typed in along with a password.
High security situations may require all three factors - something you have such as a card, something you are such as retinal imaging, and something you know such as a password.
But the costs and irritation go up as you add more levels.
-Adam
"Are there better methods (such as three-factor authentication, I guess)?"
The issue isn't simply more factors. It's a better mix of factors.
Passwords are easily lost and compromised. People write them on stickies and put them on the bottom of their keyboards.
Other non-password factors are part of the mix. For browser-based apps, you can use IP address, and other PC-specific material that floats in as part of the HTTP headers. For desktop apps (like VPN connections) independent key generators or plug-in USB readers might provide additional factors.
Its when two (or more) different factors are used in conjunction to authenticate someone.
For example, a bank might ask you for your account number and pin number. And sometimes, like when you call call centers, they might ask you for additional factors such as name, dob, phone number, address etc.
The theory is that the more factors you can authenticate against, the higher the probability that you are dealing with the correct person. How well it works and how much more secure it is is debatable in my opinion...
Factors include:
Human factors are inherently bound to the individual, for example
biometrics ("Something you are").
Personal factors are otherwise mentally or physically allocated to
the individual as for example learned
code numbers. ("Something you know")
Technical factors are bound to physical means as for example a pass,
an ID card or a token. ("Something
you have")
See: http://en.wikipedia.org/wiki/Two-factor_authentication
I'll take this from a completely different tact. All these answers are correct, of course, but I want to broaden the topic a bit - to think about where & when to apply two-factor authentication. There are three areas where strong authentication can be used: session authentication, mutual authentication and transaction authentication. Session auth is what most people think about when they think about 2FA. But imagine if people only had to use an OTP when making a banking transaction. The attack surface goes from "when logged in" to "When making a transaction", which is much smaller. if the transaction authentication uses a public key system to sign the tx, then all the better.
Mutual authentication is some system that attempts to thwart MiTM attacks. You can think of the little pictures some banking sites use, but they are totally ineffectual because there is no crypto involved. here's how we do mutual auth, by validating the site's ssl cert for the user: http://www.wikidsystems.com/learn-more/technology/mutual_authentication/. There are other ways to do the same thing, of course.