It's not that huge, ASCII only constitutes 128 characters, or 256 if you count all 8-bit possibilities of extended ASCII.

There is often a space/performance tradeoff in optimising code. You can do stuff really quick and take up loads of memory, or you can do stuff in virtually no memory and take ages, and there are often points in between.

So you can reduce the histogram from Saswat's 400 chars to just 32 bytes as follows:
set all 32 bytes to zero
scan the first string and for each character present, take the character code and split it in two: the lower 3 bits and the upper 5 bits.
The upper 5 bits divided by 8 gives you the index into the 32-byte array.
The lower 3 bits identify one of the 8 bits in that byte.
Set the relevant bit (1 << that_3_bit_number) to 1.

Scan the second string and again split the character code into two parts (5 and 3 bits).
Check the relevant bit and if it's 1 then you have a duplicate character - output it.

This prints duplicates, of course, so if string 1 is THIS IS COOL and string 2 is XPIOTOS then the program output will be IOTOS - the duplicate O's may be a problem. If not then this is your solution.

If it is then you can have a second array of 32 bytes, and when you parse the 2nd string update the 2nd array in the same way as when you parsed the 1st string.
To pick out updates scan both sets of 256 bits and where there is a 1 in both, you have a common character. Output then would be IOST (in some order).

Or you could just have a single array of 256 ints, initially zero, scan the first string, set relevant flag to 1, scan the 2nd string and shift the relevant flag left by 1. Then scan the ints and where a flag is 2 you have a character that was in both strings.