I have a Silverlight control on a web page and would like to pass the username and the hashed password to this control as part of the InitParams.
What are the security concerns with doing this?
The user has to log in to get to this page. However, I'm guessing that the browser might cache the page with the Silverlight control and this would cache the username and hashed password.
This brings me on to a more specific question: Is there a an HTML meta tag that tells a browser not to cache a page?
My question would be, what can the control do with the hashed password? It doesn't seem like it could serve any useful purpose, so why is it passed to the control?
A password is hashed to make it computationally infeasible to recover the original password. So, assuming the hash was done properly, there's no risk in exposing it. But, the fact that the control thinks it needs the hashed password makes me suspicious.
Keep in mind that MD5 hashing has been cracked by brute force attacks, so having a hashed password in the open is not 100% secure, but for most cases it may be a non issue especially if you use some stronger hashing algorithm.
Security: Think first about potential uses a malicious user might have for the hashed password (including comparison with other stored hashes).
Caching: Yes there is a meta tag, but you shouldn't use it unless you have to; better to set the HTTP headers
HTML authors can put tags in a document’s section that describe its attributes. These meta tags are often used in the belief that they can mark a document as uncacheable, or expire it at a certain time.
Meta tags are easy to use, but aren’t very effective. That’s because they’re only honored by a few browser caches (which actually read the HTML), not proxy caches (which almost never read the HTML in the document). While it may be tempting to put a Pragma: no-cache meta tag into a Web page, it won’t necessarily cause it to be kept fresh.
If an attacker can get at the hashed password, he could potentially reverse it by using a rainbow table. A rainbow table is basically a huge database of all possible passwords up to a certain size, indexed by their hash. I think of it as the ultimate speed-space trade-off. For passwords of up to 7 characters, containing only lower case letters and numbers, the rainbow table can fit in a few gigabytes. For longer passwords (or ones with less character restrictions) the required size does rise exponentially.
To defeat this attack, you need to salt the hashes. Salting means that you add a random salt value to the password before hashing it. This salt can be stored unencrypted next to the hash. Since each password is hashsed with another random salt, the rainbow lookup table becomes useless. Rainbow tables cannot consider all possible salt values because the required database size rises exponentially with the salt size.
Even then, weak passwords matching the salt+hash could still be found with brute force. This can be fixed by using some quality-control heuristics on the password (minimal length, mixes certain character types like lowercase/uppercase/digits/other, not just a 1 at the end...).
All in all, I'd say the security risks of exposing the hash are big enough that you're better of avoiding it.