Passwords

krunalc is experiencing a bad time with passwords. It's probably worth a generic thread on the subject.

How do you feel about passwords? Do you use them? Are your opinions about people who use them printable?

Personally, I don't use them, but I can envision a few cases where I might be tempted to.

The first case would be if I had developed what I considered to be a proprietary algorithm that gave me a competitive edge. In that case, I'd put the algorithm in a subroutine, call the subroutine unconditionally from the main program, and password protect only the subroutine, leaving the rest of the program open to anybody for modifications as needed.

Another case would be to prevent unauthorized people from making changes, especially if there was a concern about someone changing the logic or the password out of malice.

If I were to use passwords, I'd be upset if the manufacturer of the PLC had provided a backdoor entry. That defeats the whole purpose of the password.

If you are an end user of equipment that includes a PLC, you can include a clause in your contract with the machinery builder that you be given any passwords. If you are contracting somebody to write PLC logic for you, include the same clause. You may find that the OEM or the programmer puts up a fight over the issue, but it's better to know about these things before you sign the contract, while you still have some leverage.

I like your idea of password protecting key subroutines.

Another option is to give the whole project to the end user zipped and password protected with instructions on how to get the password from your lawyer should something happen to you or your company. We have had to do that for some of our products. One could still use two levels of passwords in this case. One password for the whole project and another password for more proprietary routines.

We will be coming out with a new product where we will allow the programmer to zip and download the project source and commments into flash on the module. The programmer will be able to zip with a password if desired. This will be a function of winzip or what ever zip tool is being used rather that our product. By doing this we hope that we will be able to avoid this debate and keep it between the integrator and the end user.

We once had some (VB) source code that a former (and disgruntled) employee had zipped and password protected.

We found a program that would hack through the zip password-protection by brute force, trying every possible combination (allowing you to set parameters, like number of characters, alphanumeric v. just alpha v. just numeric, etc).

We set about 20 PCs to the task each night of cranking through everthing. After about a week and a half, we got in and was able to extract the code.

There's no moral to this story. I'm as ambivalent as Steve as to the use/advantage of passwords, and have, like Tom, put source code in escrow, in the event of the demise of the company. I've come up with a hack around the AB protection scheme that not even AB came up with (and have promised Ken Roach that I would not reveal).

There are no secrets. "What Man creates, Man can also destroy". The only question is how much effort is someone willing to go through to get at what he wants.

Will the manufacturer of the software leave a "back door"? Certainly. Remember, it's the software that's denying access, not the hardware. If a "security-free" version of the software existed (and who better to write it than the PLC manufacturer), no code would be secure. Access would just come at a price.

My company does business with one of the largest strapping suppliers in the world. We pay around $70,000 for a complete set-up. I was shocked when I learned they password protect their program. When I'm in the field and have problems with a strap head, my only recourse is to call their service department. I don't agree with this at all. They don't provide a copy of the PLC program, in any form. The only reason we do business with them now is because they bought out the company we were buying from. I wonder just what their motives are for keeping their program off limits. I doubt it is because they are worried about losing a competitive edge, their machines are second to none.

My previous employer did pass word their PLC's to keep an unauthorized or disgruntled employee from getting access. I agree with that. It doesn't take a rocket scientist to really mess things up. Just think about it, what if someone in your facility wrote a subroutine that would trigger days or weeks after he was gone. MAJOR damage or physical injury could occur.

Get what you want in writing during the proposal and submittal stages of the job. Be specific.
Most of my customers don't get licenced copy of the PLC or OIT programming software or the ladder. I put a supervisor password in the OIT and the Plant Super can issue lower passwords to operators as required to run the system. If an operator somehow gets high level access to change parameters and doesn't know what he is doing, he may cause damage. It has happened to us and we go to great lengths to put disclaimes in our warranty now.
In the case of customers getting a copy of our code, we don't password it but we specify that if they make changes during the warranty period and damage results, we are not liable.

Great topic!...

I've never used password protection on a program, and don't plan to in the future. I feel that the end user "owns" the program and should have full access. Steve's "first case" scenario is the only case where I'd consider implementing one. Actually, I never realized that you can protect individual subroutines, so thanks for that tip Steve!

A concern (er, paranoia?) I've always had is that the end user of one of our machines would modify the program, which results in damage to the machine, then re-loads the original program and blame us for the damage. So far I've been lucky(?) in that our end users:

A.) Have no clue what a PLC is, and call us if problems arise.

B.) Have someone in-house that can safely make modifications only when authorized by us.

C.) Have an in-house programmer who knows what he's doing and/or realizes that he is responsible for any consequences his program change causes.

I can think of no way to "prove" that a program was modified, then the original re-loaded. There are no logs (in the PLC) that keep track of changes (at least none that I know of). I guess this is just one of those things you just have to hope doesn't happen? utoh

For that matter, there's nothing stopping anyone from say, jumping out a safety guard, causing someone injury, then removing the jumper and blaming the OEM. These people are probably out there, so we can only hope we don't meet up with them...

OK, enough with my paranoia... It'll never happen (Eric says with fingers crossed)...

beerchug

-Eric

P.S. Peter, realize that what Allen says about zip passwords is very true. Since compression software is meant "for the masses", there is more "zip password cracking" software available than you can shake a stick at! Since PLCs are only interesting to a small percentage of the world's population (namely us guys!), I think a PLC password is probably a MORE secure method.

Re: Great topic!...

Eric Nelson said:

P.S. Peter, realize that what Allen says about zip passwords is very true. Since compression software is meant "for the masses", there is more "zip password cracking" software available than you can shake a stick at! Since PLCs are only interesting to a small percentage of the world's population (namely us guys!), I think a PLC password is probably a MORE secure method.

