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

[John Tregea]

Hi Chipp,

I have been keeping your browser stack in mind. Once we get up to 
display of web resources (even GIS info) , you will definitely be 
hearing from me. I looked at the demo stack and thought it was 
brilliant. I wish I could embed the database in the Rev product too, but 
unfortunately there is a need for server based DB access. I have just 
started looking at the options for CMS, so I may contact you offlist 
about that. I have previously used an FTP plugin with FileMaker Pro to 
make rudimentary CMS, but will have to do way better than that this time.


Thanks and regards

John T

Chipp Walters wrote:

John,

Thank-you for your reply. I think I have a better grasp on what you 
are now

trying to do, and it now makes much better sense.

If you need any help with db specific stuff, please don't hesitate to 
ask.

Our company, Altuit, makes one of only a couple third party database
connectors for Rev. Ours is an embedded version of SQLite called
'altSQLite.' We also make an embedded browser for both Mac and PC. If 
you're

interested, you can check us out at www.altuit.com.

Also, you can find at our website a number of free Rev resources and a 
case

study for a multi-tiered Content Management System we've built around Rev
and SQL Server -->
http://www.altuit.com/webs/altuit2/RunRevCaseStudies/Hemingway.htm

best of luck!

-Chipp
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your 
subscription preferences:

http://lists.runrev.com/mailman/listinfo/use-revolution



___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Internal security of Rev?

[Mark Talluto]

On Jul 18, 2006, at 2:15 PM   Jul 18, 2006, Chipp Walters wrote:


Nope,

Actually, I did get to use Byte by Byte's 3D product on the Amiga. The
company was based here in Austin. Funny, tomorrow I'm meeting with the
old CEO of Byte by Byte to talk about using Rev on a new Enterprise
CRM app he's starting up. Small world indeed!

Back in the old days, just about every decent 3D package used
dongles--- many still do. Though most of the companies I know of have
very customer friendly ways of dealing with lost dongles. In fact, Jim
Plant, CEO of Newtek told me he wasn't too concerned as he's mostly
interested in helping his customers. If more than a few were lost by
the same company over a short period of time, he might become worried.
The simple matter in the 3D world is, if you steal the product (thus
not supporting it), you may find the company no longer around later
on!



This is all very true.  I remember Byte by Byte's product.  There  
were a few cool 3D apps on the Amiga including Newtek's Video Toaster  
and accompanying software.  I am currently using Carrara and Hexagon  
which do not use dongles.



Mark Talluto
--
CANELA Software
http://www.canelasoftware.com

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Internal security of Rev?

[Chipp Walters]

Nope,

Actually, I did get to use Byte by Byte's 3D product on the Amiga. The
company was based here in Austin. Funny, tomorrow I'm meeting with the
old CEO of Byte by Byte to talk about using Rev on a new Enterprise
CRM app he's starting up. Small world indeed!

Back in the old days, just about every decent 3D package used
dongles--- many still do. Though most of the companies I know of have
very customer friendly ways of dealing with lost dongles. In fact, Jim
Plant, CEO of Newtek told me he wasn't too concerned as he's mostly
interested in helping his customers. If more than a few were lost by
the same company over a short period of time, he might become worried.
The simple matter in the 3D world is, if you steal the product (thus
not supporting it), you may find the company no longer around later
on!

best,
Chipp
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

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

[Dar Scott]

On Jul 17, 2006, at 10:00 PM, John Tregea wrote:


Oh yes, I would then need Rev to read data from a USB port as well...


If it looks like a drive or a serial port, then Rev can do it.

(Seems like I have seen drives with a print reader someplace.)

Dar Scott

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Internal security of Rev?

[Mark Talluto]

On Jul 17, 2006, at 11:23 PM   Jul 17, 2006, Chipp Walters wrote:

In a previous life as a CEO of a company which used such dongles to  
do 3d
renderings, on occasion, even our best artists lost them. Now, it  
isn't my
job to 'teach them responsibility', but it is my job to make sure  
things get
done, and if a company wouldn't replace a dongle for a minimal fee,  
they no

longer wanted us as a customer.


You didn't happen to work for Real3D for the Amiga did you?  I used  
to use their software on my A500 and A1200 to generate 3D images and  
remember using a dongle for that software.




Mark Talluto
--
CANELA Software
http://www.canelasoftware.com

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

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

[Viktoras Didziulis]

 Hi, John
 
hardware approach for storing any authentication info would be a bad choice.
Imagine a user trying to connect 10 or more dongles, iButtons or whatever
external hardware promoted by different vendors to her or his machine just
to make the software purchased from different vendors work. What dongle
belongs to what soft ? Where to keep them all? Oh, I just lost my
dongles/iButtons box somewhere !... Where to connect all that stuff if there
are no more free ports available ? I guess all they consume power too... No
way!
 
I would suggest to give up any hardware idea for user authentication and
rely on users database on a remote server instead !
 
Best wishes
Viktoras
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

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

[Chipp Walters]

John,

Thank-you for your reply. I think I have a better grasp on what you are now
trying to do, and it now makes much better sense.

If you need any help with db specific stuff, please don't hesitate to ask.
Our company, Altuit, makes one of only a couple third party database
connectors for Rev. Ours is an embedded version of SQLite called
'altSQLite.' We also make an embedded browser for both Mac and PC. If you're
interested, you can check us out at www.altuit.com.

Also, you can find at our website a number of free Rev resources and a case
study for a multi-tiered Content Management System we've built around Rev
and SQL Server -->
http://www.altuit.com/webs/altuit2/RunRevCaseStudies/Hemingway.htm

best of luck!

-Chipp
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: 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 

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

[Chipp Walters]

John,

Adding a dongle to your product is something which should be run by
marketing as well. There are many companies who don't like having dongles on
software and it can represent a significant barrier to sales.

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.

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.

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).

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.

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.

best,
Chipp
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Internal security of Rev?

[Chipp Walters]

Kay,

That's the most insane argument I've ever heard: "teach them
responsibility!" I'm sure you're just trolling for reaction. I guess you've
found one.

So let me get this straight-- Your brother is BOTH in the ballistic sales
business AND plays Dr. Phil, teaching all his customers how to be
responsible. There are so many things that can go wrong with a dongle that
have nothing to do with 'responsibility.' It can get stolen, it can get
zapped by a lightning strike, it can be attacked by a virus (happened to me
once), and it can be lost by even the most responsible employees.

In a previous life as a CEO of a company which used such dongles to do 3d
renderings, on occasion, even our best artists lost them. Now, it isn't my
job to 'teach them responsibility', but it is my job to make sure things get
done, and if a company wouldn't replace a dongle for a minimal fee, they no
longer wanted us as a customer.

Electric Image was such a company, and treated their customers with similar
disdain. It didn't take long for the word to get around and they lost tons
of customers. A once cutting edge, great company, they ended up losing
significant market share to companies with inferior technologies-- but a
more customer-friendly approach.

I don't suppose you'd share with us the company who's policy it is to treat
their customers this way? I'm interested in knowing.

-Chipp

On 7/17/06, Kay C Lan <[EMAIL PROTECTED]> wrote:


Hmmm, sounds like a similar attitude my children have re misplaced school
socks, runners, text books and extends to mobile phones.

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

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

[John Tregea]

In the context of protecting our clients data (and therefore our 
reputation in the maritime/supply chain security field), that was my 
concern.


Whether, once a rev stack was built into a stand-alone application, was 
it possible to read the rev scripts with another copy of Rev or some 
other utility (like I used to do with ResEdit under Mac OS < X).


If a hacker could read the scripts, they could see how the de-cryption 
of an encrypted value was accomplished in the front end and by 
re-producing that  process, de-crypt and use the key in another client 
application (like pgadmin) to create a non-authorised session to the 
back-end postgreSQL database.


Following  advice from list members I am not going to rely on 
encrypted storage of any type of key in the front end.


I am looking at hardware devices capable of storing a unique key.

I spotted iButtons recently (java virtual machines in a chip) and note 
that one type of iButton stores a unique (factory set) 128bit string. I 
could pre-program Rev to read that key from an iButton provided to the 
user (via a serial port iButton reader) and use that for the login to 
the database.


So while I realise the number could be read by someone with serial port 
monitoring software, they could not reproduce another iButton with the 
same key (As I believe there is only one iButton ever made with one key)


Although a user could try to authenticate more than one workstation with 
one iButton the key would be stored in the session info and only become 
re-usable once the first session was ended.


The key would also only work with that client's installation of our 
product because the database accounts would be pre-configured to expect 
the key from the matching iButton/s. So a 10 user system would come with 
10 iButtons and readers from us. (plus 10 U3 smart drives with the user 
software on board). The only problem I see now is... Will the user's PC 
have the available serial port for the iButton reader, or can Rev be 
made to read data from a USB reader (that is also available)?


