Password Protection?

[JohnyQuick]

I have a question, and Im hoping for the best, so here it goes. I was recently told by another "anonymous" DF Developer, that the Document Password is easily visible, if you open up the Document in Windows Notepad.

I tried what he said, and there was my password, easily visible to anyone using the PC, and knew where to look. Albeit, only another developer would realy know exactly where to look.

I use Runtime liscences and password protect my documents, under Document Settings.

So, I guess my question is, are my passwords bonded, or tied to MY DF liscence, in such a way, that another Developer could not open my Document, even if he knew my password, but was using HIS Software Liscence?

Or, to be repetitive, could he only open my document if he met 2 conditions.

1) He knows the easily available "Password" to my document.

and

2) MY Software Liscence, which is currently on a cryptoken.?? Which he doesnt have.

I did a search of the Forum on Passwords, but would like you to clarify.

[AzeoTech]

There is no bonding to your license. The password is the only protection. I have the following advice:

1) make the password something with random characters, not a word. Something like: "$9i!".

2) the password is not located in the same place in every file, so if you follow suggestion #1, its very unlikely someone who doesn't know your password will ever be able to find it by opening the file in notepad or even a real binary editor. It would get lost among all the other stuff in the file.

and now the important parts:

3) most hacking nowadays, at least lower->mid level is social hacking. This means that if you follow the above advice, the most likely way someone is going to steal your document and edit it is to find your password written down somewhere, in an email, or it will simply be one of your disgruntled employees. All the encryption in the world won't help you there. I give you example A: some writer for a big publisher had the domain name xyz.com and another guy wanted it, but the writer didn't want to sell. Well, the other guy was pretty upset, somewhat experienced hacker, and obviously bored. He managed to find some basic info about the guy (his name and birthdate was all he got I believe), then called Apple and managed to get the guy's username and password with just that info. Once in, he was able to delete all his cloud data, reset his phones and do a lot of other damage. It wouldn't have mattered if the writer had a random 32 character password or simply the word "password". This guy got in by simply asking someone for the password. You could have DAQFactory locked up tight, and then your competitor could call in pretending to be you and ask your new secretary for the password because you forgot it, and they might give it to them, and you're done.

4) no matter how much protection we offer (and we can't offer that much because of export regulations), if someone wants to edit your document, they'll figure a way to do it. I'm not going to discuss how that might happen, but software piracy has been a problem since the beginning of software and the hackers have always been ahead of the developers. The Document Editing password is like a lock on your house: it keeps honest people honest, and lazy thieves out. But if someone wants into your house, they'll get in.

5) Much of the modern content on the web, especially the good stuff is in Javascript. Javascript is like DAQFactory and is an interpretted language. As such, its not compiled or encrypted (how could it be?). Therefore, if you go to some website, you can simply ask the browser for the source code and someone could copy and steal the program. In the end though, a good company recognizes that service, and continual software improvements are what sells. Chances are if a company is too cheap to create their own tool, they are too cheap to provide good service. Not to mention, they'll never be able to keep up with improvements and bug fixes because they haven't learned anything from developing the application themselves. And if that doesn't work, there are always lawyers.

[JohnyQuick]

Thank you fo that, um, disertation. The other developer already has everything Ive done, and the document would require quite alot of modification to be used by another company, or individual. Even if he has my doc, Im not sure what good it would do him.

For, now I have a solution to the password, but Im not going to discuss it here on the forum. Daqfactory is a great product, and Ive been able to do what I set out to do a year and a half ago. And theres always OEM if I decide to get real serious.

Actually, Im glad I found out what I did from the other Developer, rather than pose like the Emperors New Clothes are on.

[AzeoTech]

Sorry if I ran on a little long. I just like to be thorough. The topic has come up several times in the past couple weeks on the phone, so I thought maybe I should put it all down here.

I should add that if your goal is copy protection, i.e. keeping a customer from simply buying DF Runtime, or downloading a trial and using your .ctl app, there are a number of options available, from fancy scripting with registry values, to using a dongle similar to the one we use.

I should also add that you technically could really lock up your scripts using a combination of encryption and a dongle that contains the encryption key. It, however, would require a bit of effort, but if you only wanted to protect a few sequences, it wouldn't be that hard. Many php developers do something similar: they release 95% of their code as open source, but the real key parts they encrypt. Anyhow, most dongle manufacturers provide the encryption routines for you. You'd just use extern() to access their DLL, or more likely a DLL you created as a wrapper. Hell, most dongles actually have a fair bit of memory on them. You could encrypt and store the critical sequence script right there on the key. I'd put that code in a class (or classes) so that you could simply load and decrypt the script, then call execute() on the script to define the classes. Then you could put lots of functions right in one script string.

[SteveMyres]

You can get all the random bytes you need (to create strong random passwords or harvest keytext) from

https://www.fourmilab.ch/hotbits/secure_generate.html

It's actually true random numbers generated by nuclear decay detection.

[AzeoTech]

True, and I use a handy tool called keypass which does the same thing and actually tracks my passwords so I don't write them down somewhere.

