while equivalent for loop

Today while doing some programming stuff I found one good thing which I never encountered in the past for programming language loops. I know everyone who has done programming used for and while loop some time or the other.

In this post I am just going to give simple example to convert a for loop into while.

For loop

for(Initialization;Condition;INCREMENT/DECREMENT)
{

statements;
}

While equivalent

Initialization
while(Condition)
{
statements;
INCREMENT/DECREMENT

}


example:
int i =0
for(System.out.println("initialization");i <10;System.out.println("increment/decrement"))
{

System.out.println("Inside loop");
}

equivalent while loop:


int i =0;
System.out.println("initialization");
while(i<10)
{

System.out.println("Inside loop");

System.out.println("increment/decrement"); // this should be the last statement in the loop
}

How to get the oracle version

Some times we comes across in the situation where we have to find which version of Oracle is running. Here is a simple query which you can run to find the exact oracle verison

SELECT * FROM V$VERSION

I had a strange scenario where I had to connect to different version of oracle instances from a single Web app. Below oracle site helps finding the driver which can match those versions driver requirements.

http://www.oracle.com/technology/tech/java/sqlj_jdbc/htdocs/jdbc_faq.htm#02_02

How Java Cryptography Extension works - Password Based encryption Concept

In my last post I discussed about the basic API's to be used for encrypting and decrypting the data. For encrypting/decrypting data you need to have a key, in that case key needs to be stored in the system. In the password based encryption you provide the key at the encryption/decryption time manually because you remeber the key. The more complicated the password is more powerful the encryption will be. It can not be as strong against the attack as the one we generate using the API's but it can be good for encrypting data which you are going to decrypt at other end since you know the password.




Note: Password is first hashed to be used as a key not directly used as a plain text.







Ex: Key generated by API for 3DES encryption will have 2^168 many possibilities. While a normal person password length is 6-8 characters which comes to 26^6 or 26^8. I have taken 26 because there are 26 characters in the english alphabet, if you add numbers and special character it will be little higher but still no where close to the key generated by API.

To overcome the problem I mentioned above there are options to increase the security of the password based key

1) Salt: This is the extra random bits added to the password for generating key to encrypt/decrypt the data. These random bits are appended (base64 encoded) with the encrypted data in plain text so it can be used again for decryption. Each time data is encrypted new Salt is added for flavour.



2) Iteration Count
The iteration count is an attempt to increase the time that an attacker will have to spend to test possible passwords. If we have an iteration count of a thousand, we need to hash the password a thousand times, which is a thousand times more computationally expensive than doing it just once. So now our attacker will have to spend 1000 times more computational resources to crack our password-based encryption.



BASE64 Encoding


Binary data is typically stored in bytes of 8-bits. Standard ASCII is only 7 bits though, so if we want to display binary as ASCII, we're going to lose at least one bit per byte. BASE64 encoding is a way of overcoming this problem. 8-bit bytes are converted to 6-bit chunks and then into characters. Six bits are used so that some control characters can be used indicating when the data ends. The encoded characters can then be displayed on the screen and converted back into binary with no difficulty. Of course, since we're moving from an 8-bit chunk to a 6-bit chunk, we're going to have more chunks - 3 bytes becomes 4 characters and vice-versa.





Encryption using PBE

Decryption using PBE

I will give the example of PBE in another post.

I took part of the information in this post from http://javaboutique.internet.com/resources/books/JavaSec/javasec2_2.html

How Java Cryptography Extension works - Encryption and Decryption???

Java Cryptographic Extension is a very huge topic and I am not going to write a complete book here which makes my life miserable and readers also get bored reading chapters after chapters. In this post I am going to just discuss how Encryption and Decryption works using JCE API's and then give one working example. I will post other JCE features in coming posts.

Symmetric encryption

I know most of you are aware of how symmetric encryption works and what are the benifits/downsides of this but for whom this is a new topic it's my responsibility to give little bit of idea. This encryption method has a key which is shared by both parties (Encryper and Decryptor). It is much much faster compare to assymmetric encryption but exchanging key between both the parties is a complex task. This is used where bulk of data needs to be encrypted and decrypted. Even where ever assymmetric encryption is involved it is used for actual data encryption because assymmetric also is used to exchange symmetric key between parties. ( Please refer to my post How SSL works) .

I don't want to take more of your precious time and get back to real business here

Main cryptography classes used in this article comes from javax.crypto.* package.

