And how do you handle getting rid of prior access when the user updates
his password? You don't want his old password to work.
On 2014-04-23 12:11, Kevin Cully wrote:
Yes, any of my suggestions might be overkill for any particular
situation. I'll trust you to choose the points that you would like to
implement.
I suggest storing the passwords in a separate table because of the
"Security By Obesity" concept. By storing the values in another
table, this opens up the possibility of storing that table in another
database, perhaps on another server.
On another note, do not use MD5. Use a stronger, slower hashing
mechanism. MD5 is no longer considered a secure hashing mechanism,
partly because it is fast. SCrypt or BCrypt or PBKDF2 are slower, and
help prevent brute force attacks on your system.
On 04/23/2014 11:31 AM, [email protected]
wrote:
- 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??
[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/[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.
