Sorry Ajas!
 
I'll try to look at your code this afternoon.
 
Shane

  _____  

From: ad...@acfug.org [mailto:ad...@acfug.org] On Behalf Of Ajas Mohammed
Sent: Monday, March 09, 2009 11:56 AM
To: discussion@acfug.org
Subject: Re: [ACFUG Discuss] Password CFinput regular expression - throws
alert/error after correction also


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
-------------------------------------------------------------






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
-------------------------------------------------------------

Reply via email to