Click to expand...

I realize that nothing is secure given time. The goal is to make it too difficult so that it is easier to do the right thing and obtain the software by legal means. As I said above, I prefer to duck the question and leave the debate to the integrator and end user.

WINZIP must use a simple password algorithm. What ever happened to 128 bit encryption?

Hi all

I used to work for Siemens and we had a standard to use the contract number as the password.

It is a good idea because everyone eventually knew the password but again it just kills the flavor of protecting your own work….

So the choice is yours to protect your effort or your company business.


Hani .... bonkhead

I will make this reply as an end user

Passwords are a PITA

This said though I know they are necessary, companies make money by building machines AND servicing them (a car is a machine). The program/code/devolopment time was theirs and deserve the consideration for this. They cant afford for someone to buy/rebuild one machine and then someone duplicate it.

At times though they are used maliciously and improperly. Our main plant contracted with a programmer to program a machine they rebuilt...ie bought his services. The programmer passworded it and refuses to give them password or program...its his. They arent willing at this time to make it a court issue because it wasnt included in contract (nor excluded..ie nothing states he owns..just a contract for services).

What will happen eventually is I will go there and spend time to bypass the password and retrieve the program/code then reverse engineer it...personally for this machine I would like just as well write the code myself and clear the plc and reload.

Is an issue that has many sides and it is hard to say when/if they should be used...and if there should be backdoors. Thing is there will always be backdoors as long as there is a need.

This thread has opened my eyes.

I searched the internet for software that can unlock password protected zip files. I thought it would be hard to find, but I am wrong. THERE IS NO SECURITY IN PASSWORD PROTECTED ZIP FILES!

For now I will use PGP until I figure out what DES3 encryption is all about and implement it.

I have spent a couple hours studying cryptology since this post. I now know what is necessary to make something really secure. In the future I bet that even 128 bit encoding will be easy to break.

I thank you Steve Bailey for opening by eyes. Good topic.

We sell systems with proprietary algorithms. I don't use passwords on the logic. If someone is going to go to the trouble of reverse engineering my system from un-documented ladder logic, then they are going to break my password too. We do provide documented code to our customers on request, with the only requirement that someone in authority at the customer's facility sign a single system licensing agreement before we send it out. It is certainly possible for them to cheat us, but most people are honest and life is too short to waste worrying about the guys that are going to screw you anyway.

Part of the licensing agreement is that my company is not responsible for maintaining or restoring the software if any changes are made by the customer, and we aren't responsible for anything once the warranty period is over. So far (16 years) this has served me well.

Customers occasionally want passwords on the operator interfaces to prevent un-wanted tuning. I try to discourage this. The password usually ends up taped to the wall next to the panel anyway because somebody has trouble remembering it.

As with nearly all topics these days, they have had an airing before. This was done a long time ago, but for recent newcomers it is a valid subject.

I seem to remember last time that it also veered off to ‘time bombing’ code as well. Remember time bombs?

I admitted that I had not only password protected programs but time bombed them as well.

The reason at the time was;
password protect because I had had programs stolen and used.
Not even by a plc programmer but the management.
They got hold of the programming software and cables and learned to upload and download, no more than that.
At the time I had a contract with them to licence each new machine, they cut me out.

Another occasion at another company, I actually caught someone uploading my program for themselves. They were a supplier to this company and supplied many other similar rival companies. He was taking this program to sell to the other companies.

I use mainly Mitsubishi PLC’s and you can download all the comments and statements with the code. Anyone uploading the code has the full program, fully commented and statement-ed. It doesn’t come much easier than that

I have time bombed in the past because of bad payment. There is nothing like a dead machine to make the customer remember to write that cheque he owes you.

I know these scenarios are rare but they happened to me. I also know that ladder is not rocket science. But as said before algorithms are the things you want to protect.

Specific to my Company's product line, I think A-B didn't put a backdoor password into the MicroLogix family for three reasons:

1. Enough hassle already with the other product families. Some OEMs want intellectual property protection, and they should have it. Some plant managers don't want equipment changed without authorization, and they should have that too. Some programmers think they should have access to change whatever they want when they want. They can go spin.

2. Safety standards / Liability. A-B sells clutch-brake control systems based on the MicroLogix 1500 (wired redunant, even !). Even if such a system was edited by Einstein himself, the fact that it was able to be edited makes it theoretically unsafe, and therefore unable to be used for a machine safety application.

3. Price. The MicroLogix cannot handle colossal systems, so the real economic damage that a forgotten password can do is *relatively* small.

I believe that our original querent krunalc was earnest and honest, but I have been told the "programmer is out of business / dead / missing / fired / a jerk" story dozens of times. Twice it was true.

The ControlLogix system has some nifty security; individual routine protection, and an unbreakable OEM lock. I haven't gotten it's firmware authors drunk enough to find out if there's a memory probe that can unlock it, though. There's always Automation Fair !

Ken-
Just out of curiousity, How do you set up passwords in Logix5000?

Your comment earlier made me curious, so I checked it out.....I couldn't find passwords, protection or anything of the sort.

We go one step beyond (some might consider it a step back) what the other PLC manufacturers do. We only download one file to the controller - the compiled file. No ladder file exists in the controller, so there is no need for a password.

As an OEM based product, we give complete control of the intellectual property (the program) to the company that designed the machine. They have the final say in who gets the program.

For those that are curious, the compiling is done through the software and a .hex file is created and downloaded.

The one drawback is to the customer that has the machine, and the company that originally designed it is now out of business.

God Bless,

Stephen Luft