On 10/14/05, Ian Vaughan <[EMAIL PROTECTED]> wrote:
> Do you know for any good examples of a strong password generator ?

Here is a basic one.  You can take this and turn it into a custom tag
pretty easy.  It removes easily-confused letters from the string which
makes it more usable but less secure.  Also I am paranoid about
scoping variables and would scope these to the 'variables' scope, but
I removed them so the code would fit better in the message :-)

<cfscript>
myPwd="";
myPwdLen="8";
do {
        RandCharRange=RandRange(0,2);
        switch (RandCharRange)
        {
                case "0":{myPwd=myPwd & chr(RandRange(48,57));break;}
                case "1":{myPwd=myPwd & chr(RandRange(65,90));break;}
                case "2":{myPwd=myPwd & chr(RandRange(97,122));}
        }
        myPwd=ReReplace(myPwd,"(0|o|O|1|i|I|l|5|S)","","all");
} while Compare(Len(myPwd),myPwdLen);
</cfscript>

>Say for example you were going to encrypt the users password that is
>stored in the database, what would you recommend to do this the Hash
>function?

You appear to be investigating hashes, but not salted hashes, which is
what I would stick to exclusively.  Here is a decent article on the
subject:

http://msdn.microsoft.com/msdnmag/issues/03/08/SecurityBriefs/

I find a UUID makes a good salt value.  Store the UUID with the user
record, pull it (via the username they also typed in) and combine the
supplied password with the salt value and hash *that* and compare it
to the value in the db (which you also salted and hashed when you
stored it initially).

As has been pointed out hashes of any kind are one way.  If a user
forgets their password Never, ever ever send a user a password
replacement via email.  Instead have the user replace the password
themselves by sending them an encoded link that expires after a
certain period (I use 24 hrs). When you send out the link, store a
value in the db (a hashed UUID, for example).  Then put that value in
the link you send back to the customer.  When the link comes back
(i.e. they click on the email) Use the hashed value to find the user
record the password change is associated with.  If anyone intercepts
the email they will only have a sting of crud that doesn't give overt
clues as to its nature and which will become useless shortly.  Not
perfect, but better than linking in with UserID=123

Next you must try to authenticate whether this really is the person
who owns the account.  To authenticate the person you have to hit them
with a hint/answer challenge.  When they arrive for the reset, ask
them their secret question.  Without the answer, no soap.  This of
course means you have to give the person the opportunity to put in a
hint and an answer on their first login attempt.  I like to let the
customer write their own question and answer, so they have the freedom
to put something in thats really private... Encrypt the question and
store the answer as a salted hash.

--
--mattRobertson--
Janitor, MSB Web Systems
mysecretbase.com

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
Logware (www.logware.us): a new and convenient web-based time tracking 
application. Start tracking and documenting hours spent on a project or with a 
client with Logware today. Try it for free with a 15 day trial account.
http://www.houseoffusion.com/banners/view.cfm?bannerid=67

Message: http://www.houseoffusion.com/lists.cfm/link=i:4:221034
Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4
Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4
Unsubscribe: 
http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4
Donations & Support: http://www.houseoffusion.com/tiny.cfm/54

Reply via email to