|
Hello Community,
i am actually getting desperate with this... i have developed a nice User-SelfService Site where user can modify some settings and also change their own password.
Unfortunatly now it should run against a Novell eDirectory also instead of AD only.
I did some research and from my understanding the easyest way would be to execute an LDAPMODIFY command but unfortunatly i can not find the LDAP Tools for windows (it looks, that they only exist for Linux  )
At the Time when the password of a user has to be changed, we have the current password, the whole Path of the Users Object in eDir and also an Proxyaccount that is permitted to reset users passwords.
Did anyone have expiriance with LDAPMODIFY or Change Password on eDir?
Yor help would be really appreciated.
Thank you
Martin
|
|
|
|
|
I have created a application in .Net for remote desktop connection and it is working fast and secure also, but for some reason i am not satisfied with the User Interface so just decided to rewrite the code again from the beginning. 
But the problem came with the security from the hacker,cracker. yeah i know that .Net app can be easily de compiled so obstruced the code and declared all the class as not inheritable
so that they can't import the app and create a object for the some important class and understand the algorithm or working behind it.
Is there any other thing i am missing 
Can give any suggestion for the UI or features.
One More Question: Should i kill features for the shake of UI.(i think i should kill features).
|
|
|
|
|
kburman6 wrote: i am not satisfied with the User Interface so just decided to rewrite the code again from the beginning.
You're building a new house, because you did not like the way the old one is painted? 
kburman6 wrote: But the problem came with the security from the hacker,cracker. yeah i know that .Net app can be easily de compiled so obstruced the code and declared all the class as not inheritable
"NotInheritable" is meant as a code-construction that helps during development, not as a means to stop hackers. Open up ILSpy, load your assembly, copy and paste.
kburman6 wrote: One More Question: Should i kill features for the shake of UI.(i think i should kill features).
Dunno, how many have you got? How many would your users want?
If the app is becoming too complex for the average user, then hide some of the features under an "Advanced" tab or button.
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
|
|
|
|
|
Eddy Vluggen wrote:
You're building a new house, because you did not like the way the old one is painted?
Actually, the house has wrong things in wrong places which could not be done by just shifting the rooms.
Eddy Vluggen wrote:
"NotInheritable" is meant as a code-construction that helps during development, not as a means to stop hackers. Open up ILSpy, load your assembly, copy and paste
I have put a method
verify(apikey,secret)
with which you can activate every class and without it nothing will work.
It may be seen as constructor method.
Eddy Vluggen wrote:
Dunno, how many have you got? How many would your users want?
If the app is becoming too complex for the average user, then hide some of the features under an "Advanced" tab or button.
Hmm, that is good point 
|
|
|
|
|
kburman6 wrote: compiled so obstruced the code and declared all the class as not inheritable
You can always obfuscate your code by using an Obfuscator tool.
This will help reduce the risk of someone decompiling your code.
|
|
|
|
|
Thanks
But little bit scared because Obfuscator only change the names of methods,class,var to some random name.Means still can be decompiled and a very curious person can understand it.
And one more thing
Dim password as String ="sometxt"
sometxt can still be seen in memory dump of process is there any way to hide.
|
|
|
|
|
kburman6 wrote: But little bit scared because Obfuscator only...
There is no way to absolutely protect software that runs on a client device.
|
|
|
|
|
Nothing can protect you completely and even obfuscated code can be decompiled.
It is harder to do so though.
|
|
|
|
|
This is like locking the door to your house. Does it prevent somebody from knocking the door down with a bulldozer? No. It prevents them from getting EASY access to your house. A determined hacker can always crack your code - any code that can be run on the machine can be decompiled. You can encrypt your application, but the way that works is only the EXE file is encrypted - when the code is loaded into memory, it's decrypted and therefore understandable.
Your goal is to make it *not worth my time* to try to decompile your application. You need to make it so the official licensed version of your application is easier to get than the cracked version. Like locking the door to the house - you're not going to make it impossible to crack, just make it so difficult that it's easier to get the legit version. That way the only ones who will crack your app are the people who do that kind of thing for fun, and it won't hurt your app sales. Does anybody download the cracked Angry Birds? NO, because the licensed version is free.
|
|
|
|
|
Jasmine2501 wrote: official licensed version of your application is easier to get than the cracked version.
you are right.why don't i thought like that.
|
|
|
|
|
You are learning. We all have to learn these things. Someone told me many years ago, and I told you today. Isn't it wonderful to be a human being?
|
|
|
|
|
Hi,
First of all, I do not know if this is the correct forum. If not, please re-direct me.
I am re-designing a successfull application for XP to run under Win7 and 8. The previous incarnation runs under XP. The application at hand is a Cash Register/Production Application, not at all connected to the internet, just to a small local network. the general requirement is that a User signs in to an app running on a terminal, in order to register a fact of production, or a transaction with a customer. Any Opening,reading Writing or Closing happens under Program Control.
Under XP all machines run in non password Admin Mode. I see nothing wrong with it, but microsoft considers it a bad idea. (conversely, weare not aware of even one security related issue over the past 7 year).
I cannot think of even One feature of the 'Windows Development Cycle since 'windows XP' that has benefitted me.
The Read/Write/Modify set of permissions do not realy cut it. An employee must perform a transaction on the till, which requires a right to modify the Till Contents. he is however not allowed to do that at will. (Set the Contents to Zero, bring the takings home, and claim 'No Trade' for that day)
'Switch User' is definitely not a way to go. It is too slow, and All Users have to start from the same screen anyways.
The Microsoft model seems to be based on the 'country hopping traveling sales man', and the sharing of a computer between different people doing different things, like writing letters or spreadsheets, stored on the company server. The precursor to Azure(which I will NEVER assign my customers to)
In my application Internet security requirements are non existent.
I am now preparing a new design using the NET Framework.
I do not use any significant graphics, (other than Diaolg Boxes) DB Acces attempts account to about 1000 per week. on average over each of my users.
Anyone who can help?
Regards
Bram van Kampen
|
|
|
|
|
Bram van Kampen wrote: I am re-designing a successfull application for XP to run under Win7 and 8
Presumably based on business reasons.
Bram van Kampen wrote: 'Switch User' is definitely not a way to go.
If you want the terminal to act like a kiosk then research techniques for doing exactly that.
Other than that the app, not the OS, should control acccess to business functionality.
|
|
|
|
|
Well,
Your remark sounds sarcastic.
We aim just at the oposite. Version 2.00 was written in MFC 42,
the Re-Design affords that Version 3.00 will be written in C#. Virtually Nothing written in MFC/CPP will translate line by line to V3.00 code. We hope for a smooth technology change, with minimum Interface change.
In your argument, what is a Kiosk, and how does it exist under windows security.
Bram
Bram van Kampen
|
|
|
|
|
A Kiosk is a physical thing - A small structure, often open on one or more sides, used as a newsstand or booth. Sometimes a kiosk is running computer software, such as navigation maps at a large park or mall, or to apply for a job at Wal-Mart. They have unique security concerns because anyone can walk up and interact with the machine. It is not a technology.
I don't think his comment is sarcasm. I think you're skipping the first step of application design - asking yourself what really needs to be done, from a requirements perspective. For example, you say the new application is built in C# - WHY? Did you examine the requirements and the proposed architecture and conclude that C# is the best language to build this app with? OR, do you have a company policy that all new development will be in C#? Have you determined that maintaining the current app is not cost-effective? It sounds like you've decided to re-build this app in C# for no compelling reason at all.
|
|
|
|
|
The concept you need to implement is called "roles" and it's pretty much the way security is done these days in most places. You create roles, like "cashier" or "shift manager" or "store manager" and you assign specific permissions to those roles - you never assign permissions directly to a user. When you add roles to a user, it determines what is available for them in the app. Due to your requirement that "switch user" will not be used, you can not use Windows Active Directory roles, which is a VERY secure way of doing this. You will have to roll your own (couldn't resist) roles system.
|
|
|
|
|
I understand that when you install the .NET framework, having copied all the assemblies into the Global Assembly Cache, they are then NGENed into native code. This is why it takes a while.
This makes a lot of sense, so I've never understood why the architects of .NET didn't provide support like this for our applications. On some of the larger systems I work on they are noticably sluggish when they start up and I experimented once, signing and putting the assemblies into the GAC, then NGENing them and they were considerably faster on start up.
So why not have a system whereby the first time you run an application the native image that is created (albeit on a line by line basis) is cached somewhere with a link to the original assembly? I appreciate that somethings couldn't be done like this (stuff from emit for instance) but the vast majority of the time JITting is something which really doesn't have to happen every time an application is run.
Anyone got any thoughts on this matter?
Regards,
Rob Philpott.
|
|
|
|
|
If you wanted to, you could do this yourself by running ngen.exe.
|
|
|
|
|
Yes, but that would require sticking your application in the GAC which is hardly appropriate.
Regards,
Rob Philpott.
|
|
|
|
|
I'm pretty sure it doesn't Rob, unless things have significantly changed since this[^].
|
|
|
|
|
Maybe I've remembered it wrong. Will investigate.
Regards,
Rob Philpott.
|
|
|
|
|
Let me know what you find. I've never tried to do this myself, so I'm working on the "in theory there's no reason why not" approach.
|
|
|
|
|
Yes, seems I was off on one. Reading around, if you've given your assemblies a strong name then you get little performance from NGENing them unless they are in the GAC due to some validation which is done, but its absolutely not compulsory.
So I took one of my dumb console apps which does something and just tried to NGEN it and it didn't complain.
Coming back to the original point. If you're going to design a system with an intermediate language and CLR and all that, I still would have thought that building a standard way whereby the assemblies get Jitted just once would be in the list of original requirements. Computers rarely change their instruction sets, so why just keep doing it over and over again?
There are lots of whys like that in this field...
Regards,
Rob Philpott.
|
|
|
|
|
The implication there is that all the code has been JITted. Depending on application complexity, it's entirely possible that you only follow certain paths through the code on certain runs - thus causing problems if you were to just emit the ngen of the single pass. You could only really do this if all paths were hit during the process - otherwise there's no real need for you JITting and you could just ngen up front.
|
|
|
|
|
Rob Philpott wrote: I experimented once, signing and putting the assemblies into the GAC, then
NGENing them and they were considerably faster on start up.
Because for most systems what the code does on start up is vastly more significant.
Rob Philpott wrote: is cached somewhere with a link to the original assembly?
Sounds like a security hole just waiting to be exploited.
Precompilation caching would need to be done by using a signature/hash which would then be compared to the existing cached entity. That with the name would provide the link.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