Most of the classes in the JCE use factory methods instead of new operator for creating class.
Cipher class is the engine of the car and following are 4 wheels on which you can enjoy the ride on the car.

Wheel 1 : getInstance()

Make a call to the class's getInstance() method, with the name of the algorithm and some additional parameters like so:

Cipher cipher = Cipher.getInstance("DESede/ECB/PKCS5Padding");

The first parameter is the name of the algorithm, in this case, "DESede". The second is the mode the cipher should use, "ECB", which stands for Electronic Code Book. The third parameter is the padding, specified with "PKCS5Padding". In case second and third parameters are not mentioned they will be taken as per the JCE provider specification.

Wheel 2 : init()

Once an instance of Cipher is obtained, it must be initialized with the init() method. This declares the operating mode, which should be either ENCRYPT_MODE or DECRYPT_MODE, WRAP_MODE, UNWRAP_MODE and also passes the cipher a key (java.security.Key, described later). Assuming we had a key declared, initialized, and stored in the variable myKey, we could initialize a cipher for encryption with the following line of code:

cipher.init(Cipher.ENCRYPT_MODE, myKey);


Wheel 3 : update()

In order to actually encrypt or decrypt anything, we need to pass it to the cipher in the form of a byte array. If the data is in the form of anything other than a byte array, it needs to be converted. If we have a string called encryptme and we want to encrypt it with the cipher we've initialized above, we can do so with the following two lines of code:

byte[] plaintext = encryptme.getBytes("UTF8");
byte[] ciphertext = cipher.update(plaintext);

Ciphers typically buffer their output. If the input is large enough that it produces some ciphertext, it will be returned as a byte array. If the buffer has not been filled, then null will be returned. Note that in order to get bytes from a string, we should specify the encoding method. In most cases, it will be UTF8.

Wheel 4 : doFinal()

Now we can actually get the encrypted data from the cipher. doFinal() will produce a byte array, which is the encrypted data.

byte[] ciphertext = cipher.doFinal();

A number of the methods we've talked about can be overloaded with different arguments, like start and end indices for the byte arrays passed in.


As we need to have a key which we will be using to encrypt/decrypt the stuff, let's discuss a bit about java.security.key interface (NOTE this is an interface).

We will be creating instance of this interface by it's implementer classes like javax.crypto.KeyGenerator or java.security.KeyFactory

Key interface has three methods

1) getInstance()
Below example will generate DES key.
KeyGenerator keyGenerator = KeyGenerator.getInstance("DESede");

2) init()
Below code will generate 3DES key which is always 168 bits.
keyGenerator.init(168);

3) generateKey()

Finally we get the key using this method.
Key myKey = keyGenerator.generateKey();

Now since we have all the necessary things to build a house lets construct it. Just think before you start constructing it. Which brick will fit at what spot to make it a perfect house.

1) We need a key which we will be using for encryption and decryption.
2) We need to instantiate Cypher class using factory method to do the actual job.



package com.kapil.util;

import java.security.Key;

import javax.crypto.Cipher;
import javax.crypto.KeyGenerator;

public class JESEncryptDecrypt
{
public static void main (String[] args)
throws Exception
{
if (args.length != 1) {
System.err.println("Please enter text to encrypt");
System.exit(1);
}
String text = args[0];

System.out.println("Generating a DESede (TripleDES) key...");

// Create a TripleDES key

KeyGenerator keyGenerator = KeyGenerator.getInstance("DESede");
keyGenerator.init(168); // need to initialize with the keysize
Key key = keyGenerator.generateKey();

System.out.println("Done generating the key.");

// Create a cipher using that key to initialize it

Cipher cipher = Cipher.getInstance("DESede/ECB/PKCS5Padding");
cipher.init(Cipher.ENCRYPT_MODE, key);

byte[] plaintext = text.getBytes("UTF8");

// Print out the bytes of the plaintext

System.out.println("\nPlaintext: ");

for (int i=0;i < plaintext.length;i++)
{
System.out.print(plaintext[i]+" ");
}
// Perform the actual encryption

byte[] ciphertext = cipher.doFinal(plaintext);

// Print out the ciphertext

System.out.println("\n\nCiphertext: ");
for (int i=0;i < ciphertext.length;i++) {
System.out.print(ciphertext[i]+" ");
}

// Re-initialize the cipher to decrypt mode

cipher.init(Cipher.DECRYPT_MODE, key);

// Perform the decryption

byte[] decryptedText = cipher.doFinal(ciphertext);

String output = new String(decryptedText,"UTF8");

System.out.println("\n\nDecrypted text: "+output);
}
}