Actually my dream device would be a USB device with a 256MB U3 drive, a 
GPS chip, a thumb print reader and an iButton reader all built-in. Then 
I could do four factor authentication with one piece of hardware. Dream 
on... :-)


Oh yes, I would then need Rev to read data from a USB port as well...

Regards

John T

Kay C Lan wrote:

Closer to the topic at hand. Somewhere earlier I noted someone mentioned
storing 'valuable' data in custom props and then emptying the props on
closeStack. With my insecure work with mySQL I follow a similar 
procedure,

only after all transactions are complete do I clear the fields and custom
props. If I start the stack and there is data in a field or custom 
prop then
it indicates that something 'failed' during the process and so 
hopefully I
can retrieve the data and complete the transaction without too much 
hassle.
Conversely, if you are working with secure data I imagine a simple 
Save and
'Force Quit' followed by opening the stack in a text editor will 
reveal all

the data in custom props - maybe not what you were hoping for.

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Internal security of Rev?

[Kay C Lan]

On 7/14/06, Stephen Barncard <[EMAIL PROTECTED]> wrote:


That's BS. When a company can simply look up a registration for a
lost dongle, replacement should be a feature (with suitable hassle),
not punishment.



Hmmm, sounds like a similar attitude my children have re misplaced school
socks, runners, text books and extends to mobile phones. 'You've got lots of
money you can just buy new ones." And I could, but it wouldn't teach
responsibility. Whether we're talking diamond rings, cheap plastic cards
that allow access to 'highly restricted areas' or dongles for software
valued at tens of thousand of dollars upwards I believe there is a need to
instill an understanding of the 'value' of an object and have procedures to
prevent asset loss.

iLok does this for Pro-Tools plugins; for $30/year most plugs can be

insured and loaded onto a spare dongle.



Yes, I believe insurance is an avenue my brother suggests, although even
insurance companies aren't too pleased to fork out $80,000 unless certain
requirements have been met.

I recently had a conversation with a guy who does electronic security,
specializing in Casinos. He indicated that more than half of a Casio's
security budget is spent on protecting the companies assets from employees!
Some have suggested that the attitude of having to pay in full for a
replacement dongle would drive people to 'crack' the code. I would suggest
that if the company charged 'half' for the replacement dongle, it would
provide a 'cheap' way to pick up an extra copy without all the hassle of
cracking the code.

Closer to the topic at hand. Somewhere earlier I noted someone mentioned
storing 'valuable' data in custom props and then emptying the props on
closeStack. With my insecure work with mySQL I follow a similar procedure,
only after all transactions are complete do I clear the fields and custom
props. If I start the stack and there is data in a field or custom prop then
it indicates that something 'failed' during the process and so hopefully I
can retrieve the data and complete the transaction without too much hassle.
Conversely, if you are working with secure data I imagine a simple Save and
'Force Quit' followed by opening the stack in a text editor will reveal all
the data in custom props - maybe not what you were hoping for.

HTH
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Internal security of Rev?

[Mark Talluto]

On Jul 12, 2006, at 8:57 PM   Jul 12, 2006, Richard Gaskin wrote:


Mark Talluto wrote:

If you market your products through a distributor, copy protection  
is  invaluable if they have rights to duplicate/install the software.


Aside from hardware dongles, what devices/methods can prevent copying?


The trick is not to focus on copying, but to focus on disarming  
features.  Lets keep in mind the old saying that nothing is 100%  
safe.  Lets also keep in mind that spending a lot of time on  
protection is a waste of time.  Now that that is out of the way, we  
must also remember that no protection is also bad.  My simple key  
system has kept my distributors honest on more than one occasion.   
Errors can be made on how many products were sold once in a while and  
having the software rely on a key really makes handling issues like  
that quite easy.


I rely on generating a unique key based on the mac address.  Only my  
company can generate the keys.  Our distributors install the software  
on minis ahead of time.  They get their keys from us directly and the  
units are ready for sale.  I do not need any info on the customer and  
do not need to worry about returned units being sold to another  
customer down the road.  This model does not work for everyone, but  
it could be modified to work with general apps if the key system ran  
over the internet and was embedded in the software.


The effort took about 4 days to perfect and has been serving me for  
over 3 years.



Mark Talluto
--
CANELA Software
http://www.canelasoftware.com

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Internal security of Rev?

[Dar Scott]

On Jul 14, 2006, at 6:08 AM, Wouter wrote:

As for giving a reason to someone to crack your software, this is  
an excellent one.


Right, and with moral indignation one might not have the extra  
(emotional) moral cost of violating an agreement or stealing or  
sinning or dishonoring the state or whatever.  (Of course, some of us  
believe actual guilt is independent of guilty feelings.)


That cost is a part of the cost of cracking and part of the economics  
of cracking.  To minimize the chance of cracking, keep the cost high  
and the benefit low.  And keep below the radar.


Dar

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Internal security of Rev?

[Stephen Barncard]

That's BS. When a company can simply look up a registration for a 
lost dongle, replacement should be a feature (with suitable hassle), 
not punishment.


iLok does this for Pro-Tools plugins; for $30/year most plugs can be 
insured and loaded onto a spare dongle.





As my brother would say to some poor sap who would be trying to get a
new dongle without paying for a whole new license fee would say: "Go
into Harry Winston's and tell them your wife lost her $80,000 diamond
ring and that you'd like a free replacement"



--
stephen barncard
s a n  f r a n c i s c o
- - -  - - - - - - - - -
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Internal security of Rev?

[Wouter]

On 14 Jul 2006, at 09:25, Kay C Lan wrote:

- snip -


In the last financial year it was noted that the revenue figures were
up, better than expected. After a little analysis of the number the
reason revealed itself. Although 'users' had occasionally lost their
parallel dongles,  the USB dongles proved at lot easier to loose!

As my brother would say to some poor sap who would be trying to get a
new dongle without paying for a whole new license fee would say: "Go
into Harry Winston's and tell them your wife lost her $80,000 diamond
ring and that you'd like a free replacement"


As for giving a reason to someone to crack your software, this is an  
excellent one.

It resembles (or rather is) software hijacking.
I'm sure there are ways to identify people who lost their dongle
(for example: traces of banking in the act of the legal acquisition  
of the software),
instead of forcing them to pay again for the software and a new  
dongle combo.
And to complete the above comparison, I also would not buy a $80,000  
diamond if a dongle was needed for wearing it in the first place.


Greetings,
Wouter
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Internal security of Rev?

[Chipp Walters]

On 7/14/06, Kay C Lan <[EMAIL PROTECTED]> wrote:


As my brother would say to some poor sap who would be trying to get a
new dongle without paying for a whole new license fee would say: "Go
into Harry Winston's and tell them your wife lost her $80,000 diamond
ring and that you'd like a free replacement"



Yeah, and I pretty much HATE that line of thinking. Talk about
uncustomer friendly. Jeez. How much does it cost Harry Winston to
replace that diamond? Quite a bit. But to lose a $15 dongle and then
have to pay for the software all over again. I'd NEVER purchase a
program from a company who treated their customers that way!

Sheesh.

-Chipp
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Internal security of Rev?

[John Tregea]

I thought of combining the U3 drive with a thumb print reader (also USB) 
to make for three factor authentication.


1. password
2. thumb print
3. presence of U3 drive (serialised)

I am hoping to find a USB thumb drive manufacturer that makes metal 
encased drives and supports U3. (Dreamer)


Cheers

John

Kay C Lan wrote:

On Jul 13, 2006, at 6:50 PM, John Tregea wrote:



> The users will have one U3 enabled USB thumb drive per licensed
> client and the user application will be programmed to only run on
> the serial numbered, unique thumb drive.


On 7/14/06, Dar Scott <[EMAIL PROTECTED]> replied:

Cool!  I suppose users should keep up with those as they would keep
close tabs on a badge.  But the drive might get stolen and the user
might be a bad guy.


And a possible surprise.

My brother works for a firm that sell/contract/train software for
ballistic prices - $100,000+ for the full package. The software is
licensed with a dongle. Since Noah these have been parallel port
dongles, but with some PCs coming out these days without parallel
ports they've had some pesky users demand USB dongles. After a bit of
fussing the company eventually bit the bullet and produced USB
dongles.

In the last financial year it was noted that the revenue figures were
up, better than expected. After a little analysis of the number the
reason revealed itself. Although 'users' had occasionally lost their
parallel dongles,  the USB dongles proved at lot easier to loose!

As my brother would say to some poor sap who would be trying to get a
new dongle without paying for a whole new license fee would say: "Go
into Harry Winston's and tell them your wife lost her $80,000 diamond
ring and that you'd like a free replacement"

I believe the R&D dept are now feverishly working on making the
smallest USB Dongle known to man;-)
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your 
subscription preferences:

http://lists.runrev.com/mailman/listinfo/use-revolution



___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Internal security of Rev?

[Kay C Lan]

