Hacking: Changing/Forging Signatures in SQL

Jaymer

NOTE: This isn't necc. related to Aware, or an Aware-specific problem. It could happen if you used PHP & MySQL.

Recently I started using a Signature field - which is an Image created by a JavaScript widget.
To the database, Its really no different than if you had your Signature saved as a .jpg and you uploaded it.
It can be saved in the database (the older way) or in the file system.

And then it dawned on me... a whole directory structure under \Tomcat\webapps\AwareIM... filled with people's signatures.
And something unsettling comes over me.

(Again, I want to stress this isn't really an Aware issue.)
So what unsettles me (a tiny bit) is how systems can be circumvented/falsified/doctored, etc. by an unscrupulous person - OF COURSE this is true on ANY platform with ANY TOOL.
I mean, its not just limited to a Signature .jpg.
While I can't see and "know" someone's Aware password (cause its encrypted), I could copy/paste in a known password, log in as that user, do something, and change it back. ... AS A BACKEND USER/EMPLOYEE WHO HAS ACCESS TO THE DATABASE.
Of course I could do this years ago using PHPMyAdmin.
(And I actually CAN see their real password in some circumstances - which I guess is one reason "they" say to not re-use important passwords across systems!)

Mark Bailey is having to go through a ISO 27001 certification.
And while I don't know specifically whats in that, I read something about how many/most data breaches happen from an "insider".
And even if you kept the data IN the database encrypted (which many of us DO NOT), a company should have 2 teams that don't overlap - you can't have a person who has access to the back end raw SQL data ALSO be a person who generates the encryption keys - cause then they can get to data - a potential data breach waiting to happen.
(When I was reading this stuff I thought about many of "Us" Aware developers who "do it all" and can get to any data we want. Sure, we don't, but plenty of us have had access to credit card info for years!)

At least back when "the signature" was stored in the database, it wasn't sitting there in your face in Windows Explorer. (And even then, using a SQL tool I could still copy the binary data from 1 record into another.) So, this may not be a big deal to anyone - and its not to me [right now], but at some point as we do our SAAS apps and get bigger and a potential big customer asks about your Encryption Keys for your data, you should probably have an answer.

But thats just my opinion.

ACDC

With regards to signatures, one can cut and paste from existing documents and achieve the same thing as extracting a signature image from a web server. Sometimes a simple X or a typed name inserted in a signature space will suffice

The image of a signature in whatever form is just a representation of a process carried out and when called to authenticate the signature the developer or owner of the system must be able to authenticate/prove that its legit by showing the process involved in placing a signature on a document. ie the steps used, recorded, OTP etc etc . Also a timestamped audit trail of the steps taken and image size etc etc

When placing a signature on a document there is a lot more than just inserting an image. There should be a clearly defined algorithm that makes the signature qualify as an "Electronic Signature", part of the algorithm should include how the user is set up, OTP and Password Security etc,

The best way to lock down a signature on a signed document is to Digitally Sign the document using a digital certificate issued by a CA authority either by a universal certificate issued for the purpose of the application or individual certificates for each user. This is very possible within the Aim setup using a server-based tool to insert the digital signature in the PDF at the time of AIM based signing process. So when the PDF document gets to its destination, the embedded certificate confirms its authenticity without any further question.

With regards to direct access to the database, Field encryption and exposure of keys, well that's another BIG story