Thanks guys, but again, does anyone know why CF Validation doesnt see that user has altered text in password box and it needs to run validation again for new input?
<Ajas Mohammed /> http://ajashadi.blogspot.com We cannot become what we need to be, remaining what we are. No matter what, find a way. Because thats what winners do. You can't improve what you don't measure. Quality is never an accident; it is always the result of high intention, sincere effort, intelligent direction and skillful execution; it represents the wise choice of many alternatives. On Mon, Mar 9, 2009 at 12:39 PM, Shane <studio...@gmail.com> wrote: > It was an intranet. Going with 20 I knew I didn't have to worry about the > password layer and the users didn't mind (after the first shock). The > company only had 140 employees. I agree for many companies / scenarios it > wouldn't work. > > -----Original Message----- > From: ad...@acfug.org [mailto:ad...@acfug.org] On Behalf Of Dean H. Saxe > Sent: Monday, March 09, 2009 11:35 AM > To: discussion@acfug.org > Subject: Re: [ACFUG Discuss] Password CFinput regular expression - throws > alert/error after correction also > > That policy wouldn't fly in the real world for most apps. And if you go > that far... I'd just find other avenues of attack. > > If you think you need such strong passwords, you're better off going to an > RSA token or one time pad type of authentication system. > > -dhs > > > Dean H. Saxe, CISSP, CEH > d...@fullfrontalnerdity.com > "[T]he people can always be brought to the bidding of the leaders. > This is easy. All you have to do is to tell them they are being attacked, > and denounce the pacifists for lack of patriotism and exposing the country > to danger. It works the same in every country." > --Hermann Goering, Hitler's Reich-Marshall at the Nuremberg Trials > > > > On Mar 9, 2009, at 12:30 PM, Shane wrote: > > > Brute force. > > > > Mathematically - 20 chars is overkill. But using 20 chars pretty much > > ensures the user cannot pick a weak phrase. I agree 15 should be more > > than adequate. But I have enforced 20 chars at one location - and > > after the initial grumbling the users told me they didn't mind much > > since they could use an easily remembered phrase. I also let them go > > 6 months between password changes. Again it's all a balancing act but > > I would rather them have it six months in their head verses 1 month on > > their monitor. > > > > I know there are other considerations when it comes to password > > expiration but....... > > > > > > > > -----Original Message----- > > From: ad...@acfug.org [mailto:ad...@acfug.org] On Behalf Of Dean H. > > Saxe > > Sent: Monday, March 09, 2009 11:22 AM > > To: discussion@acfug.org > > Subject: Re: [ACFUG Discuss] Password CFinput regular expression - > > throws alert/error after correction also > > > > But when you say cracking, you'd have to have the password hashes to > > crack. > > And if they are salted hashes then you are FUBAR, there are no rainbow > > tables for that. > > > > Now, if you're talking brute force attacks, its a different story. > > And that's why a lockout policy is important. > > > > Finally, a 20 character minimum for a passphrase is ridiculous. If > > you just consider 52 chars (upper/lower, no spaces or punctuation) a > > 15 character passphrase has 5.5 X 10^25 values. Your aforementioned > > password poliicy (8 chars, at least 1 numeric) has a minimum > > complexity of 52^7*10 or 1.0 X 10^13, significantly lower than the 15 > > character passphrase. So... what kind of complexity are you really > > looking to enforce? > > > > -dhs > > > > > > Dean H. Saxe, CISSP, CEH > > d...@fullfrontalnerdity.com > > "I have always strenuously supported the right of every man to his own > > opinion, however different that opinion might be to mine. He who > > denies another this right makes a slave of himself to his present > > opinion, because he precludes himself the right of changing it." > > -- Thomas Paine, 1783 > > > > > > On Mar 9, 2009, at 12:08 PM, Shane wrote: > > > >> I agree that users do choose poor passwords. But even using an > >> extended character set you see them choose passwords like "T!mmy". > >> From a cracker's point of view there is little difference between > >> Timmy and T!mmy. > >> > >> I definitely agree that long pass phrases are best all around - even > >> using words. Set the min length at 20 and let the user choose > >> whatever they want. > >> > >> I just brought up the point because I have seen more than one > >> website, including my bank, that forces an extended char set but > >> limits the password length to a MAX of 8 characters. Yeesh. > >> > >> Security in layers - everything is a compromise. > >> > >> Shane Heasley > >> www.CTek-Media.com > >> > >> -----Original Message----- > >> From: ad...@acfug.org [mailto:ad...@acfug.org] On Behalf Of Dean H. > >> Saxe > >> Sent: Monday, March 09, 2009 10:54 AM > >> To: discussion@acfug.org > >> Subject: Re: [ACFUG Discuss] Password CFinput regular expression - > >> throws alert/error after correction also > >> > >> I'm not sure I totally agree with you. > >> > >> Yes, the math is not good when you force character sets like this, > >> but the reality is that users choose bad passwords. > >> http://www.schneier.com/essay-144.html > >> The enforcement of complex passwords improves overall complexity for > >> most users. > >> > >> From the social engineering side, you are right, users may write down > >> their passwords. But you'd have to find the password to break in, as > >> opposed to guessing the password from a large, complex pool. So its > >> a balancing act. > >> > >> My suggestion is the use of passphrases such as "yellow polkadot > >> pancakes". > >> You trade length for complexity but increase the ability of > >> memorization. > >> If you then add in some kind of special characters or "leet speak" > >> the > >> passwords are extremely difficult to guess or break. > >> > >> Finally, all of this is useless if you allow the passwords to be > >> recovered or you don't enforce server-side lockouts to slow/stop > >> brute force attacks against passwords. There's a lot more to do than > >> just enforce good passwords if you want to have a secure > >> authentication system. > >> > >> -dhs > >> > >> > >> Dean H. Saxe, CISSP, CEH > >> d...@fullfrontalnerdity.com > >> "What is objectionable, what is dangerous about extremists is not > >> that they are extreme, but that they are intolerant." > >> -- Robert F. Kennedy, 1964 > >> > >> > >> On Mar 9, 2009, at 11:46 AM, Shane wrote: > >> > >>> This is off topic - but I thought I would throw it in for free: > >>> > >>> Forcing an extended character set (upper case, numbers, special > >>> characters) on the user frequently does not lead to good security. > >>> > >>> First, from the mathematical side, the length of the password has > >>> much more bearing on how difficult it is to crack than the added > >>> complexity gained from using an extended character set. So > >>> sliggyfiverbotgar is much harder to crack than ^%tgYh. As a > >>> practical matter, passwords longer than 10 characters are not > >>> generally breakable - even when composed of mostly English words. > >>> Each extra character adds so many permutations that you need to be > >>> the NSA to brute force longer passwords. > >>> > >>> On the social engineering side. If you force average users to use > >>> an extended character set they have a hard time remembering them. > >>> If they can't easily remember them they write them down and all too > >>> frequently post them next to their monitor. It's all a balancing > >>> act > >>> - and it varies by situation. I usually go for what you have - > >>> minimum of 8 characters, with at least one number. Sometimes I > >>> require mixed case also. I don't force special characters as that > >>> tends to make too many users write down their passwords. > >>> From: ad...@acfug.org [mailto:ad...@acfug.org] On Behalf Of Ajas > >>> Mohammed > >>> Sent: Monday, March 09, 2009 10:28 AM > >>> To: discussion@acfug.org > >>> Subject: [ACFUG Discuss] Password CFinput regular expression - > >>> throws alert/error after correction also > >>> > >>> Hi there, > >>> > >>> I have this code which checks if password is strong i.e. atleast 8 > >>> characters long, consiting of one Upper case and one Lower case and > >>> one Number.and if not alerts the user about it. I am using a regular > >>> expression to do this as u can see from code below. The problem is > >>> that once the alert is displayed, even if the user corrects the > >>> error and enters a strong password, the error alert does not go > >>> away. For example, if i entered password for the first time, then > >>> obviously I will get alert saying password is not strong. Then, > >>> afterwards if i correct password to be lets say Leave1234 which is 9 > >>> chars, has one uppper case, one lower case and has a number also, I > >>> still end up getting password not strong message. I tried removing > >>> onBlur,OnSubmit one at a time but doesnt work. > >>> > >>> Any ideas???? > >>> > >>> Here is the code > >>> > >>> New Password: > >>> <!--- some possible regular expressions i used new_password ---> > >>> <!--- ^(?=.*\d)(?=.*[a-z])(?=.*[A-Z]).{8,}$ or ---> > >>> <cfinput type="password" name="new_password" > >>> validate="regular_expression" pattern="^(?=.*\d)(?=.*[a-z])(?=.*[A- > >>> Z]).{8,}$" validateat="onBlur,onSubmit,onServer" message="Your > >>> password is not strong. Your password should be atleast 8 characters > >>> long, consiting of one Upper case and one Lower case and one > >>> Number." > >>>> > >>> > >>> <Ajas Mohammed /> > >>> http://ajashadi.blogspot.com > >>> We cannot become what we need to be, remaining what we are. > >>> No matter what, find a way. Because thats what winners do. > >>> You can't improve what you don't measure. > >>> Quality is never an accident; it is always the result of high > >>> intention, sincere effort, intelligent direction and skillful > >>> execution; it represents the wise choice of many alternatives. > >>> No virus found in this incoming message. > >>> Checked by AVG - www.avg.com > >>> Version: 8.0.237 / Virus Database: 270.11.9/1990 - Release Date: > >>> 03/08/09 17:17:00 > >>> > >>> > >>> ------------------------------------------------------------- > >>> To unsubscribe from this list, manage your profile @ > >>> http://www.acfug.org?fa=login.edituserform > >>> > >>> For more info, see http://www.acfug.org/mailinglists Archive @ > >>> http://www.mail-archive.com/discussion%40acfug.org/ > >>> List hosted by FusionLink > >>> ------------------------------------------------------------- > >> > >> > >> > >> ------------------------------------------------------------- > >> To unsubscribe from this list, manage your profile @ > >> http://www.acfug.org?fa=login.edituserform > >> > >> For more info, see http://www.acfug.org/mailinglists Archive @ > >> http://www.mail-archive.com/discussion%40acfug.org/ > >> List hosted by http://www.fusionlink.com > >> ------------------------------------------------------------- > >> > >> > >> > >> No virus found in this incoming message. > >> Checked by AVG - www.avg.com > >> Version: 8.0.237 / Virus Database: 270.11.9/1990 - Release Date: > >> 03/08/09 > >> 17:17:00 > >> > >> > >> > >> ------------------------------------------------------------- > >> To unsubscribe from this list, manage your profile @ > >> http://www.acfug.org?fa=login.edituserform > >> > >> For more info, see http://www.acfug.org/mailinglists Archive @ > >> http://www.mail-archive.com/discussion%40acfug.org/ > >> List hosted by http://www.fusionlink.com > >> ------------------------------------------------------------- > >> > >> > >> > > > > > > > > ------------------------------------------------------------- > > To unsubscribe from this list, manage your profile @ > > http://www.acfug.org?fa=login.edituserform > > > > For more info, see http://www.acfug.org/mailinglists Archive @ > > http://www.mail-archive.com/discussion%40acfug.org/ > > List hosted by http://www.fusionlink.com > > ------------------------------------------------------------- > > > > > > > > No virus found in this incoming message. > > Checked by AVG - www.avg.com > > Version: 8.0.237 / Virus Database: 270.11.9/1990 - Release Date: > > 03/08/09 > > 17:17:00 > > > > > > > > ------------------------------------------------------------- > > To unsubscribe from this list, manage your profile @ > > http://www.acfug.org?fa=login.edituserform > > > > For more info, see http://www.acfug.org/mailinglists Archive @ > > http://www.mail-archive.com/discussion%40acfug.org/ > > List hosted by http://www.fusionlink.com > > ------------------------------------------------------------- > > > > > > > > > > ------------------------------------------------------------- > To unsubscribe from this list, manage your profile @ > http://www.acfug.org?fa=login.edituserform > > For more info, see http://www.acfug.org/mailinglists Archive @ > http://www.mail-archive.com/discussion%40acfug.org/ > List hosted by http://www.fusionlink.com > ------------------------------------------------------------- > > > > No virus found in this incoming message. > Checked by AVG - www.avg.com > Version: 8.0.237 / Virus Database: 270.11.9/1990 - Release Date: 03/08/09 > 17:17:00 > > > > ------------------------------------------------------------- > To unsubscribe from this list, manage your profile @ > http://www.acfug.org?fa=login.edituserform > > For more info, see http://www.acfug.org/mailinglists > Archive @ http://www.mail-archive.com/discussion%40acfug.org/ > List hosted by http://www.fusionlink.com > ------------------------------------------------------------- > > > >
