Most all web applications require some sort of username and password to login. However, you never know upon signing up how the application (site, service, whatever) will treat your password. – Option 1: The app does what all good applications, having been entrusted with your password, ought to do: it passes it through a one-way hash function (ideally with a random salt), and stores /only/ that hash code. There is *no* mathematically feasible way to retrieve your password, given only the hash code (although in some cases dictionary attacks work). Hence, if you forget your password, they have to send you a new one, but at no time does a second human have a chance to see your chosen password. – Option 2: The app is brain-dead, and stores your password in plain-text, (or in a symmetrically encrypted form where the decryption key is programmatically available to the app). These boneheads become recognizable when, upon using the “forgot password” functionality, they /send back your original chosen password in unencrypted email!/ (Dear reader, it should hardly be necessary to describe why this is a problem, but consider that in our wireless age, every unencrypted communication may as well be considered public knowledge.) There are exceptions, of course, where option 2 is quite reasonable; the venerable mailing list manager Majordomo tells you up front, “/Do not use a valuable password as it will occasionally be emailed back to you in cleartext/,” which tells you right up front what the situation is. Yet, any number of ostensibly professionally-run web apps — /many of whom anticipate being the lucky recipient of my credit card number to consummate a transaction/ — cannot be bothered either to properly protect my password or to inform me about their practices. *Therefore, I propose:* a “Password Statement”, as an adjust to or embedded within a site’s privacy and security policies, that describes how they plan on treating your shared secret (password). This statement should be summarized in a one-sentence line next to the password box on the registration dialog, with a link to more information (much as has become the /de facto/ standard for a statement about spam policies). Finally, I propose a voluntary “seal” program whereby a TRUSTe- or Verisign secure site-like seal is made available, subject to a benign entity’s copyright and trademark protection, to both signify a site’s password policy at a glance and to serve as a link to the password statement.