Hi Chipp,
Thanks for your extensive reply. My apologies if my questions have not
been clear. I am grappling with both security questions relating to the
protection of our clients information as well as methods and strategies
best suited to deliver what will be our first "commercial-off-the-shelf"
software offering. We are aiming to structure the software in a way that
protects our investment (necessary in this world at this time) without
driving our clients nuts (our corporate mission) :-) .
There is a whole bunch of other stuff I didn't say that might put some
of my questions in perspective.
We have always built easy to maintain, practical solutions for our
clients. We charge an honest amount of money for our work, always exceed
our clients expectations and in ten years have never not delivered what
we have promised on budget and within the time frame allowed. That is
why I work where I do, because my boss is someone I respect and she
always gives us the time to achieve these things. Our software this time
is an architecture that distils the best of what we know and implements
it in an entirely new way. We have built "purpose specific" solutions
for clients for many years but this is our first commercial offering.
I am aware though that there is much that I don't know and that other
organisations have strengths in complimentary areas. That is why I am
investigating a whole range of current technologies (Revolution, U3,
iButtons, JVM, RFID, encryption, hardware VPN devices etc) to see what
will achieve what is needed with simplicity for us and our clients. I
expect in the end that one or two devices and a small selection of
software development environments will be able to be combined to achieve
security for our clients along with respectful protection of our investment.
So I appreciate your reply along with the many other inputs from this
community. It has all helped me to understand more of pieces of the puzzle.
Chipp Walters wrote:
Perhaps I'm not understanding you correctly, but as I read this, you
want to burden your users with a dongle, because you don't want to
learn a bit of
PHP? I think if you consider using a 3-tier approach, you would find
it is more secure, and more extensible as well. If you are ever
inclined to
provide a web browser interface for your product, having the
middle-tier already built in PHP can be a huge benefit.
I agree entirely that dongles are not a good idea. I have never required
one for any software I have written and am not likely to start now.
The hardware based key isn't so much used as a dongle, but to provide
another factor for user authentication to ensure their data is
protected. The information is to do with risk assessment, security plans
and the counter measures being put in place in worldwide supply chains
to deter or prevent terrorist activities.
I don't want to rely only on a user maintained password for
authentication because not only can the password be discovered by an
unauthorised person, but I am only able to get limited audit information
until a valid connection is established. So repeated attacks on the
database system that fail because of incorrect username/password
combinations do not get recorded in the main audit trail. They do get
entered in the database error log, but our own audit trail is system
wide and stores much more detailed information. Hence my desire to have
a database account that is used to allow more extensive validation
against multiple factors. It was the login details of that that single
account that I wanted to store in an encrypted format in the stand alone
environment and originally asked how secure would that be.
Furthermore, having the database login info on your server makes it
MUCH MORE DIFFICULT for someone to crack it, because they have to have
access to
your server. Putting the code in a dongle, or any client app makes it
available at all times to any hacker.
Part of the attraction of Rev is that it can establish connections to
many types of databases at the same time. Our product architecture
allows organisations to overlay information from many sources of
information (multiple databases, content management systems, web based,
GIS, public data sources, XLS data, CCTV, etc).
While certain data sources are definitely going to be accessed via
CGI's the core pairing of Rev and PostgreSQL seems a clean, mature and
stable one.
Finally, if I really HAD to embed a user/pass into a stack, I could
store it with using my own encoding scheme in an already password
protected stack as
part of a script which I would not use. Because all scripts are
encrypted, then I would have the benefit of double protection in a
place difficult to
find (some script).
It seems that our best bet for providing practical security for our
users are to:
A. Always use 128bit SSL connections over the network with private and
public key infrastructure
B. Provide mirrored hot swappable drives with encrypted data storage
(hardware encryption if economical)
C. Provide a second authentication method in addition to the password
(e.g., the iButton or a USB thumb print reader)
D. Store the users classified information on a server that is configured
to prevent access at the operating system level.
Of course, I imagine if someone takes the time to crack it, then they
could also crack a USB key without much more trouble. In fact,
somewhere in your
code, you'll need to define a global or function which 'checks the
serial' and if someone can hack your stack, then they can overide that
function as well.
The solution provides many easy to use tools but is an industry specific
implementation this time. So in a way, I don't expect people to rush out
and build an intermodal container port or supply chain infrastructure
just so they can mess about with our software. :-)
As many others have already said, I would spend my time adding some
decent copy protection, and then work on features which help sell my
product.
I hear you...
Kind regards
John T
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
