Question: Most of the online sites on registration do send a link to activate the site and on any further correspondence with the end user they provide information about the site and also provide the login credentials with password in clear text (as given below)

Username - myname@gmail.com
Password - mysecretpassword

What would you do in such a case? From a usability perspective does it make sense to send the password information in clear text or should you just avoid sending this information. I was under the impression that most of the passwords are MD5 hashed before storing in the database and hence the service provider will not have any access to clear text passwords, is this a security violation?

Answer: 
It's a commonly-held fallacy that if you receive a password in plain-text it means they aren't stored securely - passwords like any other data can be stored using reversible encryption.

Having said that, it's pretty likely anyone that sends you a plaintext password does not have a clue about security and is probably storing them carelessly (unless the passwords are used as weak real-world identifiers, say as part of an in-store membership scheme, in which case they shouldn't be called passwords lest your customers get confused).

If you send a password plain-text you may as well assume that if it is linked to something important then it has been compromised. There are just too many weak points. You can also do a lot more unintentional damage.

1. The email could be intercepted giving someone else the password.
2. Someone could see them open the email on their screen (been at mates houses and had this happen to both of us so many times, and every time is a massive headache to go change all your passwords).
3. The email might be forwarded to other addresses which are not secure.
4. The email might bounce/encounter a server error and then you (perhaps your untrusted staff or outsourced helpdesk too?), and the email server's system admin will probably get copies of the original email.
5. Someone who obtains access to the user's emails through a cookie hijack or even just a briefly unattended open email account will now be able to see their password. Worse, their password is probably used elsewhere (or at least has a common stem, e.g. "password1", "password1$$" "passwordSuperSecure123") so you've now compromised more than just your own service. Worse still, it might be the password to the email account that's been hijacked and now they can steal this person's email account and thus identity for a much longer time than the expiry date on the cookie/session. (This has all happened to people I know).
There are always trade-offs, and developers have to consider useability, the savvy-ness of the intended users, the secrecy and importance of the data, the frequency that the website will be used, and so on. Of course users don't want their privacy violated, but on the other hand "ordinary" web users may be turned off by having to remember a password, or even having to invent one in the first place (some websites simplify user registration by generating a random password and emailing it). Website developers have a responsibility to keep the users' best interests in mind when designing security.

My advice is that passwords should only be emailed in the clear when they are randomly generated. This avoids the following awkward scenario: a user registers with a password which they are *already using* for various other web services, and then receives a registration confirmation email containing the password they just entered. A lot of users may not be security-conscious enough to use unique passwords for every website, but they *are* security-conscious enough to recognize that "sensitive" passwords should not be sent around by email.