minimum password length check
Shyam...@dell.com
"
CHAP secrets MUST be an integral number of bytes (octets). A
compliant implementation SHOULD NOT continue with the login step in
which it should send a CHAP response (CHAP_R, Section 11.1.4
Challenge Handshake Authentication Protocol (CHAP)) unless it can
verify that the CHAP secret is at least 96 bits, or that IPsec
encryption is being used to protect the connection.
"
The spec suggests that a chap secret be at least 96bits or (12
characters) but I see that only the AUTH_STR_MAX_LEN of 256 characters
is used for error checking.
Am I reading this correctly ?
-Shyam Iyer
Ulrich Windl
> From the spec:
> "
> CHAP secrets MUST be an integral number of bytes (octets). A
> compliant implementation SHOULD NOT continue with the login step in
> which it should send a CHAP response (CHAP_R, Section 11.1.4
> Challenge Handshake Authentication Protocol (CHAP)) unless it can
> verify that the CHAP secret is at least 96 bits, or that IPsec
> encryption is being used to protect the connection.
> "
the secret to 16 characters (AFAIR). I wrote a lottle program that generates
random secrets and estimated the entropy (i.e. number of bits):
With 16 random letters, you are at about 92 bits (e.g. mMPuhxfKAYuIFTjZ)
With 16 random letters with digits you are at about 95 bits (e.g.
b3v4B8mRoiFWjpF9)
The bad thing is that some characters look quite similar so users, like '0'
and'O', or '1' and 'l'. When trying to omit those potentially confusing characters
(plus adding other punctuation characters, leaving out space for obvious reasons),
I'm at about 83 bits (e.g. u\FphNwuuWCT74+h).
As a side note: Passwords with only six letters in one case only make about 28
bits. Now if you think that most users will use words, you can guess how poor
those passwords actually are.
Using the fully printable ASCII characterset without those characters that are
considered "unsafe" in UNIX, 16 characters would have about 102 bits of entropy
(e.g. !)Zbl(p7%Hd88L>T)
>
> The spec suggests that a chap secret be at least 96bits or (12
> characters) but I see that only the AUTH_STR_MAX_LEN of 256 characters
> is used for error checking.
)
Regards,
Ulrich
>
> Am I reading this correctly ?
>
> -Shyam Iyer
>
>
> You received this message because you are subscribed to the Google Groups "open-iscsi" group.
> To post to this group, send email to open-...@googlegroups.com.
> To unsubscribe from this group, send email to open-iscsi+...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/open-iscsi?hl=en.
>
>
Shyam...@dell.com
> http://groups.google.com/group/open-iscsi?hl=en.
> >
> >
>
secret's bit randomness calculation to check if has atleast 96bits of
entropy.
So I guess we should do some thing like this ....
If (check_96bit_entropy(<secret>) && secret < AUTH_MAX_STR_LEN) {
Use_secret ....
}
else {
Secret not strong enough ..throw error...
}
Mike Christie
> So I guess we should do some thing like this ....
>
>
> If (check_96bit_entropy(<secret>) && secret < AUTH_MAX_STR_LEN) {
> Use_secret ....
> }
> else {
> Secret not strong enough ..throw error...
> }
>
We do not check. The only problem would be if we added one now lots of
people are going to get errors in existing set ups. Some might not boot.
Maybe add a error message for a while, then make it mandatory in a later
release.
Ulrich Windl
> Essentially what you are saying is that we haven't implemented the
> secret's bit randomness calculation to check if has atleast 96bits of
> entropy.
>
No, I just wanted to point out that the quality of a secret key cannot simply be
measured with "strlen(password)", and that 96 bits of randomness may require a
longer string as one might initially have guessed.
Regards,
Ulrich
Shyam...@dell.com
> From: open-...@googlegroups.com [mailto:open-...@googlegroups.com]
> On Behalf Of Ulrich Windl
Right I get you right then..
Don't want to rework on getting the entropy of the secret. Do you mind
open-sourcing it so we could do the checks as I detailed in the previous
mail?
Thanks,
Shyam
Ulrich Windl
I don't have the code you are looking for, because what I have is Perl, and it
does _create_ random secrets following a pattern, optionally outputting the
estimated bits of randomness. Originally written to create similar, but different,
not very obvious root passwords for a set of similar machines. Something
completely different...
Regards,
Ulrich
Shyam...@dell.com
> -----Original Message-----
> From: open-...@googlegroups.com [mailto:open-...@googlegroups.com]
> On Behalf Of Ulrich Windl
> Sent: Wednesday, December 16, 2009 1:08 PM
> To: open-...@googlegroups.com
> Subject: Re: minimum password length check
>
> On 15 Dec 2009 at 22:47, Shyam...@Dell.com wrote:
>
> > From the spec:
> > "
> > CHAP secrets MUST be an integral number of bytes (octets). A
> > compliant implementation SHOULD NOT continue with the login step
> in
> > which it should send a CHAP response (CHAP_R, Section 11.1.4
> > Challenge Handshake Authentication Protocol (CHAP)) unless it can
> > verify that the CHAP secret is at least 96 bits, or that IPsec
> > encryption is being used to protect the connection.
> > "
>
> You picked up an "interesting" issue: The Microsoft Initiator limits
> the length of
> the secret to 16 characters (AFAIR). I wrote a lottle program that
> generates
> random secrets and estimated the entropy (i.e. number of bits):
>
> With 16 random letters, you are at about 92 bits (e.g.
mMPuhxfKAYuIFTjZ)
> With 16 random letters with digits you are at about 95 bits (e.g.
> b3v4B8mRoiFWjpF9)
>
What algorithm are you using to arrive at this ...
Googling(and some of my information theory lit..) almost always hints me
to shannon's theorem to find the randomness of a character string ...
Check this
http://www.redkestrel.co.uk/Articles/RandomPasswordStrength.html
Ulrich Windl
As pointed out before, this is the randomness of a string the program creates
itself. So if you unly use the set {A,B,C,D} that two bits per randomly chosen
element. Then a ten-character string will have 10*2=20 bits of entropy. More
complex scenarios are similar.
Now if you have the String "ABCD" its randomness will actually vary, depending on
the range of characters chosen. For the full alphabet an 'A' will have more
significant bits than in the example above.
IMHO that's the problem: If you don't know the range being used, you cannot guess
the entropy. Of course you can try to derive the range from the string being seen,
but that's just a guess.
Likewise, when considering "December" as a password, it's true entropy is much
less once you know that the range of passwords are only month names. (And so on)
>
> Check this
> http://www.redkestrel.co.uk/Articles/RandomPasswordStrength.html
Yes that's the basics, but you never know how randomly the user picked it's
characters. Obviously this wasn't very random, even though a program might think
so:
qwertzuiop
Regards,
Ulrich
P.S: Off-topic, isn't it?
Shyam...@dell.com
> From: open-...@googlegroups.com [mailto:open-...@googlegroups.com]
> On Behalf Of Ulrich Windl
I am increasing also beginning to infer both through discussions here
and(internally) that fixing a minimum randomness for a password is not
right in the open-iscsi
I guess this discussion might just offer some insight into the
randomness of a password for a user to set.
This can't just be imposed on an implementation verbatim.
So, if there were an implementation "Must" and a deployment "Must", this
falls under the latter.
I guess the 16 character guideline in the Microsoft initiator is more of
a guideline so that users can remember them and not write them in
post-its to compromise the secret further ... :)
-Shyam