Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Signature capturing library for Windows 10 8

Status
Not open for further replies.

Rajesh Karunakaran

Programmer
Sep 29, 2016
542
MU
Hi friends,

Any library which can incorporate Signature Capturing onto Windows application?

I need to write an application for a Windows PC (it's in fact a small laptop kind of, say like a tablet). In a form, there will be some text at top portion for the user to read and the at bottom a signature panel. The laptop supports touch screen and hence the user may user finger to draw the signature. Otherwise also, a stylus can be used I hope.

By the way, I would certainly go for a free/opensource one. But, paid also would be an option (if not very costly).

Rajesh
 
Rajesh,

I think you'll figure out what database/table design works best for all your use cases. There still is a way signatures bound to a single signature table work best for different things by establishing N:M relationships with additional tables that have at least the signatureid and another id to relate the signature to, perhaps also a third and fourth id.

As I said a part of the file name could point to the actual person to verify that you likely thought of protecting that info as it allows to collect signature files of the same person. Well, if a hacker collects all gif files I think it's easy to group the signatures and then also find matches with names from the graphics themselves.So that kind of protection isn't necessary.

And encryption as the tool to protect the names also isn't what I'd do. The usual aim of an encryption is to decrypt what you know you need, but surely not to need to decrypt every file name before you find the one you need. So this would indicate you don't do that but create a or a few hashes from record data that you can reproduce to know the file name. But what contradicts that as a way to prevent manipulation is whatever name one GIF has, a replacement GIF just needs to have the same name. So you're not safe against that replacement manipulation, you're only safe the GIF name doesn't reveal a userid in itself.

To still stick to the idea that part of the file name enables verification of the person, using a personid hash also would mark all signatures with the same hash instead of the same id number. So if you make that a concern mor important than its use is, then you better only give the filles a name of an id that doesn't directly relate it to anything else but a signature record and additional data determins the relationship of that signature to person, purpose, appointment, date, contract or other details. That obviously makes that data a weak point for manipulations, which can always be protected with hashes and backups. Backups stored with higher security would be able to reveal manipulation even if a hacker knows what hash to compute that a record looks valid. A signature should never be changed after it has been recorded.

Someone who simply copies all GIFs would likely find signatures that can be matched to user names by some kind of OCR or manually figuring out names roughly by length/letter count. While many signatures don't allow letter counting a signature usually does have a similarity with the actual name it's for. The use case to harvest the GIFs would be to fake signatures on contracts. Employees could fake contracts to get provisions from them, though sooner or later that could shoot back at them but signatures could be used anywhere else, too.

That speaks for encrypting the gif file contents themselves, mainly. The prevents misuse of the graphics themselves, which only will be displayed or printed decrypted when necessary by users that have the permissions for these use cases. And Windows vault allows to store credentials or certificates for just one EXE, so there you gain the safety of this secret.

Chriss
 
Chriss,

Thank you for the in-depth explanation. There are many things that I had not thought of.

In fact, the client requirement in my hand, doesn't talk about any kind of high-end complex way of encryption of the files. So, initially I think, I would keep it simple. However, I can explain the security issue in keeping the image files completely open and suggest him a simple kind of encryption can be done.

Regarding the filenames, post discussions here, I wouldn't keep client code in it. It will be just the visit id and the purpose id. Then I can link a Visit-Purpose combination with corresponding images files.

Rajesh
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top