How Caching works???

In todays web world many concurrent users access the web applications. Most of the web applications access the database (relational/hierarchical) in some way or the other to authenticate the user and validate the user rights on the web application. If web applications access the database each time user access the site then it will throw the user to go to competior because they are smart and implementing cache :-)

Web applications use caching to store the session information and authorization rights information for fast access. If web application does not manage the cache then it has to access the database to get the authorization information each time user access some link. This task is time as well as resource consuming.

When a object is retrieved for the first time from the database, instead of discarding the information it is storred in a buffer called cache. There are lot of complications storing the retrieved information in the cache:

1) Since caching is meant for faster retrieval if we keep adding newly retrieved contents from the database it will grow to unmanageable size. Smart people remove the unnecessary contents from the cache based on different algorithims. Some of them are mentioned below

a) Least Recently Used
b) Least Frequently Used

2) Implementing cache using algorithim which makes the fast retrieval/search possible.

3) Consider a scenario in which user has rights to access 10 links on a site initially and those rights are cached. Later on those access rights are modified (added more rights or removed some extra rights) from the admin console. If the cache is not updated on time user will not be able to access what S/he has right to access. To overcome this problem chaching should be updated at the same time when rights are modified.

4) Consider another scenario in which there are two servers behind the load balancer and cached objects are local to the servers (i.e cache is not shared between both the servers). If one of the server goes for a toss what will happen for the cached objects. To overcome this scenario chache manager needs to send notification of the newly added/removed cached object to other server's in the cluster.

5) Implementing max time for which a cached object be alive in the cache. After that max time is reached the object should be removed from the cache and recached based on next request from the user.

6) Caching parametes should be configurable so administrators can change them based on requirements.

Caching frameworks

Several object-caching frameworks (both open source and commercial implementations) provide distributed caching in servlet containers and application servers. A list of some of the currently available frameworks follows:

Open Source:
Java Caching System (JCS)
OSCache
Java Object Cache (JOCache)
Java Caching Service, an open source implementation of the JCache API (SourceForge.net) SwarmCache
JBossCache
IronEye Cache

Commercial:
SpiritCache (from SpiritSoft)
Coherence (Tangosol)
ObjectCache (ObjectStore)
Object Caching Service for Java (Oracle)

Technorati : cache internal

How to get plain text password in Active Directory???

I have seen many products synchronizing password/ sending password synch events to IDM products when user changes the password in Active Directory. Due to security reasons Windows does not allow users to get the plain text password once stored in the directory but Microsoft has given a way in case we have to get the plain text password for above reasons and also to enforce a specific password policy which can not be configured out of the box configurations.

There can be chain of password filter DLL's installed which will be called one after the other in the sequence defined in the registry (I will discuss this configuration in a bit)

Password Filters

Password filters provide a way for you to implement password policy and change notification.

When a password change request is made, the Local Security Authority (LSA) calls the password filters registered on the system. Each password filter is called twice: first to validate the new password and then, after all filters have validated the new password, to notify the filters that the change has been made. The following illustration shows this process.

Important Functions

InitializeChangeNotify
Indicates that a password filter DLL is initialized.
PasswordChangeNotify
Indicates that a password has been changed.
PasswordFilter
Validates a new password based on password policy

To install and register a password filter DLL
Copy the DLL to the Windows installation directory on the domain controller or local computer.
To register the password filter, update the following system registry key:
HKEY_LOCAL_MACHINE SYSTEM CurrentControlSet Control Lsa
If the Notification Packages subkey exists, add the name of your DLL to the existing value data. Do not overwrite the existing values, and do not include the .dll extension.
If the Notification Packages subkey does not exist, add it, and then specify the name of the DLL for the value data. Do not include the .dll extension.
The Notification Packages subkey can add multiple packages.
Find the password complexity setting.
In Control Panel, click Performance and Maintenance, click Administrative Tools, double-click Local Security Policy, double-click Account Policies, and then double-click Password Policy.
To enforce both the default Windows password filter and the custom password filter, ensure that the Passwords must meet complexity requirements policy setting is enabled. Otherwise, disable the Passwords must meet complexity requirements policy setting.

Curtsey: I took some of the content in the article from Microsoft site directly.

Tips for Developing efficient LDAP Applications

