Ger Hobbelt wrote:
On Fri, Dec 26, 2008 at 7:28 PM, Edward Diener <el...@tropicsoft.com> wrote:
I appreciate all the information you presented which I have snipped out
in giving my response below.
Money may be less of an issue than ease of use. This is a commercial
application which however needs good security to protect the database data.
There is no way the application is going to be sold to the public with some
type of hardware security mechanism. I thought such mechanisms went out with
the dinosaurs.
'good' is a 'taste' word; not a hard, measurable quantity. For a given
level of 'good', one can tailor his processes and security around and
inside those processes. All it takes is answering questions such as
"can we tolerate data corruption / pollution? System failure? Data
loss? How 'public' is our data: who do we tolerate looking at our
data? What can possibly go wrong, by accident or intention? And do we
wish to survive such scenarios, which ones, and how uch effort are we
willing to expend, before, during and after?" And, funnily, during
that Q&A process you will also discover what your (company's) actual
desired definition of 'good' really is.
And regarding dinosaurs: boy, are you in for a surprise! T.Rex is
ruling. It's just that those serial/parallel port dongles have moved
up in the world along with anything else computing; now we've got USB
and, dear sir, we use it! ;-) Nowadays it looks to me like it's less
'per application' as more 'per use' security; single-sign-on being a
big item, for example. But given ever-cheaper smartcards and tokens,
contact and contact-less, the number of corporations using this tech
is ever increasing.
Anyway...
Minimum book to read would be Schneier (applied Crypto); probably
O'Reilly OpenSSL as well; after reading, reread the other responses in
this thread for additional insight (I've been skimming the surface
only and it's rather more hopping than surfing) and, yes, this will
take some time and effort for you to do.
I know of Schneier, although I have not read his books. I will also get
the O'Reilly OpenSSL book, as the "official" OpenSSL documentation is
not understandable by me.
For now, in final closing, I'd say:
- the only thing worth protecting is the private key of the client as
it is the only 'secret' in the collection you distribute.
The MySQL documentation about the certificates needed for SSL is really
limiting and no question I have asked about what the certificates
actually entail was ever answered on MySQL NGs/forums.
My assumptions from what I could glean from the certificates distributed
is that the CA-cert.pem is the same for client and server, while the
server-cert.pem is a public key corresponding to the private
client-key.pem, and the server-key is a private key corresponding to the
public client-cert. When I say "corresponding I mean that they form a
public-private key pair.
If this is true then my client has a private key in its client-key.pem
certificate.
- take the suggestion from elsewhere in this thread, since you already
indicate 'tokens' are out, for user friendly reasons (I think you
should check that reasoning again, but that's just me): distribute or
otherwise 'derive' the passphrase required to decode that private key
in software.
I have to learn more about what these certificates contain. In MySQL I
am doing nothing more than pointing to where these certificates exist in
the application in order to connect. I do not attempt to manipulate the
certificates themselves in any way, before passing them to MySQL, which
is what you seem to be suggesting. If I need to know about "passphrase"
and how to do what I am now doing to "derive the passphrase" on the fly,
I have to go deeper into certificates, SSL, and OpenSSL. I am perfectly
willing to do so but I must educate myself first.
- accept that anyone with any access to that client machine is going
to have client-level access to your server; from anywhere on the
globe. Take measures to protect your server internally (damage
prevention) by thoroughly checking user access limits
The user in the case of MySQL is just my application, ie, whatever
username/password is used to access the database whic I am hiding pretty
well and is not in plaintext.
It may of course be very possible to generate a hidden separate
username/password for each end-user who registers the application, while
at the same time adding that username/password to the database server,
but at the present time that is not being done.
It may of course be very possible to generate a separate set of client
certificates for each user of the application, as someone has suggested
but again I would have to study this because the server only has a
single set of server certificates which communicate with all clients.
Other than the username/password and the client/server certificates
which ensure the SSL encryption/decryption of data, from the database
server's perspective there is no other way it can tell who is attempting
to access it unless I build a 3-tier system as at least one other person
has suggested.
- sit down, onsider all the possible ways your server / processes can
be damaged, include even the 'improbable' and the 'impossible' ways
and decide, at strategic level, what you want done for each of those
scenarios. "Nothing" as an answer is good too; just so everyone
realizes what they're deciding right there. Then implement it down the
line.
's all.
Of course you can send queries if you can get through. The certificates
issue I brought up in my OP was simply to determine if others thought that
hiding the certificates in some way (encrypting them, putting them in
resources, loading the resources and decrypting them on-the-fly ) was a
worthwhile security method that actually accomplished anything. It was not
an attempt to claim that this encompassed an entire security solution for
everything that involved the client-server application.
That's the danger using the 'security' word in a security conscious
list: it has a certain meaning and you re-use the word with a slightly
different meaning; not intentionally, but it happens. Garbled jargon.
Let me rephrase here:
resources, loading the resources and decrypting them on-the-fly ) was a
worthwhile security method that actually accomplished anything. It was not
^^^ worthwhile *obfuscation* method ...
hiding the certificates in some way (encrypting them, putting them in
resources, loading the resources and decrypting them on-the-fly ) was a
worthwhile security method that actually accomplished anything. It was not
an attempt to claim that this encompassed an entire security solution for
everything that involved the client-server application.
Hm... and my guess? Good enough when the expenses don't allow "this
software suite is delivered with a personalized hardware token". As
you will have realized by now, this "yes, it does" has quite a few
implications. As would a "no, it does not".
And all that fuss, just because you've woken up and inquired about
security / protection technology, instead of ignoring the subject and
waiting for a nasty surprise down the road. Dang! ;-))
My employer wanted to use SSL from the beginning in order to encrypt
data being sent between the client and server. So that
"security/protection" had to be considered. You, and others, have taken
the time to mention other security issues and I will take those issues
up with my employer.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
