On Wed, Apr 23, 2014 at 10:31 AM, < [email protected]> wrote:
> Wow! > - Loop it a few times?!? Interesting (and yet so very easy). > - I'm already salting them. > - The Rainbow table is the one that says "don't let the user pick any of > these passwords, like 'Password123'", right? > - If these things are so 1-way (not able to be decrypted in any > way/shape/form), then why store them in a separate table from the UserID? > I get the security by isolation but still...overkill in this case?? > - Security by obesity...nice...so I just throw in an extra insert before > and after the real insert, using some random string like SYS(2015)? Then > the check goes to see how many records match the SQL JOIN of Users to > Passwords based on ClientID+UserID+Password? If > 0 then grant access. > Right? > - Would you like to play a nice game of chess? :-) > > ---------- 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. > > > > On 2014-04-23 11:07, Kevin Cully wrote: > >> -- Never store encrypted passwords, only hashed+salted passwords. >> -- Loop through the hashing+salt process multiple times before storing >> the value. >> -- Do not let the user create a password that is in a rainbow table >> -- Store hashed+salted passwords in their own table independent of the >> user information. >> -- For every new hashed+salted password that is created in the table, >> store a random # of fake hashed+salted passwords before and after the >> real hashed+salted passwords. (See "Security by Obesity") >> -- If the user fails to enter information that matches a USERID and a >> Hashed+Salted password, wait X seconds before informing them. End the >> program if they cannot enter the correct information after X attempts. >> >> >> On 04/23/2014 10:19 AM, [email protected]: >> >>> Right....so it's like a Checksum of sorts that stored and the user's >>> entered password is compared with the checksum that's stored. Ok, hash. >>> Checksum, hash, ...whatever. :-) >>> >>> Thanks, >>> --Mike >>> >>> [excessive quoting removed by server] _______________________________________________ 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/CAJidMYJ3D1_7f29ANJT0-iyo-_C=got48fso-kxxy9puyvm...@mail.gmail.com ** 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.