On Jul 13, 2006, at 6:50 PM, John Tregea wrote:



> The users will have one U3 enabled USB thumb drive per licensed
> client and the user application will be programmed to only run on
> the serial numbered, unique thumb drive.


On 7/14/06, Dar Scott <[EMAIL PROTECTED]> replied:

Cool!  I suppose users should keep up with those as they would keep
close tabs on a badge.  But the drive might get stolen and the user
might be a bad guy.


And a possible surprise.

My brother works for a firm that sell/contract/train software for
ballistic prices - $100,000+ for the full package. The software is
licensed with a dongle. Since Noah these have been parallel port
dongles, but with some PCs coming out these days without parallel
ports they've had some pesky users demand USB dongles. After a bit of
fussing the company eventually bit the bullet and produced USB
dongles.

In the last financial year it was noted that the revenue figures were
up, better than expected. After a little analysis of the number the
reason revealed itself. Although 'users' had occasionally lost their
parallel dongles,  the USB dongles proved at lot easier to loose!

As my brother would say to some poor sap who would be trying to get a
new dongle without paying for a whole new license fee would say: "Go
into Harry Winston's and tell them your wife lost her $80,000 diamond
ring and that you'd like a free replacement"

I believe the R&D dept are now feverishly working on making the
smallest USB Dongle known to man;-)
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Internal security of Rev?

[John Tregea]

Thanks Dar,

I appreciate that.

But you and everyone else had told me what would work in the situation I 
described.


I just needed to stop and listen...

stopping...


listening...


Appreciating the help... :-)


Cheers

John T

Dar Scott wrote:


On Jul 13, 2006, at 9:35 PM, John Tregea wrote:

That is a valuable synopsis. I will go away now and get on with it... 
:-)


If you need help with any of those pieces, we are around.  Setting up 
SSL, encryption, message digest (using MD5)...


(I did not intend to be abrasive about hiding the key in the app.  I 
_want_ to do that, too.  But I'm OK with hiding half.  And even hiding 
a little string to add to MD5 to get a message digest for the secret 
file.  But the key?  You might not be able to claim to meet standards.)


Dar


___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your 
subscription preferences:

http://lists.runrev.com/mailman/listinfo/use-revolution



___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Internal security of Rev?

[Dar Scott]

On Jul 13, 2006, at 9:35 PM, John Tregea wrote:

That is a valuable synopsis. I will go away now and get on with  
it... :-)


If you need help with any of those pieces, we are around.  Setting up  
SSL, encryption, message digest (using MD5)...


(I did not intend to be abrasive about hiding the key in the app.  I  
_want_ to do that, too.  But I'm OK with hiding half.  And even  
hiding a little string to add to MD5 to get a message digest for the  
secret file.  But the key?  You might not be able to claim to meet  
standards.)


Dar


___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Internal security of Rev?

[John Tregea]

Dar,

That is a valuable synopsis. I will go away now and get on with it... :-)

Thanks again. (to all)



Dar Scott wrote:


On Jul 13, 2006, at 6:50 PM, John Tregea wrote:

Thanks for your time again. I believe that the database server is 
secure. It will be Solaris 10 running a dedicated copy of postgreSQL. 
Solaris will be configured with a zone that enables login only on the 
postgres port . The server will be supplied by us with pre-configured 
software for the client.


I am not familiar with postgres, so keep that in mind.

The users will have one U3 enabled USB thumb drive per licensed 
client and the user application will be programmed to only run on the 
serial numbered, unique thumb drive.


Cool!  I suppose users should keep up with those as they would keep 
close tabs on a badge.  But the drive might get stolen and the user 
might be a bad guy.


A password is like a security code that would go with a badge.  (Maybe 
a future version could even have a duress password.)


This is why I was asking about the security of the stand-alone rev 
application. I intended to store one secret key in the application in 
a custom property in base64encoded form. This key would unlock the 
first step of authentication on the database login with everything 
after that coming from within the database.


I wouldn't do that.

It is true that the data can be encrypted on the storage medium 
without me doing that in the client, but I thought that made the 
transmission more vulnerable to penetration (even with SSL).


I'd put that effort into making SSL solid.

How about this:

(Make the network as secure as you want as an add-on and independent 
feature.  You can use ipSec or encryption hardware among certain 
classes of equipment.)


Set up the db to use SSL only.  Set up the db to take per-user 
passwords.  Keep a file (or property) with secret things in it (plus 
an MD5 digest).  When the user runs the app, the secret things are 
opened up and checked.  It is decrypted with the user password.  In 
that is the host and port, the db password or cert (for this user), 
the data encryption key (if you insist), and the root cert for 
confirming the db connection.  The cert is written to a file.  The 
connection is made and the password is used to connect to the db.  You 
know connection was made with the real db.  Erase the cert file.  
Continue the session.  (The public cert doesn't have to be secret.)


The db probably has lots of data consistency and data constraint 
features that you lose with encryption.


(IIRC, in Rev the host name used in making the SSL link must be the 
same as the one in the db cert.)


Now if you use the Rev db interface or some external to connect to the 
db, then the above suggestion would have to be adjusted (or thrown 
out) as needed.  Others can advise here better than I.


Dar

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your 
subscription preferences:

http://lists.runrev.com/mailman/listinfo/use-revolution



___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Internal security of Rev?

[Dar Scott]

On Jul 13, 2006, at 6:50 PM, John Tregea wrote:

Thanks for your time again. I believe that the database server is  
secure. It will be Solaris 10 running a dedicated copy of  
postgreSQL. Solaris will be configured with a zone that enables  
login only on the postgres port . The server will be supplied by us  
with pre-configured software for the client.


I am not familiar with postgres, so keep that in mind.

The users will have one U3 enabled USB thumb drive per licensed  
client and the user application will be programmed to only run on  
the serial numbered, unique thumb drive.


Cool!  I suppose users should keep up with those as they would keep  
close tabs on a badge.  But the drive might get stolen and the user  
might be a bad guy.


A password is like a security code that would go with a badge.   
(Maybe a future version could even have a duress password.)


This is why I was asking about the security of the stand-alone rev  
application. I intended to store one secret key in the application  
in a custom property in base64encoded form. This key would unlock  
the first step of authentication on the database login with  
everything after that coming from within the database.


I wouldn't do that.

It is true that the data can be encrypted on the storage medium  
without me doing that in the client, but I thought that made the  
transmission more vulnerable to penetration (even with SSL).


I'd put that effort into making SSL solid.

How about this:

(Make the network as secure as you want as an add-on and independent  
feature.  You can use ipSec or encryption hardware among certain  
classes of equipment.)


Set up the db to use SSL only.  Set up the db to take per-user  
passwords.  Keep a file (or property) with secret things in it (plus  
an MD5 digest).  When the user runs the app, the secret things are  
opened up and checked.  It is decrypted with the user password.  In  
that is the host and port, the db password or cert (for this user),  
the data encryption key (if you insist), and the root cert for  
confirming the db connection.  The cert is written to a file.  The  
connection is made and the password is used to connect to the db.   
You know connection was made with the real db.  Erase the cert file.   
Continue the session.  (The public cert doesn't have to be secret.)


The db probably has lots of data consistency and data constraint  
features that you lose with encryption.


(IIRC, in Rev the host name used in making the SSL link must be the  
same as the one in the db cert.)


Now if you use the Rev db interface or some external to connect to  
the db, then the above suggestion would have to be adjusted (or  
thrown out) as needed.  Others can advise here better than I.


Dar

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Internal security of Rev?

[John Tregea]

Thanks everyone for the pointers, answers and time...

I appreciate it.

Regards

John T



___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Internal security of Rev?

[John Tregea]

Hi again Dar,

Thanks for your time again. I believe that the database server is 
secure. It will be Solaris 10 running a dedicated copy of postgreSQL. 
Solaris will be configured with a zone that enables login only on the 
postgres port . The server will be supplied by us with pre-configured 
software for the client.


The users will have one U3 enabled USB thumb drive per licensed client 
and the user application will be programmed to only run on the serial 
numbered, unique thumb drive.


In many cases the server will only host a private network of 6 to 8 
clients connecting to a dedicated gigabit ethernet switch. The 
client/server connections will use 128 bit SSL connections. If the 
system is integrated with an organisations existing network, a hardware 
encryption router will be placed at each user terminal and at the server 
connection to the network.


I could do as has been suggested in this thread and use a CGI to talk to 
the database, but I hesitate to commit to another technology in the mix. 
Partly cause I would have to learn it. :-)  

Maybe Python or SOAP for the initial login and then hand the secure 
session back to Revolution?


> If the data needs to be encrypted by the clients and decrypted by
   the clients, then you might as well use a secret key.  You can >
   have the key kept at the client or kept at a key server.  In the
   first case, it needs to be encrypted with a user password
> (optionally mixed with your obfuscated application key) or
   derived from it (and optionally mixed). 

This is why I was asking about the security of the stand-alone rev 
application. I intended to store one secret key in the application in a 
custom property in base64encoded form. This key would unlock the first 
step of authentication on the database login with everything after that 
coming from within the database.


It is true that the data can be encrypted on the storage medium without 
me doing that in the client, but I thought that made the transmission 
more vulnerable to penetration (even with SSL).


Regards

John T


Dar Scott wrote:


On Jul 12, 2006, at 6:20 PM, John Tregea wrote:

Thanks for your extensive reply. The point you raised about info 
leaks through memory was one of my two concerns, the other was what 
could be seen by 'peaking' into the built application.


In the latter case, you are using a hardwired password.  From my 
understanding of your recent mail, you don't want to do that.  Well, 
not completely.


I guess I can overwrite the memory variables I use by setting them to 
empty at the end of each handler.


First put a string of the right length into char 1 to -1 of the key.  
That will write over the key in RAM.  Now you might have inadvertently 
made copies by then.


I planned to do that when the user logs out anyway. I also was going 
to store the variables in custom properties (in encrypted form) 
during the session and set them to empty at the end of a session.


Why not a global?  If the file gets saved, you don't want them in 
properties.


Really there is just two things that have to be stored in the Rev 
side of the solution. That is the login user name and password for 
the postgreSQL database. Once the connection is made through that 
default account, there is a two, three or four factor validation 
process from within POstgreSQL.


If the user login is not used for data encryption, you do not need to 
keep any copies anywhere.  Use a digest such as MD5.  Even then you 
might need to have an ephemeral copy after it is keyed in, but there 
are ways to avoid that.


You can prevent entering of the db password until the user login is 
complete.


Earlier you had mentioned encrypting of data in the db at the client 
end.  If the user does not supply the password for that, then it is 
essentially and extension of your program and is as vulnerable as that.


I realised that I may be able to use the location of certain objects 
within the front end to build the key. The objects never move in 
relation to each other and the resulting string of numbers would be a 
perfectly hidden string.


maybe something like

repeat with x = 1 to the number of btnsput char 1 of the short 
name of btn x & item 1 of the loc of btn x after tTheKey

   if length(tTheKey) > 16 then exit repeat
end repeat
put char 1 to 16 of tTheKey into tTheKey

-- the key would end up something like b234t256h678f67u (a 128 bit key)

?

I would have to be careful that the stack window never has a new 
button inserted at a low layer in subsequent versions, or the clients 
would lose there data decrypt capability :-)


