Secret Word Hack

[Parker Clack]

When members sign up to the board they will often times change email addresses but then they don't update their profile to reflect this email change. They then lose their password and the script cannot send them one because the email address doesn't work anymore. This script allows your members to have the option of adding a secret word that will allow them to put in a new email address. They can then go ahead and have the script email them the password reset and they can get back onto the board without you having to look up their account. Now if they forget their password and their secret word well...

Make back ups of all the script and template files that you are about to make as there are several.

My thanks go to Chen (aka Firefly) for assistance with the coding needed to get this to work right.

Note: This file as been updated on 6.25.2001.

After working with this on several sign ups I have found that the section that I added to the user.php file will over write the secret code if you moderate your board or change any member information from the admin control panel. This updated file contains the changes to the user.php file and the rest of the file changes. If you have already installed this hack you only need to make the changes to the user.php as written. Nothing else has changed. If this is your first time installing it go with the layout as in the hack.

Parker

[jeo]

im installing it right now.......Thanks! :)

[Parker Clack]

Screen shots

[Parker Clack]

Screen shot:

[Parker Clack]

Screen shot:

[Parker Clack]

Last screen shot:

[Velocd]

My tip is just don't forget your password. If you can remember the secret word, you should also remember your password (since its more important).

Good idea though, but I think a "secret question" hack providing the questions would be better. Like "What is your mom's maiden name?" And then you supplying an answer.

[Parker Clack]

Velocd:

Good suggestion. Want to write that up?

Parker

[Chris M]

Great Parker:)

Just what I was hoping you would do:)

Satan

[JJR512]

I have installed it and been looking over it...and something occurred to me.

You start this process as an unlogged-in member. The system has no idea who you are. You click the link to use if you've lost your password. On the lost password form, you click the new link that's there as part of this hack that takes you to a new form where you put in your secret word and new email address.

Because you never had to tell the system who you are, the system must look for the secret word in the database, then modify the account (by changing the email address) that the secret word was found in.

But what if more than one person should happen to be using the same secret word? Suppose someone else has used the same secret word that I did; if I then go through the lost pw process and put in that secret word, couldn't the system find the other person's account first, reset that account with my new email address, and reset that account's password?

[Parker Clack]

Justin:

If you look over the code it checks to see if you have a userid from a cookie and then compares that to the database and the secret words.

or

