acm - an acm publication

Articles

Job applications and network security, or, how to not limit the online applicant pool

Ubiquity, Volume 2003 Issue April, April 01- April 30, 2003 | BY Trevis J. Rothwell 

|

Full citation in the ACM Digital Library

Employers discourage potential applicants by not offering secure methods for submitting personal information.


Employers discourage potential applicants by not offering secure methods for submitting personal information.



Browsing through online job postings, you can see that different companies list different methods of applying for jobs. Sometimes they list a postal address or a fax number, but these two options seem rare. I guess they suppose that if you are reading the job posting online, then you must be both able and willing to apply online. They are probably safe in supposing that you are able, but are they safe in supposing that you are willing?

For me personally, the answer is only yes in select situations. Online application methods pretty much boil down to two different styles: sending a resume via email and completing a form. By default, neither of these methods are secure (encrypted), but both can be. Email can be encrypted using software such as PGP, and forms can be encrypted using Secure Socket Layers (SSL) or Transport Layer Security (TLS).

Email is quick and convenient for both the sender and the receiver. One time I asked a hiring manager if I could send my resume via postal mail. He told me that he preferred email because an emailed resume can be more easily distributed to the various people involved in the employment decision than a paper resume can be.

But I have yet to see any posted email addresses mention anything about a public encryption key being available, and, as H.X. Mel and Doris Baker wrote in "Cryptography Decrypted," sending unencrypted email is a lot like sending a postcard. Most likely no one will bother to read it (except for the person you send it to, we presume!), but anyone through whose hands -- or servers -- it happens to pass would be able to do so. I would rather not send a resume's worth of personal information using this method.

Okay, so how about forms? Sometimes these obviously use secure socket connections. You can tell this when, for example, the URL begins with "https" instead of "http", and the browser shows a little picture of a closed padlock somewhere on the screen. But not all forms are so obvious about their security, if they have it at all. For me, questionable secure forms are not a good alternative.

Even when they clearly use a "secure" connection, though, there is still another question to ask of the Web site: "Which version of SSL are you using?" If it responds, "Why, I'm using SSL version 2!" then, again, I walk away from completing the form. If it responds, "SSL version 3, of course!" then I happily proceed. SSL 2 is certainly more secure than no encryption at all, but there are problems with it, and SSL 3 is noticeably better [2].

(If you do come across a Web site that appears to be using SSL 2, then you may be able to disable SSL 2 in your browser. Depending on how the server is set up, this might force an otherwise SSL 2 connection to use SSL 3, or even TLS, which is better still.)

These are some of the things that I look for when I come up on an online job application. I'm sure that there are people who might not be concerned if their resume could possibly be seen and read by an unintended recipient. But I hope that employers will realize that there are those of us who refrain from using potentially insecure network transactions for our personal data. By not offering secure methods when there are people who refuse to use anything less, they are, in effect, limiting who can apply for the jobs.

[1] Mel, H.X. and Doris Baker. "Cryptography Decrypted". Published by Addison-Wesley, 2001.

[2] Viega, John, Matt Messier, Pravir Chandra. "Network Security with OpenSSL". Published by O'Reilly & Associates, 2002.

COMMENTS

I need several article about network security

��� Habibeh, Wed, 15 Feb 2012 07:39:53 UTC

POST A COMMENT
Leave this field empty