You can put a little time into obfuscation, but I wouldn't put a lot 
into it.  If this is used to hide the data encryption key, then your 
encryption is no better than a light scrambling.  If this level is 
fine, then this approach is fine.


The above method has the cool feature of being a sort of application 
digest, though.



Any thoughts?


Consider these questions

Re: Internal security of Rev?

[Dar Scott]

Yes.  I agree with moving passwords off the client computer.

However, either the client computer, the app or the user will need to  
validate the server, or you are liable to MIM attacks.  If the  
environment is such that man-in-the-middle attacks cannot occur, then  
this does not apply.  For SSL, a private cert can be created and then  
the public cert for that can be used at the client end.  That needs  
to be moved to the client in a way that does not allow substitution.


The authentication of the user is still done by password.

You might also want some way to confirm that the user is contacting  
the db from a client computer that he is allowed to do that on.


(BTW, it might turn out that your db will do almost all of this for  
you.  Maybe you can just pull out the security manual for the db and  
turn the crank.  If the db can handle passwords, privileges, SSL, and  
encryption maybe you can exploit all that.)


Dar Scott

On Jul 12, 2006, at 7:37 PM, Brian Yennie wrote:

I would second that. If you're going to go to all of the trouble of  
encrypting your database, using SSL, taking thumbprints, etc, etc -  
then just about any method of storing critical passwords on the  
client side is going to immediately be the weak link. I would  
strongly consider just not storing the password on the client  
computer at all and making them enter it each time.


Chipp's method also would allow you to block all connections to the  
database that are not local. Make 'em go through an intermediary  
that only accepts certain commands/requests so that even with a  
username and password, they couldn't connect directly to the  
database server. Even for low security web apps, that is typically  
the case.



John,

Here's how I solve a similar problem.

I ask the user to login with a name and a password. They enter it and
it goes (securely) to a web page on a server, There the connection is
made to the database passing along the username and password for
verification. This way there is never a need to store anything but  
the

address of the webpage in the client app. No users or passwords are
ever stored there.

best,
Chipp
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your  
subscription preferences:

http://lists.runrev.com/mailman/listinfo/use-revolution




___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your  
subscription preferences:

http://lists.runrev.com/mailman/listinfo/use-revolution



___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Internal security of Rev?

[Dar Scott]

On Jul 12, 2006, at 6:20 PM, John Tregea wrote:

Thanks for your extensive reply. The point you raised about info  
leaks through memory was one of my two concerns, the other was what  
could be seen by 'peaking' into the built application.


In the latter case, you are using a hardwired password.  From my  
understanding of your recent mail, you don't want to do that.  Well,  
not completely.


I guess I can overwrite the memory variables I use by setting them  
to empty at the end of each handler.


First put a string of the right length into char 1 to -1 of the key.   
That will write over the key in RAM.  Now you might have  
inadvertently made copies by then.


I planned to do that when the user logs out anyway. I also was  
going to store the variables in custom properties (in encrypted  
form) during the session and set them to empty at the end of a  
session.


Why not a global?  If the file gets saved, you don't want them in  
properties.


Really there is just two things that have to be stored in the Rev  
side of the solution. That is the login user name and password for  
the postgreSQL database. Once the connection is made through that  
default account, there is a two, three or four factor validation  
process from within POstgreSQL.


If the user login is not used for data encryption, you do not need to  
keep any copies anywhere.  Use a digest such as MD5.  Even then you  
might need to have an ephemeral copy after it is keyed in, but there  
are ways to avoid that.


You can prevent entering of the db password until the user login is  
complete.


Earlier you had mentioned encrypting of data in the db at the client  
end.  If the user does not supply the password for that, then it is  
essentially and extension of your program and is as vulnerable as that.


I realised that I may be able to use the location of certain  
objects within the front end to build the key. The objects never  
move in relation to each other and the resulting string of numbers  
would be a perfectly hidden string.


maybe something like

repeat with x = 1 to the number of btnsput char 1 of the short  
name of btn x & item 1 of the loc of btn x after tTheKey

   if length(tTheKey) > 16 then exit repeat
end repeat
put char 1 to 16 of tTheKey into tTheKey

-- the key would end up something like b234t256h678f67u (a 128 bit  
key)


?

I would have to be careful that the stack window never has a new  
button inserted at a low layer in subsequent versions, or the  
clients would lose there data decrypt capability :-)


You can put a little time into obfuscation, but I wouldn't put a lot  
into it.  If this is used to hide the data encryption key, then your  
encryption is no better than a light scrambling.  If this level is  
fine, then this approach is fine.


The above method has the cool feature of being a sort of application  
digest, though.



Any thoughts?


Consider these questions.  The answers might affect your approaches.   
Is the server physically secure?  Is the client computer physically  
secure?  The network between?  Is there a risk of eavesdropping on  
the network?  Is there a risk of man-in-the-middle on the network?   
Is there a risk of a fake login to the db server?  Will people lose  
the ability to log in and access data?  Why does the data need to be  
encrypted at the client?  What encryption does the db support?  What  
are the actual standard requirements?  Are redundant layers needed?


If the data needs to be encrypted by the clients and decrypted by the  
clients, then you might as well use a secret key.  You can have the  
key kept at the client or kept at a key server.  In the first case,  
it needs to be encrypted with a user password (optionally mixed with  
your obfuscated application key) or derived from it (and optionally  
mixed).  In the second case, you still need a user password.  The  
second case might allow for encryption password management and handle  
login and db password management, too.  You can also break up the  
data into encryption zones and only provide the keys for the zones  
used by that user.


You said it yourself.  Believe it.  If you hide the key using  
scrambling level obfuscation, then you reduce your mil-grade  
encryption to scrambling level.  You can claim little about the  
encryption.


Dar



___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Internal security of Rev?

[kee nethery]

If I were you ... starting from the database working outward:

Build a CGI that talks to your database. Host that CGI on your  
servers. Give it the ability to access your database with a username  
and password that only it knows and give it the ability to execute  
any SQL that makes sense.


Have your app talk to the CGI. Have it log in either with a stored  
password in the app or have the user enter a password that you give  
to them, or both.


Have your app only send requests for SQL to be run. Don't send the  
SQL, send the name of the SQL and the parameters. For example:


SelectGameScores
Team = Dallas
Year = 2006

That gets converted in the CGI into

SQL = "select date,teamA,teamB,scoreA,scoreB from teamScores where  
date >= 'Jan 1, {year}' and date <= 'Dec 31, {year}' and (teamA =  
'{team}' or teamB = '{team}')"


