Internal security of Rev? Hardware for storing passphrases or keys?

[John Tregea]

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