Jump to content

Updating Passwords and dealing with Lost Passwords


limitphp

Recommended Posts

Ok, as far as having users being able to update their passwords, I have a page myaccount.php

 

You can only get to it if you've logged in.  Once their it displays their info.  Name, username, password, and email address.

You can only update and change your password and email address.

Name and username you cannot change.

I'm new to developing this, is that a good policy?

 

As far as dealing with lost passwords, I guess I'll start by storing encrypted passwords in the user table.

If they forget their password, I guess I can have them store a security question and an answer.  Once they answer the question, send them a new password to their email.

Is that a good policy?

Or do you think thats too much?  Should I just have them give me their first and last name and their email address?

 

I just want to make sure people don't start resetting other people's passwords.

 

All good except changing emails

 

 

Changing Emails shouldn't be done unless absolutely necessary

 

This prevents spam accounting

 

Thank you very much.  I will disable the ability to change email addresses.

Should I even display the info to them?

Like their name, username, and email address?

Right now I have it all showing in textboxes with the name, username textboxes disabled.

Give each user a unique auth code, it would look something like this:

 

a8d4k894kJ0ws45sK

 

then when updating the db, you would do something like this:

 

$auth = $_SESSION['a8d4k894kJ0ws45sK'];
mysql_query("UPDATE tableName SET `password` = '{$pass}' WHERE `auth`= '{$auth}' AND `id`='{$_SESSION['id']}'");

Give each user a unique auth code, it would look something like this:

 

a8d4k894kJ0ws45sK

 

then when updating the db, you would do something like this:

 

$auth = $_SESSION['a8d4k894kJ0ws45sK'];
mysql_query("UPDATE tableName SET `password` = '{$pass}' WHERE `auth`= '{$auth}' AND `id`='{$_SESSION['id']}'");

 

 

Not really necessary if they login they are fine,

 

NOt changing email also prevents you from not being able to pw recover

Suppose I can no longer access email I registered with. What I'm supposed to do? Register again? What if your site's TOS forbid having multiple accounts?

If you forbid me to change my email address, I'd rather not register at all.

Suppose I can no longer access email I registered with. What I'm supposed to do? Register again? What if your site's TOS forbid having multiple accounts?

If you forbid me to change my email address, I'd rather not register at all.

 

Thats a good point.

But, if you forget your password and you no longer have the same email address, how do I know you are who you say you are?

 

Whats to stop someone from saying they are your username and request a new password be sent to some other email address?

A security question and answer?

 

They can have multiple accounts, thats fine.  It'll just make my site appear to have more users....kind of like digg. 

All the purchases of music on my site will be done with google checkout.

So, I assume they'll fill out all their personal stuff through google.

 

Thats a good point.

But, if you forget your password and you no longer have the same email address, how do I know you are who you say you are?

 

Exactly. You don't.

Imagine this scenario.

I register on a site in december 2008 using my current email account.

In march 2009 my ISP gets out of business, and I have to change my email address

In january 2010, Eskimo hackers attack your site, and gain access to user database. To avoid them logging with stolen passwords you decide to regenerate passwords for all users and sent them to their registration emails.... oops...

Man... and I was so active member of the community... had this nice profile and things...

 

Exactly. You don't.

Imagine this scenario.

I register on a site in december 2008 using my current email account.

In march 2009 my ISP gets out of business, and I have to change my email address

In january 2010, Eskimo hackers attack your site, and gain access to user database. To avoid them logging with stolen passwords you decide to regenerate passwords for all users and sent them to their registration emails.... oops...

Man... and I was so active member of the community... had this nice profile and things...

 

HAHAHA, well said!! Amusing and Intuitive

This is true I guess its really a site to site thing.

 

If multiple accounts is a big issue locking down is key

If protecting an account is vital locking down is key

 

If contacting the user via email is vital maybe not locking down or allowing mulitple

 

 

The goal of any type of system is to write it to work for your needs

Thats a good point.

But, if you forget your password and you no longer have the same email address, how do I know you are who you say you are?

 

Exactly. You don't.

Imagine this scenario.

I register on a site in december 2008 using my current email account.

In march 2009 my ISP gets out of business, and I have to change my email address

In january 2010, Eskimo hackers attack your site, and gain access to user database. To avoid them logging with stolen passwords you decide to regenerate passwords for all users and sent them to their registration emails.... oops...

Man... and I was so active member of the community... had this nice profile and things...

 

So, should i let them change their email address on the myaccount page?

I'm confused again.

 

Ok, this is what I'll do:

Store encrypted passwords in the database.

When they register store a field called security_question and answer.  (let them create question and answer).

How long should I make the security_question field?  300 varchar?  500 varchar?

 

 

How should I build the rest of it?

On the myaccount page (they have to be logged in to access) should I display their username, name, password, email, but only let them change their password and email?

 

And, then, if they forget their password, have them answer their security question and then send a new password (generate via md5(uniqID)?) to their email address?

 

I'm new to developing all this, so I'm not sure how to set it up.

 

 

 

Re: Security questions.

I am not sure if you should let users choose their own questions. That could be possibly the weakest point in your account system, because people are lazy. Majority of questions would be, 'what's my second name' and such. Doesn't take long for someone who knows the user, to break into his/hers account this way.

 

Have a list of 10 predefined questions, that are not too straightforward.

 

(BTW: whenever I have to choose a security question, I choose a random one, and put in my generic security answer (being the name of my dog... which I never had) :P )

Agreed also My User management system sets the default password recovery answer to yes but when you go to change your temp password you must put in a security answer greater than 3 characters long forcing you to change it.

 

Yes I get angry emails from confused ppl everyday but it has helped make ppl change security answers

Thanks guys. 

I'll have a list of predefined security questions they can select.

I'll just make a list of questions in a security_questions table.

 

So, I guess I'll be updating my register page.

 

My site doesn't really need to be super duper secure.  Its basically going to be a site that sells music.  Only people will have to use google checkout to buy the music (for now...because its the cheapest solution.  So, I won't be storing alot of sensitive data on people....really no sensitive data.

 

I need to get more confidence in building this website.  If I make mistakes, screw it, I need to just push forward and get this thing finished. 

If I've messed up and need help later on, I need to realize I can just come here and get some help.  I'll probably be better off for making the mistakes both in syntax and mainly the logical mistakes in design.

 

 

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.