On 2014-04-23 11:37, Stephen Russell wrote:
Never join the tables. You are either finding A ROW or not in the
hashed
up table.
In the past I have put in the poor passwords into a table and just see
if a
user is attempting to set theirs to anything in my list.
I use a guid for the keys and I will mix up the guid's sequence in
generation of the "filler" to accompany their password. If you use an
INT
as a key you have to find another method.
So it'd be something like this:
FUNCTION CheckLogin(tcClientID as String, tcUserID as String, tcPassword
as String) as Logical
LOCAL llOK as Logical, lcPassword as String, lcSQL as String
lcPassword = this.SaltAndHash(tcPassword,this.nTimesToSaltAndRehash)
TEXT TO lcSQL PRETEXT 15 NOSHOW TEXTMERGE
SELECT cKey
FROM MySaltedHashedPasswords
WHERE cClientID = tcClientID and cUserID = tcUserID and cPassword =
lcPassword
LIMIT 1
ENDTEXT
IF this.RunSQL(lcSQL,'curCount') = 1 THEN && function returned with 1
matching record...grant access
llOK = .T.
ENDIF
RETURN llOK
ENDFUNC && CheckLogin(tcClientID as String, tcUserID as String,
tcPassword as String) as Logical
Seem right?
_______________________________________________
Post Messages to: [email protected]
Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox
OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech
Searchable Archive: http://leafe.com/archives/search/profox
This message:
http://leafe.com/archives/byMID/profox/[email protected]
** All postings, unless explicitly stated otherwise, are the opinions of the
author, and do not constitute legal or medical advice. This statement is added
to the messages for those lawyers who are too stupid to see the obvious.