SQL submitted = "select date,teamA,teamB,scoreA,scoreB from  
teamScores where date >= 'Jan 1, 2006' and date <= 'Dec 31, 2006' and  
(teamA = 'Dallas' or teamB = 'Dallas')"


Just make sure you do some validation in the CGI on the parameters  
that come in to prevent SQL injection.


If you do this, it doesn't matter if they can get direct access to  
your CGI, they can only run the SQL you have predefined.


Kee Nethery

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Internal security of Rev?

[Robert Sneidar]

There is no anti-pirate nirvana.


And also, another great saying: Nothing is Sailor-Proof. ;-)

Bob Sneidar
IT Manager
Logos Management
Calvary Chapel CM



___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Internal security of Rev?

[sims]

At 5:02 PM +1200 7/13/06, Richard Gaskin wrote:
That seems similar to RunRev's and others' time-limited-demo scheme, 
but does it prevent a user from attempting the same reg code on 
multiple machines?


After 30 days that code will not work when tried in any machine.
Before then, any machine can use that code. All schemes are limited.
There is no anti-pirate nirvana.

This does result in support issues - paid-up users who want to install it
again after the 30 days must go to a web page and obtain a new reg code.
There is no anti-pirate nirvana.

ciao,
sims

European Rev Conference  2006
www.techietours.com
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Internal security of Rev?

[Richard Gaskin]

sims wrote:


At 3:57 PM +1200 7/13/06, Richard Gaskin wrote:

Aside from hardware dongles, what devices/methods can prevent copying?


Although limited, Ambrosia software seems to use at least one such device.
When you come to the EuroRevCon in November I will explain this to you in more
detail, Richard.

From:  http://www.ambrosiasw.com/webboard/Forum14/HTML/52.html
"The fundamental change we made was to place the date a license code 
was generated into the code itself. That timestamp is then used at 
just one point in the process: it forces the user to activate the 
product within 30 days, or the code expires and won't activate 
anything, Now, and this is important, the timestamp has absolutely no 
effect on the operation of the software after the code has been 
entered. Once personalized for the user's computer, it remains fully 
functional forever (unless someone wipes the system clean)."


That seems similar to RunRev's and others' time-limited-demo scheme, but 
does it prevent a user from attempting the same reg code on multiple 
machines?


Thus far I've only seen phone-home systems do that

--
 Richard Gaskin
 Fourth World Media Corporation
 ___
 [EMAIL PROTECTED]   http://www.FourthWorld.com
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Internal security of Rev?

[sims]

At 3:57 PM +1200 7/13/06, Richard Gaskin wrote:

Aside from hardware dongles, what devices/methods can prevent copying?


Although limited, Ambrosia software seems to use at least one such device.
When you come to the EuroRevCon in November I will explain this to you in more
detail, Richard.

From:  http://www.ambrosiasw.com/webboard/Forum14/HTML/52.html
"The fundamental change we made was to place the date a license code 
was generated into the code itself. That timestamp is then used at 
just one point in the process: it forces the user to activate the 
product within 30 days, or the code expires and won't activate 
anything, Now, and this is important, the timestamp has absolutely no 
effect on the operation of the software after the code has been 
entered. Once personalized for the user's computer, it remains fully 
functional forever (unless someone wipes the system clean)."


ciao,
sims

European Rev Conference  2006
www.techietours.com
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Internal security of Rev?

[Richard Gaskin]

Mark Talluto wrote:

If you market your products through a distributor, copy protection is  
invaluable if they have rights to duplicate/install the software.


Aside from hardware dongles, what devices/methods can prevent copying?


--
 Richard Gaskin
 Fourth World Media Corporation
 ___
 [EMAIL PROTECTED]   http://www.FourthWorld.com
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Internal security of Rev?

[Mark Talluto]

On Jul 12, 2006, at 12:13 AM   Jul 12, 2006, Chipp Walters wrote:


I most definitely agree. I do believe a small bit of copy protection
helps keeps honest people honest. But returns are always better for
time spent on adding features vs copy protection.

On 7/12/06, Richard Gaskin <[EMAIL PROTECTED]> wrote:


With all due respect, the best investment of your time with regard to
anti-piracy is to ignore it altogether and put the time into  
features,
marketing, and offering world-class support.  Pirates are rarely  
in the

intersection of potential customers, so fighting them is a business
distraction.


If you market your products through a distributor, copy protection is  
invaluable if they have rights to duplicate/install the software.



Mark Talluto
--
CANELA Software
http://www.canelasoftware.com

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Internal security of Rev?

[Brian Yennie]

I would second that. If you're going to go to all of the trouble of 
encrypting your database, using SSL, taking thumbprints, etc, etc - 
then just about any method of storing critical passwords on the client 
side is going to immediately be the weak link. I would strongly 
consider just not storing the password on the client computer at all 
and making them enter it each time.


Chipp's method also would allow you to block all connections to the 
database that are not local. Make 'em go through an intermediary that 
only accepts certain commands/requests so that even with a username and 
password, they couldn't connect directly to the database server. Even 
for low security web apps, that is typically the case.



John,

Here's how I solve a similar problem.

I ask the user to login with a name and a password. They enter it and
it goes (securely) to a web page on a server, There the connection is
made to the database passing along the username and password for
verification. This way there is never a need to store anything but the
address of the webpage in the client app. No users or passwords are
ever stored there.

best,
Chipp
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your 
subscription preferences:

http://lists.runrev.com/mailman/listinfo/use-revolution




___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Internal security of Rev?

[John Tregea]

Hi Dar,

Thanks for your extensive reply. The point you raised about info leaks 
through memory was one of my two concerns, the other was what could be 
seen by 'peaking' into the built application. I guess I can overwrite 
the memory variables I use by setting them to empty at the end of each 
handler. I planned to do that when the user logs out anyway. I also was 
going to store the variables in custom properties (in encrypted form) 
during the session and set them to empty at the end of a session.


Really there is just two things that have to be stored in the Rev side 
of the solution. That is the login user name and password for the 
postgreSQL database. Once the connection is made through that default 
account, there is a two, three or four factor validation process from 
within POstgreSQL.


I realised that I may be able to use the location of certain objects 
within the front end to build the key. The objects never move in 
relation to each other and the resulting string of numbers would be a 
perfectly hidden string.


maybe something like

repeat with x = 1 to the number of btns 
   put char 1 of the short name of btn x & item 1 of the loc of btn x 
after tTheKey

   if length(tTheKey) > 16 then exit repeat
end repeat
put char 1 to 16 of tTheKey into tTheKey

-- the key would end up something like b234t256h678f67u (a 128 bit key)

?

I would have to be careful that the stack window never has a new button 
inserted at a low layer in subsequent versions, or the clients would 
lose there data decrypt capability :-)


Any thoughts?

John

Dar Scott wrote:


On Jul 12, 2006, at 2:27 AM, John Tregea wrote:

Yes my original question was about protecting classified information 
within a database where the front end may end up being Rev based.


You are mixing two levels.

If the information is encrypted and decrypted with a "hardwired" key, 
it is virtually part of the application.  It is subject to the 
limitations discussed.


However, if it is encrypted using a user supplied key, then it stands 
alone as encrypted information.  The user supplied key might be a 
certificate, a passphrase, or a passphrase to get to a certificate.


You can mix the user key with "hardwired" key to slow down decrypting 
without the user supplied key.


So, you need a user-supplied key.


But the structure of the stand alone rev application is my remaining 
concern. (unless you all think of some stuff I haven't thought of.)


The classified information would specifically be for supply chain 
risk assessments under ISO 28000 and 28001. We hope to use Rev to 
build a front end to a proprietary database structure, but have to 
know we can certify the resulting application under ISO 17799 
(Information Security Management) before clients would be prepared to 
use the product/service.


Revolution uses good cryptographic functions.  It uses a library that 
has undergone review and has a controlled build distribution process.


However, 1) you don't know what kinds of sneaking things folks at 
RunRev have put into their code.  I don't think they have done 
anything sneaky, I mean you are not able to demonstrate that they have 
not, without going to extra effort.  Also, 2) I would not be surprised 
if there are RAM info leaks through Revolution's memory management.  
That is, unused memory might be returned to the system without being 
written over.  Rev does a lot of copying.  (I do some things to 
mitigate this, but I have no idea if they really do any good.)  If 
those are not a concern for ISO 17799, I think you are OK.


Rev encryption is based on openSSL libraries and you need to make sure 
you have a good copy of a reviewed version.  Don't ship with what you 
get from RunRev for Windows; download a new copy and check the digest.


SSL is normally app to app, so you should be OK there, too.  However, 
at this time, you cannot supply a cert from the client side with Rev.  
(Unless something happened when I was asleep.)  Hmmm.  There should be 
an enhancement request for this.


Dar Scott

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your 
subscription preferences:

