The MyAccount.aspx form on pp 178-179 does not populate the current 
password field.  In some cases this might be a good idea, but I got to 
thinking about the many websites that offer to send you the password you 
may have forgotten.  That means we would need to pull the password from 
the database, and reverse-engineer the SitePrincipal code that encrypts 
the password.  

Does anyone know to do this?  I don't understand these Cryptogrophy 
classes that well.  I am not into to crashing systems, so I never learned 
this stuff.  Perhaps this is a sensative topic, and the answer should not 
be posted.  Comments anyone? 

Hi Charles,

In my view a very good point.  I haven't looked at that code for months
but my recollection (and comments) follow:

1)  Coding uses a one way hash so you can't recover the password.  (I
think)

2)  Philosophy on passwords is all over the map.  People have widely
differing attitudes.  It's a thing that causes irrational behaviour.  An
important consideration is running costs.  If you can't send out the
password you may have to hire people to babysit those can't manage their
passwords.  I think e-mailing the password is important (probably in
most cases).

3)  I decided to change that part of the design.

4)  There are some good articles about encryption on the web.  (maybe
try DevX.)

5)  This is another example that shows that users of the book MUST
understand the framework and the languages so that they can make it do
what they want.  ASPX goes way beyond ASP in this instance and if you
can only perform "glue programming" you are probably in trouble!

6)  NOTE TO AUTHORS.  This would be a good feature for version 2.  (BTW.
If you are working on this please keep class boundaries and interfaces
intact to help those who have customised.) 

Mike Gale, Decision Engineering (NZ) Ltd.
 
>may have forgotten.  That means we would need to pull the password from

>the database, and reverse-engineer the SitePrincipal code that encrypts

>the password.