I took this topic from sun blog but added some example code to show what the topic means so part of credit goes to them.

* Make sure to use LDAPv3 rather than LDAPv2. Some APIs still default to LDAPv2, but LDAPv2 doesn't support features like controls, extended operations, referrals, SASL authentication, and multiple binds on the same connection.

* Use at least minimal caching to avoid repeating the same queries. If you include a list of attributes to return, then make sure that you include all attributes you may need rather than performing different queries to retrieve the same entry with different attribute lists.

For example :

use this
String RETURN_ATTRIBUTES[] = { "mail","givenname","sn" };
Attributes attrs = ctx.getAttributes(DN, RETURN_ATTRIBUTES);
insted of

String RETURN_ATTRIBUTES[] = { "mail","givenname","mail" };
Attributes attrs = ctx.getAttributes(DN, RETURN_ATTRIBUTES);

String RETURN_ATTRIBUTES[] = { "mail","givenname","sn" };
Attributes attrs1 = ctx.getAttributes(DN, RETURN_ATTRIBUTES);

String RETURN_ATTRIBUTES[] = { "mail","givenname","givenname" };
Attributes attrs2 = ctx.getAttributes(DN, RETURN_ATTRIBUTES);


* Design your application to allow for loose consistency in replication and the possibility that reads and writes may happen on different systems without the application's knowledge. Avoid read-after-write behavior because it can have inconsistent results.

What I understood : In a load balanced environment when application uses connection pooling it may get connections from different servers. Some times if write operation is performed on the consumer, it may redirect the request to the master. Master may take some time to replicate the change to all consumers. If you try to do read after write there may be some inconsistencies.

* Don't treat the Directory Server like a relational database. Avoid splitting data into separate pieces so that you need to retrieve multiple entries to get all the information about a given entity.

* If you generate search filters, then do so intelligently. If you have compound filters, then use a form like "(&(a=b)(c=d)(e=f))" rather than "(&(&(&(a=b))(c=d))(e=f))" to avoid unnecessary nesting.

Unnecessary nesting may make the filter more complicated to understand and take more time to perform the operation as in the above case LDAP server will have to process 3 AND operators in the second query instead of 1 AND in the smart query. Softerra browser has a very good interface for building queries.

* Unbind connections when they're no longer needed. It's generally best to re-use connections as much as possible, but whenever you're done with a connection make sure it gets closed.

* Don't litter your code with hard-coded attribute/objectclass names, base DNs, server addresses/ports, usernames/passwords, etc. If you need to change something later, it can be hard to make sure that everything gets updated properly. You should centralize all such values in a constants class or a properties file so that they are simple to change if necessary.

* Where possible, maintain a set of persistent connections to the server (i.e., connection pools) rather than connecting and disconnecting for each operation. This will be much more efficient, especially when using SSL. In order to avoid leaking connections and duplicating large amounts of code, it may be a good idea to code the various types of operations into the connection pool itself so that those operations will check out a connection, perform the operation and any necessary error handling, and make sure the connection is put back into the pool.

I promise I will add a topic to explain how to write code for connection pooling in LDAP.

* Design your application to be able to handle the different kinds of failures that may arise: server down, network outage, DS backlogged or unresponsive, DS returning unexpected responses (e.g., unavailable or busy). Don't assume that a lost connection means the server is down -- it could be that the connection was closed due to the idle timeout or some other constraint.

Technorati : Efficient LDAP programming

How to rename LDAP DN ?

Often a times I hear from my friends that they have a requirement to rename the user id in LDAP/Active Directory. They tried to modify the DN attribute directly but that does not help as DN is an operational attribute which can not be directly modified.