However, its important to note that as an interpretted language, anyone who has the skills to crack even a relatively simple password (say a few random characters you come up with), will have the skill to access your script. Its simply the price you pay for an interpretted language. The advantages, however, outweigh this, namely the ability to make changes on the fly and to go to runtime installations and do development without shutting the system down. As I put towards the top, most web apps are written in javascript and this is basically open to any programmer that wants to steal it. Its the price you pay as a developer for creating web apps that work on lots of browsers. If you are stuck on closed source, then you have to use something like Flash, which I'm sure everyone will agree is a slowly dying technology, especially since it won't run on iOS devices.

I'm not touting open source or anything. DF is closed source after all. Its just important to keep perspective.

[SteveMyres]

Agreed. Sometimes you still need security within the app (such as my current app with user level logins), so it's good to have a handy entropy well when you need it!

[AzeoTech]

Absolutely. I just don't want anyone to get a false sense of security with their app.

[JohnyQuick]

Thanks!, Your brief explanation of USB Dongles sounds like a good idea. Right now I use one Cryptoken to access my document on computers with a DF Runtime license on them.

Lets say I want to lock up my document , by using a dongle and encryption. If a make startup sequence , that starts my other sequences, and somehow encrypt that sequence into the token, so that my CTL document will not run without the cryptoken/dongle? Does that make sense. Or does the CTL itself get encrypted onto the dongle? In any case, would I then need 2 tokens to edit/change my document on a Runtime licensed PC?

Could you just explain a little more how using a dongle could protect a CTL better?

Thanks

[JohnyQuick]

And SOMETIMES, more than just a veil of false security is EXPECTED.!!!!! One wouldnt need a users password or even try to guess the password, in order to TAKE another persons DOCUMENT-ctl.

All that is needed, is to open the document-ctl in safe mode for example, and then change ANY setting in in your DOCUMENT SETTINGS tab, under the FIle TAB, and then save as the document, or even just SAVE, and keep the same name.

VOILA, as they say in France, the previous users Password is GONE-NULL-no longer of any use more for protection AT ALL.!!!! What a JOKE!!

The NEW USER is now Free to take and use the CTL at will or call his own-copy-whatever!!

This is a serious Flaw in DAqfactory, in my opinion. Might as well just learn C++ instead.

[AzeoTech]

As I mentioned, since DAQFactory is an interpretted language, there is very little you can do to really, truly protect your script. At some point, DAQFactory has to have it in a form it can compile, and that means it will exist at that point, in memory, in its normal form. The only way you can protect your code is to move it to C++ in a DLL and have DAQFactory load it. I'm not saying do your whole app, just the important algorithms you don't want someone to steal. Then you can lock up the C++ code with a dongle or whatever you want. Unfortunately, this is really the only choice that is most foolproof, though anything can be reverse engineered.

If you are trying to protect the application from being copied, then you could use a dongle, however, someone could try and get access to your script and would then get the passcode to the dongle and thus bypass it. The dongle option really is an "honest people honest", much like a door lock. Someone who really wants to copy it will not have too much problems just kicking the door in.

[AzeoTech]

I'm not sure what you are talking about. What release (#) and what version (base / pro, etc) are you running in? I just ran 5.87a, the latest. Create a new document. Added just a single control, set a document editing password, saved the doc, did file - new, did File - open in safe mode, and the file opened in Runtime, requiring me to enter the password to switch to development.

[SteveMyres]

As I mentioned, since DAQFactory is an interpretted language, there is very little you can do to really, truly protect your script. At some point, DAQFactory has to have it in a form it can compile, and that means it will exist at that point, in memory, in its normal form.

Hmmmm. Would it be feasible to create a development-time pre-compilation option so that step can be avoided at runtime (and which would also inherently read-protect as well)? Note that I'm not suggesting the ability to create standalone exe's (though that would obviously be very cool if feasible) just a hard app file that can't be edited, viewed, or have its password bypassed.

Obviously apps deployed in that form wouldn't be editable while running, but for some applications that would actually be preferred.

[AzeoTech]

Yes, that is a good idea. Can you post it on our request list so the idea doesn't get lost?

[EOlsen]

I like the idea of using compiled code only for run-time installations as a means of protecting script code and hope that gets implemented.

 

In the mean time if you want to use passwords for different user access levels instead of storing the password as a string do a sum or an even more complicated math function on the bytes of the password and store the results as a number. Use the same password to math function to compare an entered password with the stored numeric password. This way even if someone sees your stored (numeric) password, it will be harder to figure out what text to enter to generate the same number.

[AzeoTech]

It is unlikely that we would implement it in this way (only compiled code).  We would be more likely to simply encrypt script (or rather the whole file) with reasonably heavy encryption, especially now that we have cleared the export regulation hurdles.  Really, if someone is going to go through the trouble to try and trace through DAQFactory and retrieve your script after decryption, encryption vs compilation isn't going to make a difference as it would be just as easy to recover it from the compiled script.  If your algorithms are that valuable, you probably should just compile them in C and call them using extern().  But even then, someone can trace through your C code, so there is no true protection.  Its something that software developers learn to live with, often protecting themselves with the law, or better yet, by offering excellent service to their customers.  This is especially an issue in the era of web apps which are often written in JavaScript which can only be obfuscated, and are pretty easy to reverse engineer.

 

As for the passwords, the technique EOlsen describes is called a hash and is very typical.  We don't use it because a lot of times customers forget their password, and with a hash it can't be restored without a fair bit of trouble.  Its worth considering, but we'd likely have to charge customers a few hundred dollars whenever they forgot their password to recover editing capability on the document (we charge $50 now).