Hi, I never bind the password field directly to the attribute. If the password is entered by the user, I put 2 field and compare them before saving so I uses 2 variables inside the component.
Some notes about password... - If you need strong passwords, never allow the user to enter their password, humans do not have good entropy. It is usually far better to generate a 6 chars random string than a user specified password. - Always salt passwords. Ideally with a random string at least as long as the password. You will need to store the salt somewhere with the hashed password. In my user access and authentication framework, I put it before the hash in the password attribute. - Uses time (and ideally a resource) consuming algorithm for the hashing to make brute force really hard. A PKDF2 with few 1000 iterations or bcrypt does well. You can easily go to 250ms of computing time to hash a password, for long term and high security, some go to more than 1 second. This may even help for bad passwords. SHA is now way too fast with GPU and custom ASIC, you would need billons of iterations to have a significant slowing of brute force. - Requiring frequent passwords change is useless, even lower the security it is now finally recognized by the NIST. A good password need to be changed only when compromised. - Requiring mix capitals letters of symbols does not really helps, people still uses dictionary works by replacing commun letter with numbers. Dictionary attacks know there tricks. Samuel > Le 23 mai 2017 à 06:26, getsh...@gmail.com a écrit : > > 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) >> Help/Unsubscribe/Update your Subscription: >> https://lists.apple.com/mailman/options/webobjects-dev/getsharp%40gmail.com >> <https://lists.apple.com/mailman/options/webobjects-dev/getsharp%40gmail.com> >> >> This email sent to getsh...@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/samuel%40samkar.com > <https://lists.apple.com/mailman/options/webobjects-dev/samuel%40samkar.com> > > This email sent to sam...@samkar.com <mailto:sam...@samkar.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/archive%40mail-archive.com This email sent to arch...@mail-archive.com