Correct approach is to call the rename API from JNDI and that takes care of the job. I am pasting a sample code ( changing the which I feel will help some one who is also looking for similar functionality.

public static boolean changeId(DirContext ctx, String p_oldID, String p_NewID)
{
String RETURN_ATTRIBUTES[] = { "uid","objectclass","modifytimestamp"};
String DN = null, LDAPuid = null ;
boolean status = true;
int i = 0;
Attribute attr = null;

String newid = "\"cn=" + p_NewID +",OU=Users,OU=Test\"";

String empNo = null;

try
{
// Make LDAP connection
//ModificationItem[] mods = new ModificationItem[1];
String SEARCH_FILTER = "(cn=" +p_oldID+")";

SearchControls constraints = new SearchControls();
String newline = System.getProperty("line.separator");
// Set search scope to subtree
constraints.setSearchScope(SearchControls.SUBTREE_SCOPE);
NamingEnumeration results = ctx.search("", SEARCH_FILTER, constraints);

while ( results != null && results.hasMore() )
{
//String s = "";
SearchResult sr = (SearchResult) results.next();
DN = sr.getName();
System.out.println("DN is" + DN);
i++;
Attributes attrs = ctx.getAttributes(DN, RETURN_ATTRIBUTES);

attr = attrs.get("uid");
LDAPuid = (String)attr.get();
System.out.println("UID is " + LDAPuid + newline);

ctx.rename(DN,newid);

System.out.println("Employee Number | New User ID");
// System.out.println(empNo + " " + p_NewID );

}
System.out.println("Total no of records are " + i);
System.out.println("Now changing the userid in LMS ....");


}

catch(Exception e)
{
System.out.println("In the exception block" );
e.printStackTrace();
return false;
}
return status;
}

Technorati : LDAP rename entry

How HTTP Keep Alive works?

HTTP Keep Alive
Http Keep-Alive seems to be massively misunderstood. Here's a short description of how it works, under both 1.0 and 1.1, with some added information about how Java handles it.

Http operates on what is called a request-response paradigm. This means that a _client_ generates a request for information, and passes it to the server, which answers it. In the original implementation of HTTP, each request created a new socket connection to the server, sent the request, then read from that connection to get the response.

This approach had one big advantage - it was simple. Simple to describe, simple to understand, and simple to code. It also had one big disadvantage - it was slow. So, keep-alive connections were invented for HTTP.

HTTP/1.0
Under HTTP 1.0, there is no official specification for how keepalive operates. It was, in essence, tacked on to an existing protocol. If the browser supports keep-alive, it adds an additional header to the request:

Connection: Keep-Alive

Then, when the server receives this request and generates a response, it also adds a header to the response:

Connection: Keep-Alive

Following this, the connection is NOT dropped, but is instead kept open. When the client sends another request, it uses the same connection. This will continue until either the client or the server decides that the conversation is over, and one of them drops the connection.

HTTP/1.1
Under HTTP 1.1, the official keepalive method is different. All connections are kept alive, unless stated otherwise with the following header:

Connection: close

The Connection: Keep-Alive header no longer has any meaning because of this.

Additionally, an optional Keep-Alive: header is described, but is so underspecified as to be meaningless. Avoid it.


Curtsey: http://www.io.com/~maus/HttpKeepAlive.html

Commonly used openssl commands

Here I am giving some of the commonly used openssl commands.


• Generate A Certificate Signing Request
openssl req -new -newkey rsa:1024 -keyout hostkey.pem -nodes -out hostcsr.pem
• Create A Self-Signed Certificate From A Certificate Signing Request
openssl req -x509 -days 365 -in hostcsr.pem -key hostkey.pem -out hostcert.pem
• Generate A Self-Signed Certificate From Scratch
openssl req -x509 -days 365 -newkey rsa:1024 -keyout hostkey.pem -nodes -out hostcert.pem
• Generating a certificate using the ca certificate generated above
openssl x509 -req -in sonycsr\ldapssllocal.pem -CA sonycerts\ca.pem -CAkey sonykeys\cakey.pem -CAcreateserial -out sonycerts\ldapssl.pem -days 1024
• View The Contents Of A Certificate Signing Request
openssl req -text -noout -in hostcsr.pem
• View The Contents Of A Certificate
openssl x509 -text -noout -in hostcert.pem
• View The Signer Of A Certificate
openssl x509 -in cert.pem -noout -issuer -issuer_hash
• Verify A Certificate Matches A Private Key
openssl rsa -in key.pem -noout -modulus
• Find The Hash Value Of A Certificate
openssl x509 -noout -hash -in cert.pem
• Create A Private Key
openssl genrsa -des3 -out key.pem 1024
• Encrypt A Private Key
openssl rsa -des3 -in hostkeyNOPASSWORD.pem -out
• Decrypt A Private Key
openssl rsa -in hostkeySECURE.pem -out hostkeyNOPASSWORD.pem
• Convert PEM Format Certificate To PKCS12 Format Certificate
openssl pkcs12 -export -in cert.pem -inkey key.pem -out cred.p12
• Convert PKCS12 Format Certificate To PEM Format Certificate
openssl pkcs12 -in cred.p12 -out certkey.pem -nodes -clcerts

Technorati : openssl commands