if ($bbuserinfo['userid'] == 0 or $permissions['canmodifyprofile'] == 0) {
show_nopermission();

So if the bbuserid is 0 (which it will be if they aren't logged in) then they get the "your aren't logged in " error message.

Then the part that Chen wrote for me:

if ($user) {
$DB_site->query("
UPDATE user SET email = '".addslashes(htmlspecialchars($email))."'
WHERE userid = $bbuserinfo[userid]
");
eval('standarderror("'.gettemplate('redirect_emailupdated').'");');
} else {
eval('standarderror("'.gettemplate('error_infoinvalid').'");');
}
}

If the bbuserid and the secret word don't match they get the "error_infoinvalid" template error message.

Parker

[JJR512]

OK, I understand now.

So it seems that this feature working depends on there being a cookie on the person's computer. Some people may be using the board without cookies, or they may be trying to get in from some other computer. I can see that second thing happening a lot, actually; someone goes to a public computer or a friend's computer, some other computer that isn't their own, and if they have their own browser set to remember passwords, they might not even remember their own password, because they never have to use it.

So I think it may be a good idea if this didn't rely on cookies.

To that end, perhaps on the form where it asks for your secret word and new email address, perhaps it could also ask for your username. Then the system would check if the username and secret word match, and go from there.

[Parker Clack]

I will look into adding a Username check. I am also thinking of adding a check for things like "mother's maiden name", "name of family dog" that sort of stuff. I just haven't had the time to write that yet.

Parker

[Bro_Joey_Gowdy]

Nice Hack

[JJR512]

If using a system like "mother's maiden name" or other secret question/secret answer systems like you've suggested, I'd like to suggest that the answer be stored in the user's profile in encrypted form, like passwords.

[Parker Clack]

Justin:

Changing the script as written look in member.php for

$user = $DB_site->query_first("
SELECT email,userid,secret FROM user
WHERE secret='".addslashes($secret)."' AND userid = $bbuserinfo[userid]
");

and change to

$user = $DB_site->query_first("
SELECT email,userid,secret FROM user
WHERE secret='".addslashes(md5($secret))."' AND userid = $bbuserinfo[userid]
");

in register.php change

'".addslashes($secret)."',

change to

'".addslashes(md5($secret))."',

and admin/user.php

'".addslashes($secret)."',

change to

'".addslashes(md5($secret))."',

Look for

$pwinclude="";
if ($apassword!="") {
$pwdinclude=",password='".addslashes(md5($apassword))."'";
}

and below this add:

$secretinclude="";
if ($secret!="") {
$secretinclude=",secret='".addslashes(md5($secret))."'";
}

then below this change

'".addslashes($secret)."',

to

$secretinclude,

and change

makeinputcode("Secret Word","secret",$user[secret],0);

to

makeinputcode("Secret Word<br>Leave blank unless you want to change it","secret");

Parker

[JJR512]

While Parker was writing and posting his reply to my suggestion, I was figuring out how to do it on my own, and while I was at it, I also incorporated my other idea, which is to ask you for your username rather than relying on a possibly non-existant cookie. I also incorporated Velocd's idea of using a question/answer system rather than a secret word by itself. The way I have done it is that the user specifies both the question and the answer. I had originally thought to use a list of questions in a drop-down menu box that the user could select, but that would have been more complicated coding than I felt like doing right now, and my way gives the user more freedom. There's no inherent advantage or disadvantage do doing it either way, from a practical standpoint.

I have attached a text file that is basically Parker's original instructions with my modifications. If you have already installed his original version, you will need to have your users enter a secret question and specify a new secret answer (existing secret words are not imported, as they are not encrypted and thus unusable, and I suppose I could have written into the script something to encrypt the old secret words, but since the user has to go to the profile to put in a secret question anyway, then they can just go ahead and put in the answer themselves without me having to figure out how to write that extra bit of code!).

[Paul]

Justin,

Your changes are excellent. Thanks to Parker for another great and useful solution! I will be installing this shortly. I'm surprised it's actually not in vB by default.

Paul

[Parker Clack]

Taking Justin's suggestion for encrypting the secret word in my original version of this script I have written a second version with the file changes needed.

I appreciate Justin's work into this and for his version. This gives you the ultimate choice of deciding which one that you would prefer to have on your site.

This version works the same as the original it just encrypts all the secret words in the database.

Note: This file has been updated as of 6/25/2002

After working with this on several sign ups I have found that the section that I added to the user.php file will over write the secret code if you moderate your board or change any member information from the admin control panel. I have made the necessary changes to the admin/user.php file as needed. Just download the script and make the changes in the user.php section. If you have not installed this hack just follow the outline in the hack.

Parker

[Paul]

A more "secure" and user-friendly approach to this hack would be the following:

1. Requiring predefined questions which become part of the authentication procedure (entering in a username and seeing a question isn't a good idea from a security standpoint).

2. Converting the answer to lowercase before processing the md5 hash. ("What is my favorite flavor of ice cream?" A: "Strawberry" is not the same as "strawberry")

3. Creating an md5 hash of the secret answer prevents the administrator from making a visual determination to see if "Main Street" and "Main St." are actually both the correct answer. If the user cannot remember their password, chances are they won't recall the exact spelling and punctuation used in their answer.

Any thoughts?

Paul

Edit: These comments apply to Justin's version of the hack.

I'm assuming the easiest way to do this would be a strtolower() around any processing of secret_a and creating another table with the various questions and an id number (reducing the overall size of the database) (i.e. "What is the name of the town you were born in?" = "2")

secret_q would then have a value of "2"

I'll try doing this myself tomorrow, but I have a limited knowledge of the workings of vb :D

[JJR512]

I have updated my version, attached in Post #17 (https://vborg.vbsupport.ru/showthread.php?postid=265159#post265159) (above), to incorporate some suggestions from Parker Clack. The change basically checks to see if the person has a secret question/answer before it tries to take the person through the process of answering the secret question.

LoveShack, I'm not sure if I understood what you meant by your Point #1 above. Whether the system uses predefined questions or lets users make up their own questions, either way, the question is going to be visible to anyone who wants to see it. I think if the user can make up his own question/answer, he/she is more likely to use something that he/she can easily remember. Either way has advantages and disadvantages. I happen to like the way I did it, which is why I did it that way; you want it another way, and are going to code that for yourself, so now, like Parker said, we will have even more choices! :)

(BTW, the added complexity that you alluded to at the end of your post is part of the reason why I avoided going that way! :D)

I agree that making everything work as lower-case would be a good idea, and I'll work that in sometime tonight, and update my post again.

Regarding your Point #3, I understand what you're saying...I think that using unencrypted answers might be a better idea if you're using predefined questions, per your other suggestion. But for my version, allowing the user to make up his own question, I don't think many people would be too keen on the idea of putting in a question like, "What is my mother's maiden name?" if they know that I'll be able to see the answer. I could take that answer and use it to find out all kinds of things about that person and commit all kinds of fraud. Not that I would, of course, but what I'm saying is that some people will know that that kind of thing is possible. If you use a predefined question you could make a question that people wouldn't care if the board owner could see the answer or not. This is the same kind of debate, pretty much, that raged when vBulletin switched the password system to MD5, as well. There are some advantages to being able to see the passwords. But having them be encrypted was deemed to be more important, so I figured those reasons pretty much applied here, too.

[Paul]

Hi,

Originally posted by JJR512
LoveShack, I'm not sure if I understood what you meant by your Point #1 above. Whether the system uses predefined questions or lets users make up their own questions, either way, the question is going to be visible to anyone who wants to see it.

Not necessarily. In the suggestion I made, one would have to choose the correct question and correct answer making both a part of the authentication procedure. For example, suppose a drop-down box was used with three questions. You would need to pick the correct question from the drop down box and supply the correct answer in order to be able to change the e-mail address.

(BTW, the added complexity that you alluded to at the end of your post is part of the reason why I avoided going that way! :D)

Added complexity in this case is added security.

I agree that making everything work as lower-case would be a good idea, and I'll work that in sometime tonight, and update my post again.

Pretty simple to do. Just use strtolower();

Regarding your Point #3, I understand what you're saying...I think that using unencrypted answers might be a better idea if you're using predefined questions, per your other suggestion. But for my version, allowing the user to make up his own question, I don't think many people would be too keen on the idea of putting in a question like, "What is my mother's maiden name?" if they know that I'll be able to see the answer. I could take that answer and use it to find out all kinds of things about that person and commit all kinds of fraud. Not that I would, of course, but what I'm saying is that some people will know that that kind of thing is possible. If you use a predefined question you could make a question that people wouldn't care if the board owner could see the answer or not. This is the same kind of debate, pretty much, that raged when vBulletin switched the password system to MD5, as well. There are some advantages to being able to see the passwords. But having them be encrypted was deemed to be more important, so I figured those reasons pretty much applied here, too.

You clearly would not use a question such as "What's your mother's maiden name," simply because it's a question frequently used in banking. Rather, by using predefined questions you could narrow the possibility that you'd be intruding on privacy issues and get a more identifying piece of information. For example, "Who was your fourth grade social studies teacher?"

Encrypting the answers would mean that Mrs. Johnson != Mrs Johnson != Harriet Johnson != Miss Johnson, simply because you couldn't visually make a determination as to what the correct answer is supposing the person e-mailed you.

After evaluating this hack and taking all these situations into consideration, my development team decided that this was creating more of a problem than it was potentially solving. A good hack for those who want such a system though. Kudos for creating it.

Paul

[JJR512]

The "added security" that would allegedly result from making the user select a question from a drop-down box, in addition to having to correctly answer that question, is, in my opinion, not truly any more secure of a system than just having a secret word, as the original form of this hack was, except that now the user has to remember two things, the question and the answer, as opposed to just one, and let's remember, the user is doing this in the first place because he couldn't remember something. The whole point of the question, at least the way I see it, is that it's there to help jog the memory of the user. The way my version works isn't really any different from the way Parker's original version works; the user has to remember one thing, whether it's called a "secret word" or "secret answer". The question serves no practical purpose as far as how this system works is concerned; its sole purpose is to help the user remember what his secret word (or "answer") is.

Pretty simple to do. Just use strtolower();
Yes, it was. I knew how to do it; I just had to take the time to do it. I believe I replaced all occurances of md5($secret_a) with md5(strtolower($secret_a)). I will change the attachment in my earlier post with the newer version right after I submit this reply.

I understand what you're saying about having the answer encrypted. This debate as to the value of leaving it in plain text has already taken place, when the vB team switched the password system to use encryption. So believe me, I understand; I've seen it all before. My point of view is this. The user will be using this system because he couldn't remember his password. If he can't remember his password, why should I think he'll have better luck remembering a question that might be meaningless to him personally, and the answer to that as well? This is why I want the user to be able to make up his own question, because it will most likely be something that means something to him. And because the question means something to him, so will the answer, and it won't be something he's likely to forget. For the user to feel comfortable using such a personal question, he needs to feel secure that his answer is secure.

There is no way that this can create "more of a problem" than it is solving. Without this system, if a use forgot his password, he was going to be contacting you for help. This system gives the user a fall-back system to use in case he forgets his password, that potentially allows him to recover from the situation without needing to contact you. If he can't remember his secret answer and can't get in, he's going to contact you. It's not this system is going to make people contact you when they would otherwise have had no reason to do so.

So, like I said, we have choices. Anyone who likes my version can use mine; anyone who likes Parker's version can use his; anyone who likes whatever you might post can use yours; and anyone who wants something else that's slightly different from anything we've done so far can either make it themselves, or suggest it here and maybe one of us will incorporate that suggestion into a new version. :)

[Parker Clack]

I have made changes to the admin/user.php file in both versions of the hack that I wrote. The only difference between the two files is that one encrypts the secret word and the other one doesn't.

If you have already installed the hack the only changes that were made were to the admin/user.php file. The rest of the hack is unchanged. This was necessary are the script as written was over writing the secret word if you used the admin control panel to change any of the member's information or after a member signed up.

If this is the first time you have installed this hack then just follow it as outlined in the hack.

Remember to make back ups of any of the files that you have changed.

I apologize for any inconvience that this might have caused.

Parker