On 2014-04-23 15:44, Ed Leafe wrote:
You would generate a new salt when they update their password, and save that salt with the user. If they submit their old password, the new salt will result in an invalid hash.
Thanks Kevin and Ed for following up on this. I just took one of those 5-hour energy shots so if I ramble, that's why. lol
So we store the password in a DIFFERENT table from the Users table, and in the Users table we stored the Salt value (set via SYS(2015) to make it random), which is encrypted with your master encryption key of course before being stored in that field in the User table. SO...we then look up the ClientID + UserID in the User table, then grab the Salt key value, THEN we search the Passwords table for the SALTED and HASHED key of the 3 part combination: ClientID + UserID + Password. Thus, when the user changes his password, the new random Salt key stored in the Users table for his record (cClientID and cUserID fields) makes sure that his old passwords are invalid. Plus, this adds to the security by obesity approach Kevin mentioned.
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.
