Link to home
Start Free TrialLog in
Avatar of rgb192
rgb192Flag for United States of America

asked on

change password links

/ChangePassword.php?userID=125&token=afdfacdfasf32ad

change password link

userID numerical

token long hash string

I am watching a php security video where teacher warns to make token unique for every userID because one user can maliously change all users password by guessing userID given same token

is this situation common
I think I may have had non content management system change password links in my php programming past where I could have been exploited


do content management systems like wordpress prevent this exploit
ASKER CERTIFIED SOLUTION
Avatar of Ray Paseur
Ray Paseur
Flag of United States of America image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
SOLUTION
Avatar of skullnobrains
skullnobrains

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
SOLUTION
Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
SOLUTION
Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
SOLUTION
Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of rgb192

ASKER

thanks
Avatar of skullnobrains
skullnobrains

@ray ( and a little off-topic. chip in if you like, just discussing the subject )

the above links apply to the storage of local passwords and is pretty much the way passwd authentication works on most unix systems.

when dealing with remote users, you need to consider that the main risk relies somewhere between the user's keyboard and your password backend. recent security breaches such as heartbleed pretty much demonstrate that point. this is even more true nowadays since many servers usually handle multiple users with a single process, even when performing authentication.

it is hence VERY important to use password-response mechanisms when authenticating users. this implies the authenticating daemon needs to know the actual password rather than a hash.

one way to address this is to run separate saslauthd servers. usually these would be dedicated and run a minimal number of services ( typically saslauthd only. no ssh or telnet. no console login allowed. ) from encrypted drives. you can alternatively use a reversible encryption for the individual passwords or the password database that is input when the password storage starts.

either way the passwords are known to the process/server while it is running which is a security concern and the reason why you would use a separate host and whatever extra security measures you deem reasonable. replicating the passwords between such hosts is probably the most complex part, but that's a whole other story.