http://motomastyle.com/home/ http://motomastyle.com/security-perceived-risk-versus-potential-damage/#PageComment_10 Your post alludes to a critical security vulnerability; you should never trust the User when it comes to security (or much of anything for that matter). In the case of the iTunes music library app, the damage was amplified because the User did not properly manage his passwords (namely, he only had one). There are two approaches to this situation: The first option is to force the User to be more secure ("Your password must contain at least 3 numbers, an uppercase letter and the symbol '∂'."). As a rule, though, this doesn't work; all you end up with is a bunch of post-it notes stuck to monitors. Alternatively, assume that your Users will do everything insecurely and code around worst-case scenarios. As I gather you were conveying as the main point in your post, it is a good idea to integrate security features now rather than wait until your app gets hacked. Thu, 29 May 2008 13:25:37 -0400 http://www.todofixthis.com http://motomastyle.com/security-perceived-risk-versus-potential-damage/#PageComment_10 http://motomastyle.com/security-perceived-risk-versus-potential-damage/#PageComment_9 Good post! Over the years I've seen wide-open SQL injection opportunities (and attempts to exploit them in the logs); an "is logged in" variable passed as a hidden field on the browser; an internal web site that was "securely" made available to remote users by placing it on an "unadvertised" public IP (Google picked it up, of course).... Educating folks is a never-ending battle. Thu, 29 May 2008 13:25:07 -0400 scottjeynes http://motomastyle.com/security-perceived-risk-versus-potential-damage/#PageComment_9