I would like to know how the password is saved in database ?
I mean what function is used?
Is it SHA1($password) or something else?
It is not SHA1($password)
It is SHA1(strtolower($username) . $password)
Curious: why do you want to know? Don't think about changing it. That's not a good idea unless you understand the many, many consequences.
Lainaus käyttäjältä: Arantor Beeblebrox the First - joulukuu 07, 2013, 08:29:24 IP
It is not SHA1($password)
It is SHA1(strtolower($username) . $password)
Curious: why do you want to know? Don't think about changing it. That's not a good idea unless you understand the many, many consequences.
Hi Arantor, thanks for replying, but that function is incorrect , it doesn't work,
I have made some modification for forum where user can change few of his settings, for this he needs to be logged in, so I am using this code:
<?php
require('SSI.php');
if($context['user']['islogged'])
{
change settings
enter password (if pass is correct then change settings) //User required to enter password for extra safety
}
?>
So to match the password just for additional security, I need to know how the password is hashed and converted so that I can match the password.
example:
<?php
$username="user";
$password="pass";
$c=SHA1(strtolower($username) . $password); //I need to know this function <<<<<<<<
if($c==$storedpasswordindatabase)
echo "TRUE";
?>
Trust me, that's how it's done. Trouble is your code misses out all the other stuff, like updating the session details and forcing an update to the cookie.
You should not do this via SSI, redirect to the user's profile where it is handled - along with proper security measures. Right now with your current code it would actually be possible for users to modify other users' passwords - including someone manipulating YOURS.
Lainaus käyttäjältä: Arantor Beeblebrox the First - joulukuu 07, 2013, 09:36:37 IP
Trust me, that's how it's done. Trouble is your code misses out all the other stuff, like updating the session details and forcing an update to the cookie.
You should not do this via SSI, redirect to the user's profile where it is handled - along with proper security measures. Right now with your current code it would actually be possible for users to modify other users' passwords - including someone manipulating YOURS.
I am just comparing two strings, I don't understand how they can be "manipulated", because I am not modifying/changing/storing them somewhere or using any kind of update, delete , drop or insert query.
I read it as though you were trying to have the code update the user's password (which would be a colossal problem from a security perspective)
Seriously, though, STILL I would suggest you not doing it this way, and instead diverting it to the profile area.
You are receiving the password from the user in plain text which can be intercepted; SMF does not do so - the only time SMF gets the password in plain text is when a user registers or changes their password, it is encrypted again on the client before sending.
But my original point stands, SHA1(strtolower($username) . $password) is how it is done in the database.
No offenses, but I want to know where you get the gall to ask how something is coded, then when one of the Developers tells you, you go and say he's wrong.
1. Arantor knows a lot more about SMF's coding than most of us ever will.
2. If you think he's wrong, then tell us how it is done, so the dev team can change it, because if they don't know how it's done, then, well, it must not be done right.
3. Also, if a dev team member explains that doing something a certain way would be bad, then guess what? Doing it that way is a bad idea.
Lainaus käyttäjältä: Arantor Beeblebrox the First - joulukuu 08, 2013, 05:30:01 IP
the only time SMF gets the password in plain text is when a user registers or changes their password, it is encrypted again on the client before sending.
What if some user wants to update his account settings, then it requires password again, what about that password required?
If its client sided I am assuming use of javascript?
Actually I have made a script to change account settings, because in default SMF forum, if you allow members to change account settings, then they can change their registeration date, their post counts, and some other stuff, I want the members to be able to change only the following things:
Change there email
Change there forum name
I don't want user to be able to change anything else. Only administrator should be able to do all the other changes , no one else.
The script for changing those things is ready, but when I saw change account settings page in user profile, then it requires password to change stuff for security reasons, so I wanted to apply that condition to my change account settings script too, so that it becomes more secure.
Lainaus käyttäjältä: BurkeKnight - joulukuu 08, 2013, 05:37:30 IP
If you think he's wrong, then tell us how it is done, so the dev team can change it, because if they don't know how it's done, then, well, it must not be done right.
I am just asking for help, obviously I don't know about it,
i tried to search loginandout.php in sources and found this:
sha1(strtolower($user_settings['member_name']) . un_htmlspecialchars($_POST['passwrd']))on your request. Thanks.
I told it was wrong because my string was not compared (the entered and stored password), thats why I said it wrong, not questioning developer or anything else. I am just trying to understand SMF.
well, you are also incorrect with this
Lainaus käyttäjältä: anir - joulukuu 09, 2013, 04:39:42 AP
because in default SMF forum, if you allow members to change account settings, then they can change their registeration date, their post counts, and some other stuff, I want the members to be able to change only the following things:
If this is true, then you have majorly screwed up permissions... because, in the default SMF only admins can change those settings.
Look at your profile on THIS site.... those are the things that a user can change on a standard, default, installation of SMF.
Yup, permission to change some of the other stuff is indeed separate from being able to access account settings. Date registered for example requires moderate_forum, as does post count.
You will, as admin, implicitly have the ability to change these because admins always have every permission. I suggest you try it with a non admin account and see for yourself.