http://lists.runrev.com/mailman/listinfo/use-revolution



___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Internal security of Rev?

[Dar Scott]

On Jul 12, 2006, at 2:27 AM, John Tregea wrote:

Yes my original question was about protecting classified  
information within a database where the front end may end up being  
Rev based.


You are mixing two levels.

If the information is encrypted and decrypted with a "hardwired" key,  
it is virtually part of the application.  It is subject to the  
limitations discussed.


However, if it is encrypted using a user supplied key, then it stands  
alone as encrypted information.  The user supplied key might be a  
certificate, a passphrase, or a passphrase to get to a certificate.


You can mix the user key with "hardwired" key to slow down decrypting  
without the user supplied key.


So, you need a user-supplied key.


But the structure of the stand alone rev application is my  
remaining concern. (unless you all think of some stuff I haven't  
thought of.)


The classified information would specifically be for supply chain  
risk assessments under ISO 28000 and 28001. We hope to use Rev to  
build a front end to a proprietary database structure, but have to  
know we can certify the resulting application under ISO 17799  
(Information Security Management) before clients would be prepared  
to use the product/service.


Revolution uses good cryptographic functions.  It uses a library that  
has undergone review and has a controlled build distribution process.


However, 1) you don't know what kinds of sneaking things folks at  
RunRev have put into their code.  I don't think they have done  
anything sneaky, I mean you are not able to demonstrate that they  
have not, without going to extra effort.  Also, 2) I would not be  
surprised if there are RAM info leaks through Revolution's memory  
management.  That is, unused memory might be returned to the system  
without being written over.  Rev does a lot of copying.  (I do some  
things to mitigate this, but I have no idea if they really do any  
good.)  If those are not a concern for ISO 17799, I think you are OK.


Rev encryption is based on openSSL libraries and you need to make  
sure you have a good copy of a reviewed version.  Don't ship with  
what you get from RunRev for Windows; download a new copy and check  
the digest.


SSL is normally app to app, so you should be OK there, too.  However,  
at this time, you cannot supply a cert from the client side with  
Rev.  (Unless something happened when I was asleep.)  Hmmm.  There  
should be an enhancement request for this.


Dar Scott

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Internal security of Rev?

[John Tregea]

Chipp,

Thanks for the advice, I will have a think about all the various 
comments and see what seems the most secure approach. If we go ahead I 
may bounce the proposed structure of this list again.


Regards to all

John T

Chipp Walters wrote:

John,

Here's how I solve a similar problem.

I ask the user to login with a name and a password. They enter it and
it goes (securely) to a web page on a server, There the connection is
made to the database passing along the username and password for
verification. This way there is never a need to store anything but the
address of the webpage in the client app. No users or passwords are
ever stored there.

best,
Chipp
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your 
subscription preferences:

http://lists.runrev.com/mailman/listinfo/use-revolution



___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Internal security of Rev?

[Chipp Walters]

John,

Here's how I solve a similar problem.

I ask the user to login with a name and a password. They enter it and
it goes (securely) to a web page on a server, There the connection is
made to the database passing along the username and password for
verification. This way there is never a need to store anything but the
address of the webpage in the client app. No users or passwords are
ever stored there.

best,
Chipp
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Internal security of Rev?

[John Tregea]

Thanks Richard... (and Brian) (and everyone else)

Richard Gaskin wrote:

Brian Yennie wrote:

Although probably at least non-trivial, Chipp is probably on to 
something here. I don't think Rev script encryption is intended for 
the highest possible security.


Absolutely.  All code in all languages always leave their algorithms 
exposed to anyone with a low-level debugger/disassembler.  Code is not 
the place to store secure information.


Code in Rev is encrypted with a DES equivalent; more than most "script 
kiddies" can break, but often little more than a weekend's work for 
someone who knows what she's doing.


When a stack is encrypted, properties are also made unreadable in the 
disk file via the same DES-derived algo.  But since those properties 
must be usable at runtime, anyone with a copy of Rev can simply open 
and read properties.


Security is best handled with encrypting the data itself.  Rev now 
supports Blowfish and others, which can be made to exceed legal limits 
if needed, certainly sufficient for most industrial, medical, or 
government applications.


I haven't had a need for strong security in my apps as yet, so I'm 
confident others here can provide better details on the specifics (Dar 
-- where are you? ).  But given the range of industrial-strength 
encryption options Rev now supports, I see no reason why anything made 
with Rev would be any less secure than anything made with any other tool.



___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Internal security of Rev?

[John Tregea]

Dear Richard,

Thanks for your post. Yes my original question was about protecting 
classified information within a database where the front end may end up 
being Rev based.


My concern was whether the stand alone application (once built) could be 
disassembled in any way that would reveal some of the structure of the 
back end of the system. For example;


I plan to base64encode a user name and password for PostgreSQL and store 
each element in its own custom property in the main Rev stack.


Would it be possible for someone to read the scripts in the built 
application, run a base64decode on my two custom properties, and...

go do skull duggery in the database?

I realise I could tie the front end closer to the DB and create a 
legitimate account in PostgreSQL when an administrator sets up a new 
user account and password, but the administrator needs an account and 
password to do that and the db structure itself is confidential to our 
company.


You may have heard of the US "Container Security Initiate" and 
"Customs-Trade Partnership against Terrorism", the World Customs 
Organisations "Framework for Supply chain Security" or the International 
Maritime Organisations "International Ship and Port Facility Security 
Code"? Well we are building a front end (hopefully in rev) and a secure 
database for the risk assessments, operational compliance needs and 
documentation requirements of all the above...


The network communications would use SSL 128 bit encryption, the data in 
the database is encrypted (by revolution) using Blowfish, there will be 
a biometric thumb print scanner built into the keyboard, the application 
would only reside on a U3 Drive, the database will be on a dedicated 
Solaris 10 CPU with a hot swappable HD that would be removed when the 
operator is not present etc. etc. etc.


But the structure of the stand alone rev application is my remaining 
concern. (unless you all think of some stuff I haven't thought of.)


The classified information would specifically be for supply chain risk 
assessments under ISO 28000 and 28001. We hope to use Rev to build a 
front end to a proprietary database structure, but have to know we can 
certify the resulting application under ISO 17799 (Information Security 
Management) before clients would be prepared to use the product/service.


The branch of the thread about protecting the software is of interest 
too, but mainly because my boss would be very un... happy if I allow the 
results of years of research and development to be hacked when we 
release the software.


Having said all this I will now have to find and eliminate everyone that 
reads this email... ;-)


Regards

John T.

Richard Gaskin wrote:

John Tregea wrote:

I read about MD5 but thought it was a way of generating a hash string 
and using that string to check if the originating string had changed. 
Do you mean I could "un" MD5 a string like base64Decode?


MD5 is used to create a "signature" of a chunk of data which is 
mathematically improbable to have been derived by a different chunk. 
This is useful for comparing two things when you don't have the things 
themselves, such as passwords, but the MD5 result doesn't contain 
enough data to derive its source.


However one can use it in place of a password, so you can compare 
password results without ever embedding the password itself.


This extremely lightweight encryption function uses MD5 for that purpose:


While that particular function is at the "toy" level of security, 
stronger methods could be made which use MD5 in related ways.


But all of this seems a red herring, if I've read this thread 
correctly.  At first I had the impression we were talking about 
protecting critical data, but in later posts it seems we're just 
talking about anti-piracy.


With all due respect, the best investment of your time with regard to 
anti-piracy is to ignore it altogether and put the time into features, 
marketing, and offering world-class support.  Pirates are rarely in 
the intersection of potential customers, so fighting them is a 
business distraction.


--
 Richard Gaskin
 Managing Editor, revJournal
 ___
 Rev tips, tutorials and more: http://www.revJournal.com
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your 
subscription preferences:

http://lists.runrev.com/mailman/listinfo/use-revolution



___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Internal security of Rev?

[Chipp Walters]

I most definitely agree. I do believe a small bit of copy protection
helps keeps honest people honest. But returns are always better for
time spent on adding features vs copy protection.

On 7/12/06, Richard Gaskin <[EMAIL PROTECTED]> wrote:


With all due respect, the best investment of your time with regard to
anti-piracy is to ignore it altogether and put the time into features,
marketing, and offering world-class support.  Pirates are rarely in the
intersection of potential customers, so fighting them is a business
distraction.

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Internal security of Rev?

[Richard Gaskin]

John Tregea wrote:

I read about MD5 but thought it was a way of generating a hash string 
and using that string to check if the originating string had changed. Do 
you mean I could "un" MD5 a string like base64Decode?


MD5 is used to create a "signature" of a chunk of data which is 
mathematically improbable to have been derived by a different chunk. 
This is useful for comparing two things when you don't have the things 
themselves, such as passwords, but the MD5 result doesn't contain enough 
data to derive its source.


