50 Replies
my user name and phone number in data base in unique
now i made a part so it can be updated
but if the user name and phone number be same as old one it cant update the password
and for update password user need to chenge the username + phone number everytime
is there anyway i can fix it
yes: separate the password update
it makes absolutely no sense to send a password update at the same time you send phone number updates
so, create a separated form for the password
should i do this for user name and phone number too ?
or only password
usernames should have a separated system too, since they MUST be unique
but over all it is possibel do to all of the at once ?
DO NOT DO THEM AT ONCE
yes but in overall i mean
it is, but it is very bad ux
the password needs to be updated separatedly
im making another section for it
here's the correct process to update a password:
- check if all fields are filled in
- check if the new password and confirmation are the same
- check if it respects the rules you want for the password
- check if the password hash matches the hash in the database
- update the hash in the database or reject
just check how other websites do it
many even have an entirely different page just for the password
ye most of them use diffrent page
i just remove editing username
and only phone number
you should give the option of having a display name that isnt an username, like how discord does
thats a good idea
and obviously, store emails too
if you need to update the email address or username or restore passwords, you need an email address
in first i was gonna only use phone number and no password and user name
and only people can enter website with 2fa
but i chenge it to this
you mean, with oauth?
yes
then it isnt 2fa if it only uses oauth
hmm
but that is a good idea, as you dont have to deal with passwords
yes thats very eazyer and faster
and im pretty sure you will royally screw it, as dealing with passwords is hard
i mean, if you're asking about how to update a password, im sure you arent using hashes
yes
are you using hashes?
NO
then you're doing it very very very very wrong
.....
it is very importent ?
lets put it this way: if you dont want to be on the news for a data leak, it is mandatory
🤣
i can do it with only php ?
yes, use
password_hash
and the associated functionsand i need to un hash it for using it ?
you cant unhash it
thats the whole point of the hash: it's always one way
but system will un hash it for using it ?
no
there is no unhashing
it doesnt exist
if someone get the hashed password some how he can just login into account
unless the hashing algorithm is broken and insecure
no, because the hash of it will be different
is php hashing system safe?
it's safe enough, as far as we know today
and as far as has been mathematically proven so far
any password you put into a hash will always produce the same hash (with some caveats, but not going to go into that here). So when someone logs in, you send the password to the server, which then calculates the hash of the sent password and compares it to the hash in the database. If they match, what the user put in matches what they put in when they last changed their password
yup, but you need to use a specific function to compare, or your site is susceptible to timming attacks
and php has weirdness when comparing strings with numbers too ...
and you need to re-hash the password if the setting have changed as well
but as jochem explained, you always hash the value to compare to the password
basically, "it's complicated" and it's a good idea to read up on best practices before you ever use this for something even remotely important, and probably before you write any code that you'd want to show anyone else
and never, ever, EVER use passwords without hashing. Not even once
I've had to maintain an application from when MD5 was fine through SHA1 and up to using mcrypt and finally password_hash. It's not the end of the world, you just check the type of hash, validate with that one, and update the hash if it's valiid to the newest type on next login. And invalidate any passwords using the old hash six months after the transition
ive had to do the same, and it was a little messy
but still, you have to compare the hash in a timming-constant way
and not use the
== operator
the === is fine, but isnt timming-constantback in the day, I just decided that 700ms was an acceptable response time, logged the start, then never returned anything from the page until 700ms had passed
no matter what the outcome of the password check was
no, no, that's not what i meant
it's to prevent timming attacks
for example, the time that a wrong input takes is different from the correct one
with that, and many attempts, it is possible to guess the password (specially if it isnt even hashed)
yeah, that's what I mean. I saved the start time in a variable, checked the password, then if it was successful loaded everything from the DB and set everything up serverside. That always took <50ms. Then, whether the check succeeded or not, I subtracted the start time from the current time, subtracted that result from 700, and slept for that many ms before the first output to apache ever took place
it's crude, but there wasn't anything built in back then
anyway, this is just two old developers rambling on about how shit used to work "back in our day 🧓"
that is a very very shoddy and consistent way of doing it
it's smart, not gonna lie
I mean, this was PHP4 days
so shoddy was the way you did everything
yeah, it's understandable