Useful to keep in mind.
https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet
On 5/23/17 7:26 AM, Morris, Mark wrote:
I know this is off topic, but I would recommend BCrypt for your
passwords. It has 3 features that make it better than simply hashing
your passwords:
1. It uses a different salt for each password,
2. It handles version control automatically (we used to have code to
handle when we migrated from one hash algorithm to another), and
3. It has a parameter to control how computationally expensive the
process is, so as hardware gets faster you can easily keep pace.
I’ve heard that there are newer schemes out there that also have these
advantages, so I’m sure they are good as well, but I wouldn’t stick
with just running it through a SHA256 or similar hash.
Back on topic, I take Sharpy’s approach. ;-)
Regards,
Mark
On May 23, 2017, at 5:26 AM, getsh...@gmail.com
<mailto:getsh...@gmail.com> wrote:
Hi Riccardo,
I’m interested in how others deal with this too.
My approach is to never bind directly to the password attribute.
With forms that persist a password value I bind to a component ivar,
check validity on the raw string to whatever my password policy might
dictate (in the component’s action method) then call the password
attribute setter passing the digested string.
Sharpy..
On 23 May 2017, at 7:33 pm, Riccardo De Menna <deme...@tuorlo.net
<mailto:deme...@tuorlo.net>> wrote:
Hi all,
I have a request for tips on how to properly perform a task…
Whenever I have to deal with database fields that contain passwords
I generally use some sort of ‘digest’ as early as possible and then
only store and compare the digested data. I’d like to apply this
digest in the validateValueForKey method of my EOGenericRecord
subclass, coercing the value, but I’m having problems because
validateValueForKey gets called twice, first at component validation
level and then when things are actually saved (I think it’s called
by validateTakeValueForKeyPath first and validateForSave later right?).
Result: My digest algorithm is applied twice and this obviously
messes up with the whole thing.
What should I do to avoid this?
One idea would be to intercept component validation on
validateTakeValueForKeyPath and skip coercion there. Or skip it
later on the validateForSave.
What would be the right way? Also… is it somehow guaranteed that
validation happens twice? Could it happen three times? More? If so,
my idea would not work.
What do you think?
Riccardo
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@lists.apple.com
<mailto:Webobjects-dev@lists.apple.com>)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/getsharp%40gmail.com
This email sent togetsh...@gmail.com <mailto:getsh...@gmail.com>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@lists.apple.com
<mailto:Webobjects-dev@lists.apple.com>)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/mark.morris%40experian.com
This email sent tomark.mor...@experian.com
<mailto:mark.mor...@experian.com>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/ray%40ganymede.org
This email sent to r...@ganymede.org
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