However one can use it in place of a password, so you can compare 
password results without ever embedding the password itself.


This extremely lightweight encryption function uses MD5 for that purpose:


While that particular function is at the "toy" level of security, 
stronger methods could be made which use MD5 in related ways.


But all of this seems a red herring, if I've read this thread correctly. 
 At first I had the impression we were talking about protecting 
critical data, but in later posts it seems we're just talking about 
anti-piracy.


With all due respect, the best investment of your time with regard to 
anti-piracy is to ignore it altogether and put the time into features, 
marketing, and offering world-class support.  Pirates are rarely in the 
intersection of potential customers, so fighting them is a business 
distraction.


--
 Richard Gaskin
 Managing Editor, revJournal
 ___
 Rev tips, tutorials and more: http://www.revJournal.com
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Internal security of Rev?

[John Tregea]

Yikes!, that point number 4 is a tall order. But happily it is one of 
the core parts of what we do and how we are able to do it.


My boss always said, "how can you write software to help people be 
organised if you can't even keep your sock drawer tidy?". Mind you I 
don't know that she had ever seen my sock drawer, but my office drawer 
may have given her a clue O:-) .


So the short answer is we take a plenty of time to get things right 
(three years on the current development) (nearly a year of evaluations 
looking for the correct development environment and database 
combination) and back up everything we do regardless of what it takes to 
fix a problem (if it is of our making). I did say this was the short 
answer, so I better shut-up now.


Thanks for all the assistance, I was hesitant to ask as we are still in 
evaluation mode and not a licensed user yet. (soon though, soon :-) )


John T


Dar Scott wrote:


On Jul 11, 2006, at 8:56 PM, John Tregea wrote:

Like putting a big padlock on the door with a note stuck to it saying 
"the key is under the mat".


Yes.

You need to write the note in pig-latin.

(almost) The best you can do is obfuscation.  Don't put your key in 
one place.  Don't leave your key in your code in a form that looks 
like a key from an editor.  Don't use a script that can be seen by a 
text editor.  Even machine language is just obfuscation.  Everybody 
has this same problem to some degree.


However, there are a few things you can do.

1
If you assume a paying customer is less likely to try to break your 
encryption, then put part or all of the decryption key in the software 
enabling key (serial number or whatever you call it).


2
Don't put all your eggs in one basket.  Don't use the same encryption 
key for all modules or all products.  This is even better when 
combined with #1.


3
Don't keep decrypted pieces in files.  Not very long, if you have to.

And most of all...

4
Keep motivation by sneaks low:  Keep your price low.  Come out with 
something better, soon.  Provide good support.  Fix bugs.  Make sure 
the software is flexible.  Be ready to license and supply OEM 
components.  Your happy customers will never notice that there is an 
encryption challenge; be ahead of them on what you give them.


Dar Scott
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your 
subscription preferences:

http://lists.runrev.com/mailman/listinfo/use-revolution



___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Internal security of Rev?

[John Tregea]

Hi Jim,

Remind me never to play poker with you... :-)

Thanks very much, I was leaning towards breaking things up into chunks 
and hiding them in places, but thought the script would allow a 
knowledgeable hacker to reverse my process to easily.


I will explore further (but quickly before my trial expires)

John

Jim Ault wrote:

You could make a small bit compress/decompress routine which would give you
less transparency. 


Perhaps using BinaryEncode/BinaryDecode in the Rev lib.  Multiple variables
in one call, very fast.  Fancier would be two levels of encoding.

You could also INTERLACE the chars of a variable between two or more custom
properties

on doInterLace  textBlock --between 2 custom properties
  put 1 into flag  --actually, any number will do
  repeat for each char CH in textBlock
put flag*-1 into flag
put CH after tempArr[flag]
  end repeat
  set the custompropertyset of this stack to "lkupTA"
  set the customproperties of this stack to tempArr
end doInterLace

