Information Security of Java and NET - Research Proposal Example

Java and .NET Introduction Security is a very important theme in today’s world when it comes to computers, information technology and programming languages (Berman, 2002). However, security has to be tempered with ease of use as well as the functionality which is present in any solution. In certain situations, focusing on security may even lead to a decrease in usability as early adaptors of Vista found out to their disadvantage. The operating system made security such an important concern for itself that it became cumbersome for many without disabling the security features which made it so secure in the first place (LaGesse, 2007). Luckily, when it comes to programming languages, security does not seem to be a paramount concern because Java and .NET both have a firm grip on the security features that are needed by programmers (Schwarz, 2006). However, one of them is likely to be better than the other when it comes to the overall picture with regard to security and there are several aspects of security on which these languages can be compared. These aspects include user authentication and authorization, security configurations, cryptography support, and the protection of code created by the programmer. To fully understand the relationship these languages have with security issues, it would be ideal to examine the issues one at a time. User Authentication As discussed by Piliptchouk (2004) user authentication should be based on a strong foundation which comes from the operating system itself. Authentication itself is defined as the ability of a software to determine if the person using the software is the exact person s/he claims to be. Financial intuitions might be particularly concerned with the authentication process both for their clients and their employees as well (Feig, 2005). The authentication process is followed by the authorization process which creates a roles based level of security where system administrators are allowed to select what users can and cannot do within the system (Paul and Evans, 2004). The web based solution for .NET includes ASP.NET which is used in conjunction with the Internet Information Server on windows to process HTTP requests initiated by a client. While IIS is the default for windows, it is also possible to ASP.NET to other web servers. As a possible threat to security, process isolation is not really a strong consideration for .NET and all managed code is executed locally. Even though ASP.NET and IIS have different security settings, the use of ASP.NET through IIS for some types of authentication might make ASP.NET vulnerable to the same security flaws as IIS (Piliptchouk, 2004). However, ASP.NET remains quite easy to use for programmers since it has authentication modules which increase in number as the number of authentication types increase. These are used to handle authentication events and can even be used to create customized authentication schemas through account mapping and the creation of new principal users. On the other hand, Java gives users two methods for authentication to a server which are, JAAS and Java servlets (Piliptchouk, 2004). Servlets are the HTTP oriented server layer tools which are designed specially to handle web based software. On the other hand, JAAS can be used with any application which uses Java including Java applets which run on the web. JAAS is based on an API therefore it is not dependent on underlying mechanisms which also adds to the security features of Java (Piliptchouk, 2004). Essentially, Java is able to separate the authentication code from the application code and this gives a Java application the additional advantage of completely changing or even obtaining a new authentication system without changing the application code itself (Paul and Evans, 2004). Like the application code, the abilities given to users as well as their credentials have to be stored in some location and both Java and .NET permit multiple methods of storing these credentials. In fact, improper security or storage of these credentials may result in more security threats or security breakdowns than the issues with the languages themselves (Piliptchouk, 2004). For example, storing passwords without encryption, or without using a properly configured and secures host could be more dangerous than anything else (Schwarz, 2006). When it comes to ASP. NET, programmers have three options with regard to storing user credentials. The first is the ISS for window’s accounts which uses Active Directory Services. The second is using a passport account for which credentials are verified by Microsoft (Paul and Evans, 2004). Finally, the easiest to use and perhaps the least secure method of authentication is placing data within the application’s configuration file. With this method, all that the programmer has to do is to define the username and the password within the credentials section of the application (Piliptchouk, 2004). Java does not define any preset methods for accounts storage but can use mediators which allow it to use directory services and other custom data storage solutions for authentication. When users have logged in, Java creates a session on the server which is based on when the user logs in through an application. After a certain period of inactivity, the session is terminated and the user has to be authenticated again. This feature can be given a preset time limit or disabled all together depending on the needs of the programmer or the requirements of the application itself (Piliptchouk, 2004). Java Wins While it may seem that both languages are more or less equal when it comes to authentication, authorization is a different matter altogether. The flexibility offered by Java with regard to setting parameters for individual users are much better for programmers than setting policies for groups of users (Trevor et. al. 2007). Further, the integration with IIS for .NET may make the programming process simpler but this makes .NET suffer when it comes to creating robust security features (Paul and Evans, 2004). The JAAS features in Java make security, authentication as well as authorization powerful realities which .NET does not have to an equal level (Piliptchouk, 2004). While Java wins in this regard, the protection of the code written by the programmer presents a different picture altogether. Code Protection While some such as Dahl (2005) may suggest that alternatives to windows and the .NET environment are better than windows in all respects, others such as Piliptchouk (2004) show that when it comes to code protection, the .NET environment has a lot of advantages over Java. Code protection is critically important for programmers for a variety of reasons and the first of these is information security. Code may contain the names of fields and tables; the actual procedures used for verification and even encrypted keys which could provide hacking hints to those who would chose to use them. More importantly, programming code is a form of intellectual property which belongs to a company or an individual that may want to jealously protect its intellectual property rights (Piliptchouk, 2004). As such, code can be viewed as a company asset which needs protection from being copied or examined by unauthorized individuals (Feig, 2005). However, as with the protection criteria for user authentication, the underlying mechanisms such as the operating system can also be a threat or a help for the protection of programming code. Undoubtedly, there are tools available to reverse engineer applications which have been distributed without protection. Bytecode formats for both languages are commonly available as are decompiling programs. In fact, it would be considered as a critical security flaw if user credentials or other such sensitive information is hardcoded into a piece of software (Paul and Evans, 2004). However, as there are Bytecode decompilers, there are software tools for both Java and .NET which allow the languages to get a certain level of protection. These tools are called obfuscators and one such obfuscator is built into Microsoft’s Visual Studio. For Java, many such tools are freely available on the internet (Piliptchouk, 2004). For both languages, code is protected firstly through the use of certifications. For a .NET solution, the certificate relies on Windows and its associated certificate management systems which have developed to a strong point (Paul and Evans, 2004). Java uses Keystores for managing certifications which may have different formats depending on the vendors. While managing certificates in both languages is almost as easy, .NET appears to have more robust system for dealing with certificates as compared to Java (Piliptchouk, 2004). These certificates can be used to authenticate the source of a piece of code as well as other related information and once the integrity of a program has been established, others means may need to be used to protect the code itself. Fundamentally, this means that the packages in the program or the class protection tools should not be compromised by joining with other packages or through the process of derivation. To prevent unauthorized exposure of code, .NET uses probing algorithms at the time of code execution to locate assemblies. Further, data types are ordered into namespaces which may themselves be sealed from others to prevent inheritance from that class (Piliptchouk, 2004). With Java, the execution of an application uses class loaders which verify that the class is not in violation of any policy of the application itself. However, .NET goes one step further in terms of protecting code with C# and may even restrict how a debugger handles code and may not allow the complier to give much information about protected areas even if they are found by a complier to have bugs within them (Piliptchouk, 2004). .NET Wins While in most cases, tight integration with the Windows operating system may lead .NET to lose in a direct comparison to other development environments (Dahl, 2005). In the case of code protection and source code security, .NET turns out to be the winner. In the final evaluation concerning code protection, it is possible to say that both platforms offer the same type of features but when it comes to Code Access Security, the features present in the .NET environment are much better than Java’s (Piliptchouk, 2004). Even though Java may have a higher level of flexibility, the sheer number of features for .NET make it a winner. Cryptography The distribution and the release of code from one party to another depends on cryptography and the idea of how well managed the cryptography of an environment is. In fact, this measure can affect many other aspects of security for a given environment since cryptographic subroutines may be called into play in several different situations where programs needs to receive or transmit sensitive data. Even backup data needs to be encrypted when it is stored for any significant period of time without strong supervision (Lucas, 2004). For the enterprise market, cryptography becomes even more important since even application level data may need to be encrypted except when it is being used by an individual (Schwarz, 2006). To protect data of a sensitive nature, programs use encryption tools defined by the language they are created in. For a .NET solution, cryptography is based on the Windows Cryptography service which also uses key containers to decrypt data which has been encrypted. The solution in .NET for cryptography allows the programmer to configure it in a variety of ways while allowing the addition of custom algorithms for encryption. More importantly, .NET uses a stream model along with the strongest possible settings as defaults for encrypting data that has been deemed as sensitive (Piliptchouk, 2004). Java’s cryptographic abilities are divided into two elements which include JCA (Java Cryptography Architecture) and JCE (Java Cryptography Extension). These are packages which are composed of frameworks that form the basis of encryption for Java. The algorithms used for encryption itself come from other providers since JCE and JCA are internal packages which cannot be bypassed through software. Trusted authorities such as SUN and IBM create encryption algorithms that encrypt and decrypt the data but the signing process itself may be cumbersome for the average developer (Piliptchouk, 2004). Regardless of the operating system, SSL has become the norm for transporting data from one point to another and both Java and .NET use SSL as a transport mechanism for secure data. Since SSL allows for both the client and the server to be authenticated, .NET has to go through the ISS for configuring and dealing with SSL which means that internet traffic may be secured internally through SSL while other forms of data transfer need third party support. Fixes and patches as well as updates from Microsoft have alleviated the problem to a large extend but it seems like quite an oversight to keep it out of the first version of the .NET framework developed by the company (Piliptchouk, 2004). Java offers JSSE (Java Secure Socket Extensions) which work as platform level extension to handle internet traffic in a secure manner while servlets specifications create options for handling SSL protection and also disallow unauthorized connection attempts (Paul and Evans, 2004). While this exceeds .NET’s ability for handling SSL and allows for various forms of traffic to go through on the secure layer without any third party support, both platforms have come to a point of parity with regard to transmitting and receiving data in a secure manner (Piliptchouk, 2004). Application level protection and cryptology also exists in the real world which is separate and distinct from the transmission protocols. This approach may be considered to be smarter that blanket encryption since it protects only sensitive data as defined by the programmers. For example the login and password information on an IM session could be encrypted while the messages themselves may not be. In some situations, this may lead to more optimized data transfer and faster connections. Java uses GSSAPI, which may be found on the application level to give token-based encrypted connections. Java manages to this offer both a platform level encryption and a transport level encryption even though the security objectives of both encryption methods are essentially the same i.e. secure authentication and the protection of data going from one end to the other (Piliptchouk, 2004). Encryption for web services is offered as WSA (Web Services Architecture) by Microsoft but as an element to counter the lack of other encryption services which are dependent on the ISS. While it can be disadvantage when it comes to user authentication, with regard to encryption, it is a blessing. The extensible architecture of the .NET platform has permitted the development of several approaches to transporting data in a secure manner (Piliptchouk, 2004). These approaches are not that firmly grounded in Java since their standardization and further development needs to be completed and third party support for these offerings is still limited. .NET Wins Even though cryptography features are more or less evenly distributed on both the platforms, third party support and ease of use allows .NET to edge ahead. The solutions offered by Java are more complicated but Java does fair better when a choice needs to be made between platform level and application level encryption. However, the web services support of .NET gives it the grounding it needs to become a better candidate where cryptography is concerned as far as transmitting data is concerned (Piliptchouk, 2004). Security Configurations Security and the related configurations for both Java and .NET and simply handled with XML which can be governed through a GUI. With .NET, the GUI can be used to adjust all security configurations much as the GUI tool supplied with Java. However, the java environment allows programmers to set both the code and agent based security settings. Further, in .NET the names and the particular places where the files are stored have to be fixed in order for them to work properly. .NET also creates machine based and application based security related configuration files while allowing for the creation of company wide security policies (Piliptchouk, 2004). Company wide security policies may help in handling issues which come up when individual users decide to change their policies to make life easier for themselves such as by turning off their local firewalls (Scheraga, 2005). The resulting security policy gives the users the rights and authorities to use with the programs developed on the .NET platform. Of course this also means that windows can create severe conflicts when multiple security policies need to be created for various .NET programs. Security configuration files which are in conflict with each other may cause programs to behave erratically when trust zones overlap or when frameworks trusted by one program are set to be without trust by others (Piliptchouk, 2004). Java Wins The configurability of security has Java as the clear winner since the .NET environment can lead to conflicts if programmers or the users are not careful with their settings. However, the configurability of the .NET environment means that programs can easily be run on their own virtual machines within a given system and initiating as well as working within this virtual space is slightly easier as compared to Java (Piliptchouk, 2004). Nevertheless, the risks of having multiple policies may make Java a better choice when configurability is the most important security concern. Conclusion Both platforms and development environments offer their advantages and disadvantages to users as well as programmers and it remains up to the individual programmer or the company itself to select one or the other. In essence, the needs of the software and the demands of the project should dictate which environment is used. If security configurability and user authentication is the prime concern for the developers then Java is the best option. On the other hand, if cryptography and code protection are the most important concerns then the .NET environment is better. Undoubtedly, neither of the platforms performs poorly when it comes to security since that appears to have been quite high on the agenda of the people who developed these environments in the first place. Word Count: 3,128 Works Cited Berman, A. 2002, ‘Lessons Learned: The Aftermath of September 11’, Information Systems Security, vol. 11, no. 2, pp. 30-31, Dahl, E. 2005, ‘The Truth About Windows Alternatives’, PC World, vol. 23, no. 9, pp. 75-82. Feig, N. 2005, ‘Those Responsible for Data Breaches Should Bear The Costs’, Community Banker, vol. 14, no. 12, pp. 12-13. LaGesse, D. 2007, ‘Tech to Ride an Upgrade Cycle’, US News and World Report, vol. 142, no. 2, p. 9-10. Lucas, M. 2004, ‘One Year Later, IT Prepares for Next Disaster’. Computer world, vol. 38, no. 31, pp. 1-12. Paul, N. and Evans, D. 2004, ‘.NET Security: Lessons Learned and Missed from Java’, University of Virginia, [Online] Available at: http://www.cs.virginia.edu/papers/acsac-net-java.pdf Piliptchouk, D. 2004, Java vs. .NET Security, O’Riley. Scheraga, D. 2005, ‘Firewalls Are Not Enough’, Chain Store Age, vol. 81, no. 12, pp. 83-86. Schwarz, E. 2006, ‘Safeguarding Your Data’. Chain Store Age, vol. 82, no. 1, pp. 16-17. Trevor, J. et. al. 2007, ‘Defeating Script Injection Attacks with Browser Enforced Embedded Policies’, WWW2007, [Online] Available at: http://www2007.org/papers/paper595.pdf Read More