This should go without saying, but I've heard the question asked enough to warrant a blog post. Generally speaking, the developer would like to store some secret information in a Silverlight application and, at the same time, prevent someone from accessing that information. A secret, in this context, is anything that could be used to compromise the system or any information that should not be disclosed to unauthorized entities. 
Let's take a quick look at how Silverlight applications are packaged and deployed. When you build a Silverlight application, your code is compiled into one or more assemblies. These assemblies are packaged together inside of a ZIP file archive (XAP File). This XAP file contains the assemblies and any additional resources that were not compiled into the assemblies as embedded resources. When the Silverlight plug-in is loaded, the XAP file will be downloaded for execution on the user's computer.
Any user that is curious about your application will do the following:
- Manually download the XAP file referenced on your Silverlight Host Page.
- Rename the XAP file from .XAP to .ZIP and extract the files.
- Open Reflector and disassemble your code in search of anything of value.
Simply put, you cannot safely store secrets anywhere inside your Silverlight application. Silverlight is no different from any other .NET application in this respect and the XAP packaging does not make it any more difficult to disassemble than a regular .NET application. In fact, one could argue that your application is even more vulnerable now since your application is visible over the Internet (assuming this is a public application)!
The question remains. How do you protect your secrets? Usually the first answer to this question would be to obfuscate your Silverlight assemblies. Obfuscation is a process for making it difficult to disassemble/read compiled code through the application of various algorithms. For example, one algorithm would replace meaningful variable, method, and class names with random character strings. While obfuscation does help "raise the bar" against casual snoopers, it will not stop determined individuals. After all, obfuscated code is still valid, just ugly and more complicated. If you are using obfuscation as the sole means to protecting the secrets of your application, you should not have a warm-fuzzy feeling about this.
If you really care about protecting secrets in your application, you need to change the way you are thinking about the problem. What if you could get away with not storing the secrets in your application at all? For example, suppose you have an algorithm that you want to protect, this logic is what gives your application value and if someone where to figure out how it works, they could re-package the logic and give it away. Instead, why not delegate this task to a web service that your Silverlight Application consumes? That way, your Silverlight application has no knowledge of how the work is done, it just ships off the work and gets the processed results back. Yes, this comes with a cost of external dependencies and possibly some performance penalties, but it may be worth it. This also has the added benefit of separation of concerns, since you can now build other "interfaces" to your valuable business logic down the road.
In summary, Silverlight does not bring anything new to the table that should change how you view security. These same problems existed before Silverlight and they will continue after Silverlight is released. Currently, the best way to protect secrets in your Silverlight applications is to not store them at all.