Ranter
Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
Comments
-
Never ever ever should someone be able to change someone else's password directly.
Like you did. -
Numinex10867yYeah... It sounds like you're storing passwords in plaintext and you sent it to them via email...
-
@Numinex @dontPanic @rammmukul
Anyone with access to the database can technically reset a user's password if that is used for authentication and not encryption - no matter if the password is hashed, salted or encrypted with 748 iterations of rot13...
It shouldn't necessarily be done that way, but there are valid scenarios for it (for example ldap in small companies). -
@Numinex There is no password reset page. The passwords are salted md5 hashes. So I would go in there, generate a new password and salt, mix them up, store in the database, and send the user their new password.
-
@Condor Of course. While I maintained this site, I rewrote from the ground up. And there were a lot of other reasons for a rewrite including, SQL injection, XSS, pages simply lacking authentication, you get the idea.
-
@Condor Yes, defiantly. I was considering starting devrant.com to rant about it. Then I found this site.
-
@Condor If it wasn't salted, it would be close to nothing. Since it is, I think it's difficult to crack even with an unsecure hash function. But don't take my word on it, I might recall it wrong.
-
@Condor Yes, maxlength usually indicates either passwords saved in plain text or mindless developers. Both are a security issue. :)
-
hell169537yI don't see any problem in resetting the password to a temporary one but I still vote for the automatic reset option.
Related Rants
So a user reported they couldn't login to our site, so I reset their password to:
uI+ffRT7M2NAzo8uOqzf4QxO3I9tj8PJ4TS0n8zDV7I
And sent them back an email with the updated password. A few minutes later, they replied and said that password didn't work. They even tried a different web browser, etc. I tried it myself, and sure enough, it didn't work.
I spent the next several hours trying to figure out why the password didn't save properly, or why the logic didn't compare them correctly. Perhaps it was some sort of caching issue? Oh the horror.
As it turns out, the problem was a maxlength of 28 on the login form field:
<input type="password" name="password" value="" maxlength="28"/>
I don't know who wrote that code, but it sure wasn't me.
undefined
html