And now you have interlaced chars (even cr's and nulls) in one propertyset
in two custom properties [1] and [-1].  Let them read THAT with their
morning coffee.

Extra subterfuge...  build the above script at runtime so it isn't even in
the file this is a 9-liner and you are allowed 10.

build the script
set the script of btn eraser to myScript
insert the script of btn eraser into back

doInterlace textBlock

Of course you would not want to call it 'interlace'...  perhaps sunflower,
or getIntOfLastItem.

Jim Ault
Las Vegas

On 7/11/06 7:42 PM, "Troy Rollins" <[EMAIL PROTECTED]> wrote:

  

On Jul 11, 2006, at 9:49 PM, John Tregea wrote:



Our application will be used to front end a database that contains
classified information, the initial login account details would
have to be stored in the Rev application (inside custom properties
  

IIRC, a couple of years back I planned to use custom properties for
this sort of thing. As I remember it, that had to be ditched because
custom properties ended up as plain text, easily readable by dropping
the stack file on a text editor. I think we pulled the properties
into script and populated them at runtime, which gave a marginally
more secure feeling.

To this day I still don't know of a very good way to handle this in
Rev produced apps. I'm all ears.

--
Troy
RPSystems, Ltd.
http://www.rpsystems.net


___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution




___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


  

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Internal security of Rev?

[John Tregea]

Hi Brian,

I read about MD5 but thought it was a way of generating a hash string 
and using that string to check if the originating string had changed. Do 
you mean I could "un" MD5 a string like base64Decode?


I follow you though and have now planned to store the really sensitive 
keys and names of encryption methods in the database.


I do need to store one user name and password in the front end though to 
enable Rev to connect to PostgreSQL and validate the users right to log 
in to get the rest of their accreditation and permissions.


Cheers

JT

Brian Yennie wrote:

John,

Although probably at least non-trivial, Chipp is probably on to 
something here. I don't think Rev script encryption is intended for 
the highest possible security. More like enough to keep out anyone who 
is *not* an expert.


Is it really critical for your application to store the login 
information, including password, on the client machine? That seems 
like a weak point of the security regardless of what tool you use. 
Even compiled C-code can be hacked, but it's much harder to do if the 
login information is stored remotely.


If you must store the password locally, you might look into the merits 
of a simple MD5-based solution. That is, compute a hash of the 
password and store that.


Finally, you might consider what the other weak points are. For 
example, unbreakable encryption will only do you so much good if you 
then send the password over an insecure network connection. If someone 
can just record and play back your communications, they don't have to 
know what's actually in it to break in.


As with all anti-hack measures, it will basically boil down to what is 
enough of a deterrent that it's not worth the effort to crack. There 
are virtually no unbreakable schemes, it's more a matter of setting 
the bar higher than the particular would-be intruder can reach.


HTH


John,

I'm no cryptographer, but I would guess cracking Rev's password
protected code wouldn't be too awfully hard. Mainly this is because
you can expect to find multiple occurrences of strings like "on
mouseUp". I'm not suggesting any novice could crack it, but I imagine
someone with some decent tools and a bit of time could get in.

You could probably get a more learned opinion from Dar Scott or
someone with more cryptography chops than I have.

Just my opinion,
Chipp
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your 
subscription preferences:

http://lists.runrev.com/mailman/listinfo/use-revolution




___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your 
subscription preferences:

http://lists.runrev.com/mailman/listinfo/use-revolution



___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Internal security of Rev?

[Troy Rollins]

On Jul 12, 2006, at 12:27 AM, Dar Scott wrote:

The best you can do is obfuscation.  Don't put your key in one  
place.  Don't leave your key in your code in a form that looks like  
a key from an editor.  Don't use a script that can be seen by a  
text editor.  Even machine language is just obfuscation.  Everybody  
has this same problem to some degree.


So, what does this mean in terms of Revolution?

Don't use unencrypted custom properties for anything you consider  
security sensitive data?


Encrypt custom properties and use a runtime code-assembled key to  
decrypt them?


--
Troy
RPSystems, Ltd.
http://www.rpsystems.net


___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Internal security of Rev?

[Richard Gaskin]

Brian Yennie wrote:

Although probably at least non-trivial, Chipp is probably on to 
something here. I don't think Rev script encryption is intended for the 
highest possible security.


Absolutely.  All code in all languages always leave their algorithms 
exposed to anyone with a low-level debugger/disassembler.  Code is not 
the place to store secure information.


Code in Rev is encrypted with a DES equivalent; more than most "script 
kiddies" can break, but often little more than a weekend's work for 
someone who knows what she's doing.


When a stack is encrypted, properties are also made unreadable in the 
disk file via the same DES-derived algo.  But since those properties 
must be usable at runtime, anyone with a copy of Rev can simply open and 
read properties.


Security is best handled with encrypting the data itself.  Rev now 
supports Blowfish and others, which can be made to exceed legal limits 
if needed, certainly sufficient for most industrial, medical, or 
government applications.


I haven't had a need for strong security in my apps as yet, so I'm 
confident others here can provide better details on the specifics (Dar 
-- where are you? ).  But given the range of industrial-strength 
encryption options Rev now supports, I see no reason why anything made 
with Rev would be any less secure than anything made with any other tool.


--
 Richard Gaskin
 Fourth World Media Corporation
 ___
 [EMAIL PROTECTED]   http://www.FourthWorld.com
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Internal security of Rev?

[Dar Scott]

On Jul 11, 2006, at 8:56 PM, John Tregea wrote:

Like putting a big padlock on the door with a note stuck to it  
saying "the key is under the mat".


Yes.

You need to write the note in pig-latin.

(almost) The best you can do is obfuscation.  Don't put your key in  
one place.  Don't leave your key in your code in a form that looks  
like a key from an editor.  Don't use a script that can be seen by a  
text editor.  Even machine language is just obfuscation.  Everybody  
has this same problem to some degree.


However, there are a few things you can do.

1
If you assume a paying customer is less likely to try to break your  
encryption, then put part or all of the decryption key in the  
software enabling key (serial number or whatever you call it).


2
Don't put all your eggs in one basket.  Don't use the same encryption  
key for all modules or all products.  This is even better when  
combined with #1.


3
Don't keep decrypted pieces in files.  Not very long, if you have to.

And most of all...

4
Keep motivation by sneaks low:  Keep your price low.  Come out with  
something better, soon.  Provide good support.  Fix bugs.  Make sure  
the software is flexible.  Be ready to license and supply OEM  
components.  Your happy customers will never notice that there is an  
encryption challenge; be ahead of them on what you give them.


Dar Scott
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Internal security of Rev?

[Brian Yennie]

John,

Although probably at least non-trivial, Chipp is probably on to 
something here. I don't think Rev script encryption is intended for the 
highest possible security. More like enough to keep out anyone who is 
*not* an expert.


Is it really critical for your application to store the login 
information, including password, on the client machine? That seems like 
a weak point of the security regardless of what tool you use. Even 
compiled C-code can be hacked, but it's much harder to do if the login 
information is stored remotely.


If you must store the password locally, you might look into the merits 
of a simple MD5-based solution. That is, compute a hash of the password 
and store that.


Finally, you might consider what the other weak points are. For 
example, unbreakable encryption will only do you so much good if you 
then send the password over an insecure network connection. If someone 
can just record and play back your communications, they don't have to 
know what's actually in it to break in.


As with all anti-hack measures, it will basically boil down to what is 
enough of a deterrent that it's not worth the effort to crack. There 
are virtually no unbreakable schemes, it's more a matter of setting the 
bar higher than the particular would-be intruder can reach.


HTH


John,

I'm no cryptographer, but I would guess cracking Rev's password
protected code wouldn't be too awfully hard. Mainly this is because
you can expect to find multiple occurrences of strings like "on
mouseUp". I'm not suggesting any novice could crack it, but I imagine
someone with some decent tools and a bit of time could get in.

You could probably get a more learned opinion from Dar Scott or
someone with more cryptography chops than I have.

Just my opinion,
Chipp
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your 
subscription preferences:

http://lists.runrev.com/mailman/listinfo/use-revolution




___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Internal security of Rev?

[Jim Ault]

You could make a small bit compress/decompress routine which would give you
less transparency. 

Perhaps using BinaryEncode/BinaryDecode in the Rev lib.  Multiple variables
in one call, very fast.  Fancier would be two levels of encoding.

You could also INTERLACE the chars of a variable between two or more custom
properties

on doInterLace  textBlock --between 2 custom properties
  put 1 into flag  --actually, any number will do
  repeat for each char CH in textBlock
put flag*-1 into flag
put CH after tempArr[flag]
  end repeat
  set the custompropertyset of this stack to "lkupTA"
  set the customproperties of this stack to tempArr
end doInterLace

And now you have interlaced chars (even cr's and nulls) in one propertyset
in two custom properties [1] and [-1].  Let them read THAT with their
morning coffee.

Extra subterfuge...  build the above script at runtime so it isn't even in
the file this is a 9-liner and you are allowed 10.

build the script
set the script of btn eraser to myScript
insert the script of btn eraser into back

doInterlace textBlock

Of course you would not want to call it 'interlace'...  perhaps sunflower,
or getIntOfLastItem.

Jim Ault
Las Vegas

On 7/11/06 7:42 PM, "Troy Rollins" <[EMAIL PROTECTED]> wrote:

> 
> On Jul 11, 2006, at 9:49 PM, John Tregea wrote:
> 
>> Our application will be used to front end a database that contains
>> classified information, the initial login account details would
>> have to be stored in the Rev application (inside custom properties
> 
> IIRC, a couple of years back I planned to use custom properties for
> this sort of thing. As I remember it, that had to be ditched because
> custom properties ended up as plain text, easily readable by dropping
> the stack file on a text editor. I think we pulled the properties
> into script and populated them at runtime, which gave a marginally
> more secure feeling.
> 
> To this day I still don't know of a very good way to handle this in
> Rev produced apps. I'm all ears.
> 
> --
> Troy
> RPSystems, Ltd.
> http://www.rpsystems.net
> 
> 
> ___
> use-revolution mailing list
> use-revolution@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution


___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Internal security of Rev?

[John Tregea]

Thanks Chipp and Troy,

I have looked at the encryption that is built into Rev and it seems very 
robust in terms of encrypting data. But I have to save the bit length, 
encryption type and key string (128 byte character string) inside rev to 
be able to un-encrypt the data coming back from the database. I have 
base64encoded them in my trials (and stuck them in custom properties) 
but know that the syntax in the scripts spells out where to get the info 
and how to decode it.


Like putting a big padlock on the door with a note stuck to it saying 
"the key is under the mat".



John

Troy Rollins wrote:


On Jul 11, 2006, at 9:49 PM, John Tregea wrote:

Our application will be used to front end a database that contains 
classified information, the initial login account details would have 
to be stored in the Rev application (inside custom properties


IIRC, a couple of years back I planned to use custom properties for 
this sort of thing. As I remember it, that had to be ditched because 
custom properties ended up as plain text, easily readable by dropping 
the stack file on a text editor. I think we pulled the properties into 
script and populated them at runtime, which gave a marginally more 
secure feeling.


To this day I still don't know of a very good way to handle this in 
Rev produced apps. I'm all ears.


--
Troy
RPSystems, Ltd.
http://www.rpsystems.net


___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your 
subscription preferences:

http://lists.runrev.com/mailman/listinfo/use-revolution



___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Internal security of Rev?

[Troy Rollins]

On Jul 11, 2006, at 9:49 PM, John Tregea wrote:

Our application will be used to front end a database that contains  
classified information, the initial login account details would  
have to be stored in the Rev application (inside custom properties


IIRC, a couple of years back I planned to use custom properties for  
this sort of thing. As I remember it, that had to be ditched because  
custom properties ended up as plain text, easily readable by dropping  
the stack file on a text editor. I think we pulled the properties  
into script and populated them at runtime, which gave a marginally  
more secure feeling.


To this day I still don't know of a very good way to handle this in  
Rev produced apps. I'm all ears.


--
Troy
RPSystems, Ltd.
http://www.rpsystems.net


___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Internal security of Rev?

[Chipp Walters]

John,

I'm no cryptographer, but I would guess cracking Rev's password
protected code wouldn't be too awfully hard. Mainly this is because
you can expect to find multiple occurrences of strings like "on
mouseUp". I'm not suggesting any novice could crack it, but I imagine
someone with some decent tools and a bit of time could get in.

You could probably get a more learned opinion from Dar Scott or
someone with more cryptography chops than I have.

Just my opinion,
Chipp
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Internal security of Rev?

[John Tregea]

Hi all,

I have evaluated Rev a couple of times across the last few version 
releases and feel quite satisfied that it will enable us to achieve the 
things we want in terms of commercial product development.


I have a question about the readability of the scripts "source code" of 
an application once it is built as a standalone. I have seen the 
"encrypt with password" option in the standalone settings but want to 
know if anyone can tell me how secure this option is.


Our application will be used to front end a database that contains 
classified information, the initial login account details would have to 
be stored in the Rev application (inside custom properties ?). I know I 
can base64encode the username and password for the database before 
putting them into the custom properties, but if someone is able to read 
my script, they could discover which custom properties I use and how to 
decode the information. This would eventually lead them to a direct 
connection to the database and the potential for SQL injection attacks 
etc. on the back end.


Other steps I intend to take is to put the front end rev application on 
a U3 drive and encode the drive serial number uniquely into the rev app 
to stop it being copied and run from another location (effective copy 
protection, I hope). I also thought to measure the available space on 
the volume [diskSpace] where the application is first installed (U3 
drive) and check it each time the application launches (quitting if the 
disk space is greater than the original space on the initial installed 
USB device).


Any other experiences/ideas/suggestions would be greatly appreciated.

If all is OK, then I can get the enterprise product and formally join 
your community...


Thanks and regards

John T.
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution