Also, it would be very useful to be able to set passwords for multiple userobjects at once…
Actually, since the passwords are so easily cracked, we probably won’t be adding this feature at all to GH2. All it really does is give people a false sense of security.
That doesn’t sound so good. Wouldn’t it be better to make them uncrackable?
by a 0.01% of GH users or less maybe…
a note warning that security is not guaranteed is not enough?
You know if you don’t include it you force third-party developers to try to add it, right? 
Even if it’s crackable, I’d like to be able to choose whether to use it.
1 Like
Unfortunately that is not mathematically possible. Anything which must run all by itself must be loadable without passwords, and as such is vulnerable.
It only takes one person to write a C# script that cracks them (and they have, and they are available online).
“Dear user, feel free to assign a password, not that it in any way protects you, but go ahead, waste your time.”
The fact is that when you provide protection, people assume it’s good, no matter how calmly you try to point out all the massive holes.
And they can’t do it either. What they can do is include licensing (which is not a service we provide anyway) or obfuscate their assemblies (which they’re doing anyway and this stuff is responsible for 90% of fatal crashes in GH).
I just don’t want to be the person who sells you a shiny second hand automobile which falls apart two days later.
3 Likes
A marketplace for userobjects would really bring things to the next level. Sketchup has the warehouse and Dynamo has the library of packages. And, by the way, I really like how the Online Package Search is done in Dynamo, and the process of installing and uninstalling a package( so similar to Atom actually).
But without password protected userobjects I don’t really see how this can happen.
Publish something in a blog does not launch notifications on all computers… If it was as massive the software industry would not work.
Everyone knows that 100% security is impossible to guarantee. For me, it is not a waste of time to put a password to a cluster that I give to a client, for me it is to protect my work. Although it is crackeable, it is most likely that he/she does not even think about that can be cracked. Although 50% are capable, I get no charge for access to the other half. Without a password I have to add the price of a tool + can modify the tool.
I bet you a beer that someone will develop an equally or less unsafe way to protect a cluster. Although it’s a shabby way, like paint the canvas and ModifiersEnabled = false 
I understand and respect your opinion. Have you received complaints about the vulnerability of the clusters? Because you will surely receive them for removing the password protection 
We’re working on YAK as a package manager for Rhino6 and beyond.
Then it doesn’t happen because it is not possible to password protect .NET code which must be executed without a password. You can always hack into the assembly either before or after loading using either Cecil or Reflection and just get the data out.
You can only password protect data if it’s wholly hosted on a server (until Russian hackers pwn your web-app that is) or if it’s encrypted using the password. Then, before you can use that data the user has to enter the password, and after that the data isn’t password protected any more.
But there’s a difference between “it’ll take the NSA about 3 days of server time to crack the encryption of this email” and “download this C# component to automatically remove the passwords from all your clusters”.
@piac seemed to have some ideas on obfuscation, but to be honest it went a bit over my head and I didn’t really understand what it would take to implement them. But obfuscation isn’t the same as encryption.
What we can do is encrypt files, but I don’t think that actually solves any problems people are having.
I can’t stop people from doing stupid things, all I can hope to do is be less stupid myself.
Yes, some of them from fairly shocked and angry people.
encryption doesn’t help. The idea behind most password hacks is by bypassing password checks or by replacing passwords with known passwords. As long as reflection works, you can replace any member, no matter if marked as private or internal. Working with raw pointers you can also inject dlls and replace method as an alternative. There are tons of possibilities, and zero protection. That’s the drawback of c# and intermediated language. In the end it took me less then ten lines of code, and without using any additional tools.
So there is no protection against it, although dani is right as well. With passwords you stop at least most gh users. Its however just a matter of time until someone provides a method in the internet. So it might be a good idea to keep this feature, but explicitly mark it as insecure.
Another aspect. Everytime you download a plugin or a pw protected cluster you do something very risky. Its very easy to hide malware inside. So actually true open source like ladybug is the most secure approach.
But you know, I do obfuscate as well, because I don’t want others to simply copy and paste my intellectual property. Its a very difficult topic, and I don’t know a good solution to this problem. I like to make it as hard as possible.