Kyle Hamilton wrote:
Mr Diener:
This is, incidentally, why I call it "security theater" -- you're not
gaining anything from the actions that you're going through, except
"warm and fuzzies" of the people you're entertaining with it (in this
case, your boss).
You need to fix your server architecture, which is likely going to
involve a lot of work -- work that you're not doing while you're
searching for ways to hide authentication credentials which are
subject to attack.
Please suggest ways to do so. The server is no different from any other
server database. It accepts a username/password to prevent unauthorized
users from accessing its data. I am perfectly willing to listen to other
server techniques which involve security, or read about such techniques,
but I need to be pointed to such things. Just generally saying what you
say is not going to help me. I am open to specific suggestions if you
want to give them.
Yes, it might prevent the casual user from doing
it, but the casual user is also unlikely to know what to do with the
credentials that he sees anyway. The advanced user will be able to
find the credentials, and is more likely going to know how to write
SQL to abuse the credentials than the casual user.
The practical upshot of this is that you're protecting your
infrastructure from people who wouldn't know how to attack it. This
is more likely than not going to lead to your company feeling warm and
fuzzy, that the system is safe from attack -- which is (ironically)
going to lead to more security vulnerabilities that your company is
not going to be on the lookout for.
This is not the psychology of the company for which I am working.
This could lead to catastrophic
data loss and downtime while you try to figure out how the data in the
tables managed to disappear out from under you -- and if the data is
of sufficiently high value, it will more likely lead to the data being
sucked down by attackers using the credentials. Since you have
admitted that you don't have visibility with MySQL directly as to the
queries it's receiving and processing, your company is a sitting duck
against these types of attacks.
Why do you say "Since you admitted..." etc. ? The server database is
accessible and manipulatable in whatever ways we want to manipulate it.
If your company hires a security consultant, s/he will state the same thing.
Thanks for your help but right now I am the programmer and "security
consultant", and therefore I must come up with security answers.
Nonetheless I will mention to my employer that he might want to hire
another person as a "security consultant" to deal with server side
security issues.
-Kyle H
On Thu, Dec 25, 2008 at 6:49 PM, Victor Duchovni
<victor.ducho...@morganstanley.com> wrote:
On Wed, Dec 24, 2008 at 10:06:59PM -0500, Edward Diener wrote:
It sounds like you are trying to implement DRM with an application that is
running on untrusted hardware controlled by a potentially hostile user.
You want to ensure that only your code has access to your server, and not
modified or user developed code. This is a "whitebox" DRM problem.
Are you saying that any application sold on the market which needs to
ensure secure access to data on a server outside the client machine on
which the application runs is a "whitebox" DRM problem ?
No, I am saying that applications where you don't trust the user are
DRM problems. If you trust the user (not abuse, modify or replace)
your application, then you don't need DRM, just authenticate trusted
users by giving each user appropriate credentials (possibly a per-user
private key, delivered separately from the application, via a secure
enrollment process).
--
Viktor.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
