It's considered bad practice to keep a user's password anywhere on your server in plain view. Many users use the same password across multiple systems, and if your server was ever compromised, the attacker would then have emails, usernames and passwords for a lot of different people (depending on how popular your particular site is of course). They could then use this information to try to login to other systems that your users might typically use. Thus giving the attacker access to other personal information about your users.
I wouldn't use your system if I knew you stored my password in plain text somewhere on your server. And it's the responsiblity of web app developers to make sure that systems they develop doesn't do this. There are ways to encrypt passwords so that they can still be retrieved, which is worth reading about. Most apps these days use the methods that you've mentioned. They allow the user to pick their own password (you can force them to make sure it has so many characters, and not too easy to guess if you'd like), and then forces them to confirm their account through email. They already have their login credentials at this point, just not allowed to login until the "confirmed" flag has been set. If they lose their password, they're typically emailed some information about how to change their password, or even a new password that's randomly generated. I just had to do a "Forget your password" process yesterday, in which they sent me an email with my username and password. Upon logging in with that data, they then required me to change my password, and then provide other user details to confirm it was me. I'm sure if you look around on the web you'll find all sorts of discussion about the best way to deal with these type of login and registration systems. What's best for your users is really up to you, but I strongly advise you to encrypt password information at all costs. Jay patrickk wrote: > thanks james ... your answer leads to more questions: > > 1. so what do you do when a user forgot his password? you obviously > can´t email it, so you have to set a new one. that seems a little > complicated (for the user). > 2. the user should set his own password, I agree. but that doesn´t > mean, I´m not going to send it ... does it? > > so what´s the preferred solution here? > the user sets his own password and writes it down somewhere (because I > ´m not able to send it - I´m not sending the password before the user > activates his account, of course). and when he lost his password, we > have to set a new one ... ? > > I´m not sure I really get the idea here. one solution might be to > store the raw password somewhere (extending the user model) - but that > ´s also very strange. on the other hand, that seems to be a very > common task/problem ... I´m confused ... > > patrick > > > Am 18.07.2006 um 19:42 schrieb James Bennett: > > >> On 7/18/06, va:patrick.kranzlmueller <[EMAIL PROTECTED]> >> wrote: >> >>> since the password is stored encrypted, I´m not sure how to send it. >>> >> There isn't any way to get at the 'raw' password once it's been >> encrypted; you'll need to work around this by emailing the password >> before it's encrypted, or by having the user set their own password >> during registration (which is arguably more secure than emailing it). >> >> >> -- >> "May the forces of evil become confused on the way to your house." >> -- George Carlin >> >> > > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~----------~----~----~----~------~----~------~--~---
