Apple

It uses a different salt for each password,
It handles version control automatically (we used to have code to handle when we migrated from one hash algorithm to another), and
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, email@hidden 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 <email@hidden> 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 (email@hidden)
Help/Unsubscribe/Update your Subscription:

This email sent to email@hidden

_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:

This email sent to email@hidden

References:
	>Tip request: How to avoid coercing twice in NSValidation (From: Riccardo De Menna <email@hidden>)
	>Re: Tip request: How to avoid coercing twice in NSValidation (From: email@hidden)