Temporary password too short

classic Classic list List threaded Threaded
24 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Temporary password too short

William Allen Simpson-2
I've been around a long time (2003) and have old accounts that I never use,
usually explicitly setup to prevent folks from creating accounts with
different capitalization for misleading user names in comments.

After SUL, that case variance problem should be handled correctly.  But
those existing variants could still be re-activated.

Many of these accounts have expired email, so I don't see any notices.
Recently, one that has a current email sent me a notice that reads in
relevant part:

# Temporary password: YH2MnDD
#
# This temporary password will expire in 7 days.
# You should log in and choose a new password now. If someone else made this
# request, or if you have remembered your original password, and you no longer
# wish to change it, you may ignore this message and continue using your old
# password.
#
I use fairly long passwords with special characters (a 96 character set
including space).  This replacement password is much more easily guessed.
The account could have been stolen within minutes or hours.

   https://secure.wikimedia.org/wikipedia/en/wiki/Password_strength

(Merely 7 case insensitive alphanumeric characters is equivalent to only
40-bits of strength.)

Please update the password generator to use at least 17 characters, with
at least some punctuation!  (Users reading the text might have trouble
noticing blanks, so don't use the space character.)

Of course, I know that various studies show that 12 to 15 characters
using a 95 character set are probably enough.  And that's fine for the
user's choose.  But this is an automatically generated replacement,
emailed out in the clear.  It should be something stronger!

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Temporary password too short

Steve Summit
William Allen Simpson wrote:
> This replacement password is much more easily guessed.
> The account could have been stolen within minutes or hours.

Is this true?  (Yes, I know that a fast machine can try zillions
of passwords per hour in theory, but for a reasonably designed
system, certainly not in practice.)

> Please update the password generator to use at least 17 characters,

That seems like far too many.

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Temporary password too short

Andre Engels
In reply to this post by William Allen Simpson-2
On Wed, Oct 26, 2011 at 1:55 PM, William Allen Simpson <
[hidden email]> wrote:

> # Temporary password: YH2MnDD
> #
> # This temporary password will expire in 7 days.
> # You should log in and choose a new password now. If someone else made
> this
> # request, or if you have remembered your original password, and you no
> longer
> # wish to change it, you may ignore this message and continue using your
> old
> # password.
> #
> I use fairly long passwords with special characters (a 96 character set
> including space).  This replacement password is much more easily guessed.
> The account could have been stolen within minutes or hours.
>
>   https://secure.wikimedia.org/wikipedia/en/wiki/Password_strength
>
> (Merely 7 case insensitive alphanumeric characters is equivalent to only
> 40-bits of strength.)
>


I do seriously wonder whether it is possible to steal such a password
'within minutes or hours'. My calculation says that to do it within 24
hours, one needs to test 40 million passwords per second. And remember that
'testing' in this case means sending a message to the Wikimedia servers and
waiting for an answer. Surely getting over 1000 times the normal  number of
requests per second (I have no number for the total number of requests, but
the number of page requests seems to be around 6000 per second) is something
that would not remain unnoticed at the Wikimedia servers for 24 hours.



> Please update the password generator to use at least 17 characters, with
> at least some punctuation!  (Users reading the text might have trouble
> noticing blanks, so don't use the space character.)
>

The more sensitive way of working, in my opinion, would be to invalidate the
temporary password after a certain, low, number of tries, and allow a
temporary password only a restricted number of times within a certain
period. For example, if the password is expired after 5 failed login
attempts, and a new temporary password is only sent once a minute, an
attacker is effectively reduced to one attempt per 12 seconds, making
cracking a 62-alphabet, 7-character key such as this one a task which takes
in the order of one million years.


--
André Engels, [hidden email]
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Temporary password too short

Daniel Friesen-4
In reply to this post by William Allen Simpson-2
On Wed, 26 Oct 2011 04:55:11 -0700, William Allen Simpson  
<[hidden email]> wrote:

> I've been around a long time (2003) and have old accounts that I never  
> use,
> usually explicitly setup to prevent folks from creating accounts with
> different capitalization for misleading user names in comments.
>
> After SUL, that case variance problem should be handled correctly.  But
> those existing variants could still be re-activated.
>
> Many of these accounts have expired email, so I don't see any notices.
> Recently, one that has a current email sent me a notice that reads in
> relevant part:
>
> # Temporary password: YH2MnDD
> #
> # This temporary password will expire in 7 days.
> # You should log in and choose a new password now. If someone else made  
> this
> # request, or if you have remembered your original password, and you no  
> longer
> # wish to change it, you may ignore this message and continue using your  
> old
> # password.
> #
> I use fairly long passwords with special characters (a 96 character set
> including space).  This replacement password is much more easily guessed.
> The account could have been stolen within minutes or hours.
>
>    https://secure.wikimedia.org/wikipedia/en/wiki/Password_strength
>
> (Merely 7 case insensitive alphanumeric characters is equivalent to only
> 40-bits of strength.)
>
> Please update the password generator to use at least 17 characters, with
> at least some punctuation!  (Users reading the text might have trouble
> noticing blanks, so don't use the space character.)
>
> Of course, I know that various studies show that 12 to 15 characters
> using a 95 character set are probably enough.  And that's fine for the
> user's choose.  But this is an automatically generated replacement,
> emailed out in the clear.  It should be something stronger!

Assuming a scenario where a brute force attacker were able to make 1000  
password guesses a second this 7-char [a-zA-Z0-9] password would take 1.14  
centuries to crack. And it expires in 7 days. Not to mention, if memcached  
is being used, we should be rate limiting password guesses.

Admittedly if someone managed to crack into the database and see the  
contents of the user table within 7 days of submitting the password reset,  
done on the local system this temp password could take <1s to crack.
However that's not really something we should care about. Our user table  
contains a user_token whichcan be used to fake a login as a user. It's  
easier to use than it is to crack a temp password.
If a site accidentally leaks it's user table it has to reset the  
user_token column for every user to make the site secure, and with your  
note likewise they should also reset user_newpassword when they reset  
user_token.
The ONLY advantage they gain from cracking the temp password is the  
ability to change the e-mail and hold onto the account after the password  
is reset or the system administrator resets the database's user table.

Maybe we should make a maintenance script to reset these columns.


Admittedly I don't really like the idea of a new 'password'. What I do  
like the idea of a long cryptorandom reset token on link like we have for  
e-mail confirmation.

--
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Temporary password too short

Neil Harris
In reply to this post by Steve Summit
On 26/10/11 13:03, Steve Summit wrote:

> William Allen Simpson wrote:
>> This replacement password is much more easily guessed.
>> The account could have been stolen within minutes or hours.
> Is this true?  (Yes, I know that a fast machine can try zillions
> of passwords per hour in theory, but for a reasonably designed
> system, certainly not in practice.)
>
>> Please update the password generator to use at least 17 characters,
> That seems like far too many.
>

In practice, that password is probably much stronger than most users'
real passwords.

It might perhaps be worth adding one more character, but the simplest
way to increase security on this would be to just put a limit on the
number of reactivation attempts for that particular password.

Assuming the seven-character password given, "YH2MnDD", uses the character set [A-Za-z0-9], there should be 62^7 ~= 3.5 x 10^12 possible such passwords.

Automatically expiring that temporary password after say, 10 failed reactivation attempts, would reduce the probability of successfully guessing that particular password to around 3 x 10^-12 -- probably safe enough for wiki purposes.

Based on this, I don't think it's likely to be nearly as much of a problem as brute-force attacks on ordinary login passwords that go for the "low-hanging fruit" of users with passwords like "1234" or "password1".

Even these can be substantially mitigated by a mixture of per-account and per-client-IP-address throttling, and CAPTCHAs.

If there's one measure I'd like to see that isn't (as far as I know) yet implemented, it would be to require admins and other privileged users to set strong passwords, perhaps initially by Javascript-based warnings, and later by locking out those accounts completely, after a warning period of perhaps one year.

- Neil



_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Temporary password too short

Helder .
On Wed, Oct 26, 2011 at 11:13, Neil Harris <[hidden email]> wrote:
>
> If there's one measure I'd like to see that isn't (as far as I know) yet
> implemented, it would be to require admins and other privileged users to set
> strong passwords, perhaps initially by Javascript-based warnings, and later
> by locking out those accounts completely, after a warning period of perhaps
> one year.


+1
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Temporary password too short

Olivier Beaton
Admins should be required (At least at wmf) to use an authenticator, no?

On Wed, Oct 26, 2011 at 9:24 AM, Helder <[hidden email]> wrote:

> On Wed, Oct 26, 2011 at 11:13, Neil Harris <[hidden email]> wrote:
>>
>> If there's one measure I'd like to see that isn't (as far as I know) yet
>> implemented, it would be to require admins and other privileged users to set
>> strong passwords, perhaps initially by Javascript-based warnings, and later
>> by locking out those accounts completely, after a warning period of perhaps
>> one year.
>
>
> +1
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Temporary password too short

John Du Hart
No, maybe stewards but not admins.

On Oct 26, 2011 9:40 AM, "Olivier Beaton" <[hidden email]> wrote:

> Admins should be required (At least at wmf) to use an authenticator, no?
>
> On Wed, Oct 26, 2011 at 9:24 AM, Helder <[hidden email]> wrote:
> > On Wed, Oct 26, 2011 at 11:13, Neil Harris <[hidden email]>
> wrote:
> >>
> >> If there's one measure I'd like to see that isn't (as far as I know) yet
> >> implemented, it would be to require admins and other privileged users to
> set
> >> strong passwords, perhaps initially by Javascript-based warnings, and
> later
> >> by locking out those accounts completely, after a warning period of
> perhaps
> >> one year.
> >
> >
> > +1
> > _______________________________________________
> > Wikitech-l mailing list
> > [hidden email]
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> >
>
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Temporary password too short

Neil Harris
In reply to this post by Helder .
On 26/10/11 14:24, Helder wrote:
> On Wed, Oct 26, 2011 at 11:13, Neil Harris<[hidden email]>  wrote:
>> If there's one measure I'd like to see that isn't (as far as I know) yet
>> implemented, it would be to require admins and other privileged users to set
>> strong passwords, perhaps initially by Javascript-based warnings, and later
>> by locking out those accounts completely, after a warning period of perhaps
>> one year.
>
> +1

Thanks.

Proper password-strength-checking is sufficiently compute- and
dictionary-intensive that it should probably be done server-side, during
the period when the password is still temporarily available in plaintext
during the login operation, and always done after the user logs in
successfully, even when the user doesn't have Javascript enabled.

Ideally, it could be also done interactively keystroke-by-keystroke on
the password change dialogue, using AJAX callbacks to the server.

All this should, of course, be forced to be done over HTTPS -- as,
eventually, should all logged-in or password-related activity of any sort.

- N.




_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
OQ
Reply | Threaded
Open this post in threaded view
|

Re: Temporary password too short

OQ
In reply to this post by Andre Engels
On Wed, Oct 26, 2011 at 7:59 AM, Andre Engels <[hidden email]> wrote:
> I do seriously wonder whether it is possible to steal such a password
> 'within minutes or hours'. My calculation says that to do it within 24
> hours, one needs to test 40 million passwords per second. And remember that
> 'testing' in this case means sending a message to the Wikimedia servers and
> waiting for an answer. Surely getting over 1000 times the normal  number of
> requests per second (I have no number for the total number of requests, but
> the number of page requests seems to be around 6000 per second) is something
> that would not remain unnoticed at the Wikimedia servers for 24 hours.

Ignoring the fact that most wiki's are throttled to 5 login attempts
in 5 minutes per IP.

So you can really only check 60 an hour or 1440 a day per IP.  So with
114 Billion/hr rate needed and limited to 60/hr you'd need about 2.4
Billion IP addresses.

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Temporary password too short

Tim Starling-2
In reply to this post by Neil Harris
On 27/10/11 00:13, Neil Harris wrote:
> Automatically expiring that temporary password after say, 10 failed
> reactivation attempts, would reduce the probability of successfully
> guessing that particular password to around 3 x 10^-12 -- probably
> safe enough for wiki purposes.

The problem with this approach is that it introduces a DoS
vulnerability. Unless the username is secret as well as the password,
a limit on the number of "guesses" makes it easy to prevent someone
from resetting their password, by flooding the system with fake
guesses for the target username.

Rate limiting per IP does not suffer from this problem, which is why
we use it. Fixing rate limiting so that it doesn't require memcached
and is enabled by default would be useful.

As others in this thread have noted, 40 bits of entropy is plenty for
this particular application. Guessing of user-supplied passwords is a
much more significant threat, and one that is not properly addressed
in a default MediaWiki installation.

-- Tim Starling


_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Temporary password too short

Neil Harris
On 26/10/11 23:30, Tim Starling wrote:

> On 27/10/11 00:13, Neil Harris wrote:
>> Automatically expiring that temporary password after say, 10 failed
>> reactivation attempts, would reduce the probability of successfully
>> guessing that particular password to around 3 x 10^-12 -- probably
>> safe enough for wiki purposes.
> The problem with this approach is that it introduces a DoS
> vulnerability. Unless the username is secret as well as the password,
> a limit on the number of "guesses" makes it easy to prevent someone
> from resetting their password, by flooding the system with fake
> guesses for the target username.

I was working on the assumption that the attackers were unlikely to know
that any particular given user is attempting to reactivate their
account, so they would have to spam their DDoS across the whole range of
valid usernames.

If an outsider knows that one particular account is trying to be
reactivated, you are of course completely right, and the above wouldn't
work.

>
> Rate limiting per IP does not suffer from this problem, which is why
> we use it. Fixing rate limiting so that it doesn't require memcached
> and is enabled by default would be useful.
>
> As others in this thread have noted, 40 bits of entropy is plenty for
> this particular application. Guessing of user-supplied passwords is a
> much more significant threat, and one that is not properly addressed
> in a default MediaWiki installation.
>
> -- Tim Starling
>

As was said by another commenter, the ultimate solution for this is
sending a one-time reactivation link in the body of the email, with a
sufficiently long randomly-generated cryptographic token (eg 40 hex
digits) embedded in it that entropy issues are no longer relevant, and
typeability is also irrelevant, because the user either clicks on the
link in their mail client, or cuts and pastes it into their browser.

-- Neil


_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Temporary password too short

William Allen Simpson-2
In reply to this post by Neil Harris
I'm going to pick on Neil a little, because I know he can take it,
but it applies to just about everybody else in this thread.

For shame.

On 10/26/11 9:13 AM, Neil Harris wrote:

> On 26/10/11 13:03, Steve Summit wrote:
>> William Allen Simpson wrote:
>>> This replacement password is much more easily guessed.
>>> The account could have been stolen within minutes or hours.
>> Is this true?  (Yes, I know that a fast machine can try zillions
>> of passwords per hour in theory, but for a reasonably designed
>> system, certainly not in practice.)
>>
>>> Please update the password generator to use at least 17 characters,
>> That seems like far too many.
>>
>
> In practice, that password is probably much stronger than most users'
> real passwords.
>
Please don't conflate user choices with our choices.  Since the
password is generated on demand, the adversary *knows* something was
generated and sent.

That's quite different than attacking a random user.

It is our choice to send a weak password in email -- a bad choice.


> It might perhaps be worth adding one more character,

Really, how *hard* is it to generate a longer string?


>                                                    , but the simplest
> way to increase security on this would be to just put a limit on the
> number of reactivation attempts for that particular password.
>
Why would this be simpler?  Seems like a lot more code to me.


> Assuming the seven-character password given, "YH2MnDD", uses the character set [A-Za-z0-9], there should be 62^7 ~= 3.5 x 10^12 possible such passwords.
>
I really wish folks would at least read a Wikipedia article before
making such calculations. :-(

No, you've listed the number of combinations, not the entropy.

No, 40-bits of strength means 2**20 attempts on average.  Same order of
magnitude as WEP.  You remember WEP, the security designed to be
easily crackable?

https://secure.wikimedia.org/wikipedia/en/wiki/Wired_Equivalent_Privacy

    In 2005, a group from the U.S. Federal Bureau of Investigation gave a
    demonstration where they cracked a WEP-protected network in 3 minutes
    using publicly available tools.

Or, maybe, perhaps, you might trust that a well-known long-time security
professional is telling you the generated password is too weak. ;-)


> Automatically expiring that temporary password after say, 10 failed reactivation attempts, would reduce the probability of successfully guessing that particular password to around 3 x 10^-12 -- probably safe enough for wiki purposes.
>
No, that's not correct math.

Worse, that would generate a denial of service attack all on its own.
All the adversary has to do is send periodic attempts to lock somebody
out of their own account.

Moreover, what problem does that solve?


> Based on this, I don't think it's likely to be nearly as much of a problem as brute-force attacks on ordinary login passwords that go for the "low-hanging fruit" of users with passwords like "1234" or "password1".
>
This is the lowest *possible* hanging fruit.  We're generating it!


> Even these can be substantially mitigated by a mixture of per-account and per-client-IP-address throttling, and CAPTCHAs.
>
While it would be nice to have better user password checking, and
require all login sessions to be over HTTPS, and not use cookies to
identify sessions, and many other desirable improvements -- this is
the simplest and easiest thing I can imagine!


> If there's one measure I'd like to see that isn't (as far as I know) yet implemented, it would be to require admins and other privileged users to set strong passwords, perhaps initially by Javascript-based warnings, and later by locking out those accounts completely, after a warning period of perhaps one year.
>
Now, that seems much too long a time.  I'd make it a prerequisite for
being an administrator at all!

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Temporary password too short

Thomas Dalton
On Oct 30, 2011 11:29 AM, "William Allen Simpson" <
[hidden email]> wrote:
> On 10/26/11 9:13 AM, Neil Harris wrote:
> > Assuming the seven-character password given, "YH2MnDD", uses the
character set [A-Za-z0-9], there should be 62^7 ~= 3.5 x 10^12 possible
such passwords.

> >
> I really wish folks would at least read a Wikipedia article before
> making such calculations. :-(
>
> No, you've listed the number of combinations, not the entropy.
>
> No, 40-bits of strength means 2**20 attempts on average.  Same order of
> magnitude as WEP.  You remember WEP, the security designed to be
> easily crackable?
>
> https://secure.wikimedia.org/wikipedia/en/wiki/Wired_Equivalent_Privacy
>
>    In 2005, a group from the U.S. Federal Bureau of Investigation gave a
>    demonstration where they cracked a WEP-protected network in 3 minutes
>    using publicly available tools.
>
> Or, maybe, perhaps, you might trust that a well-known long-time security
> professional is telling you the generated password is too weak. ;-)

If you are going to be so insulting, please at least try and be right...
You could start by reading the articles you are telling other people to
read.

For a random sequence of characters, the entropy is just the base-2 log of
the number of combinations, so there is nothing wrong with just calculating
the number of combinations. Converting to entropy just makes it easier to
compare two passwords drawn from different character sets.

WEP is flawed because it encrypts different parts of the message using
related keys, not because it is susceptible to a brute force attack on the
password. It is completely irrelevant to our discussion.

To get the average number of attempts, you half the number of combination,
you don't square root it. With 40 bits, the average is 2^39 attempts, not
2^20.
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Temporary password too short

Antoine Musso-3
In reply to this post by William Allen Simpson-2
On 30/10/11 12:28, William Allen Simpson wrote:
>> >  It might perhaps be worth adding one more character,
> Really, how*hard*  is it to generate a longer string?

Have a look at the method User::randomPassword() in the file
includes/User.php :

Password is at least 7 characters long and can be made longer with the
global $wgMinimalPasswordLength (which will require longer password for
everyone).

So we could just change that 7 to 10 and we will get longer temporary
passwords.

--
Antoine "hashar" Musso


_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Temporary password too short

Andre Engels
On Sun, Oct 30, 2011 at 2:20 PM, Antoine Musso <[hidden email]> wrote:

> On 30/10/11 12:28, William Allen Simpson wrote:
> >> >  It might perhaps be worth adding one more character,
> > Really, how*hard*  is it to generate a longer string?
>
> Have a look at the method User::randomPassword() in the file
> includes/User.php :
>
> Password is at least 7 characters long and can be made longer with the
> global $wgMinimalPasswordLength (which will require longer password for
> everyone).
>
> So we could just change that 7 to 10 and we will get longer temporary
> passwords.
>

We could, but why would we? As has been shown by me and others in this
thread, any brute force attempt that has a reasonable chance to crack the
current passwords would already include an amount of traffic to the
Wikimedia servers amounting ot a Denial of Service attack.

--
André Engels, [hidden email]
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Temporary password too short

Daniel Friesen-4
In reply to this post by Thomas Dalton
On Sun, 30 Oct 2011 05:34:02 -0700, Thomas Dalton  
<[hidden email]> wrote:

> On Oct 30, 2011 11:29 AM, "William Allen Simpson" <
> [hidden email]> wrote:
>> On 10/26/11 9:13 AM, Neil Harris wrote:
>> > Assuming the seven-character password given, "YH2MnDD", uses the
> character set [A-Za-z0-9], there should be 62^7 ~= 3.5 x 10^12 possible
> such passwords.
>> >
>> I really wish folks would at least read a Wikipedia article before
>> making such calculations. :-(
>>
>> No, you've listed the number of combinations, not the entropy.
>>
>> No, 40-bits of strength means 2**20 attempts on average.  Same order of
>> magnitude as WEP.  You remember WEP, the security designed to be
>> easily crackable?
>>
>> https://secure.wikimedia.org/wikipedia/en/wiki/Wired_Equivalent_Privacy
>>
>>    In 2005, a group from the U.S. Federal Bureau of Investigation gave a
>>    demonstration where they cracked a WEP-protected network in 3 minutes
>>    using publicly available tools.
>>
>> Or, maybe, perhaps, you might trust that a well-known long-time security
>> professional is telling you the generated password is too weak. ;-)
>
> If you are going to be so insulting, please at least try and be right...
> You could start by reading the articles you are telling other people to
> read.
>
> For a random sequence of characters, the entropy is just the base-2 log  
> of
> the number of combinations, so there is nothing wrong with just  
> calculating
> the number of combinations. Converting to entropy just makes it easier to
> compare two passwords drawn from different character sets.
>
> WEP is flawed because it encrypts different parts of the message using
> related keys, not because it is susceptible to a brute force attack on  
> the
> password. It is completely irrelevant to our discussion.
>
> To get the average number of attempts, you half the number of  
> combination,
> you don't square root it. With 40 bits, the average is 2^39 attempts, not
> 2^20.
And to top it off WEP is a local attack, one where you can brute force at  
a much higher rate than you can over the latent Internet hitting servers  
as fast as they can handle your requests.


I do take back my estimate of it taking 1.14 centuries at 1000  
guesses/second to brute force the entire password space. That was  
calculated on the basis of normal passwords which are length-variant as  
well, but the one we generate is fixed-length so that doesn't apply.

Looking at our code we generate a fixed-length random password:
- length 7 or the minimum password length, whichever is larger (minimum  
password default seams to be 1 so it's usually 7)
- one character is always a digit, which character is a digit is random
- All other characters are [a-zA-Z]

A digit has 10 possibilities, the alphabet has 26 characters which  
combined with an upper-lower set is (26*2) = 52 possibilities.

So for one digit placement (ie: #XXXXXX) the number of possible passwords  
is (10 * 52^6) (ie: [10, 52, 52, 52, 52, 52, 52]), for all 7 digit  
placements that is multiplied by 7.

(10 * 52^6) * 7 = 1383942676480

So there are 1383942676480 (~1.38 x 10^12) possible passwords to generate.

Going back to the estimate of a theoretical brute force attack able to  
guess 1000 passwords/second without any rate limiting, that will take 8.95  
years to go through the entire password space. If I understand Thomas  
Dalton's note about halving the number of combinations then that would be  
an average of 4.5 years.

Given that we expire a temporary password within 7 days after generating  
it at 1000 passwords/second an attacker will be able to go through (7 * 24  
* 60 * 60 * 1000) = 604800000 potential passwords, which when divided by  
the number of possible passwords is ((7 * 24 * 60 * 60 * 1000) / (10 *  
52^6)) = 0.3% of the possible passwords.

And of course, we rate limit password guesses when a cache is available.  
Though making that a 'we always rate limit password guesses' would be a  
good idea.


Since the strength of that is already good enough I'd still opt to instead  
work on the less simple task of replacing our randomized 'passwords' with  
a generated token embedded in a link.

--
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Temporary password too short

Neil Harris
In reply to this post by William Allen Simpson-2
On 30/10/11 11:28, William Allen Simpson wrote:
> I'm going to pick on Neil a little, because I know he can take it,

Yes, I can ;-)

> but it applies to just about everybody else in this thread.
>
> For shame.

My main point here is that (given some simple assumptions about how the
site is administered) this is largely a theoretical problem, not a
practical one, and there are far bigger problems that need fixing more
urgently.

This is not to say that a few more characters in the password, or a long
term move to a more secure mechanism using much longer tokens, wouldn't
be a good idea, but I don't think it's nearly as big a deal as you
currently think, and we have more serious problems than this (see below)
which need fixing first.

[snip]

> I really wish folks would at least read a Wikipedia article before
> making such calculations. :-(
>
> No, you've listed the number of combinations, not the entropy.
>
> No, 40-bits of strength means 2**20 attempts on average.  Same order of
> magnitude as WEP.  You remember WEP, the security designed to be
> easily crackable?
>
> https://secure.wikimedia.org/wikipedia/en/wiki/Wired_Equivalent_Privacy

No, you're thinking of a birthday attack, which does indeed takes ~
sqrt(n) guesses on average. A simple brute-force guessing attack, which
this would be, takes n/2 guesses on average. In this case, 62^7 ~=  
2^41, so you're looking at roughly 2^40 guesses to hit a collision, not
2^20.

A bit of rate-limiting on the password recovery mechanism should be
enough to limit this to a reasonable level of security: even with the
current 7-character temporary passwords, if the mechanism has a
site-wide limit to (say) one forced password reset attempt per second,
one account will end up being successfully brute-forced roughly every
30,000 years.

Of course, this would mean that the mechanism could easily be DDoS'd,
but that's really no big deal either -- the password reset mechanism is
hardly core infrastructure, and, could trivially be tweaked to be more
secure -- and yes, adding a few more characters to the password wouldn't
hurt.

However, this is way, way, way lower risk than the current risk of
brute-forcing low-hanging-fruit user passwords: for every user with a
password generated by base64-encoding the output of /dev/random, there
will be _thousands_ with passwords like "secret99" and "trustno1".

-- Neil



_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Temporary password too short

Thomas Dalton
On 30 October 2011 15:38, Neil Harris <[hidden email]> wrote:
> However, this is way, way, way lower risk than the current risk of
> brute-forcing low-hanging-fruit user passwords: for every user with a
> password generated by base64-encoding the output of /dev/random, there
> will be _thousands_ with passwords like "secret99" and "trustno1".

A password from /dev/random is extremely insecure. It is highly
susceptible to the "find where they wrote it down because it's far too
difficult to remember" attack.

Obligatory xkcd link: http://xkcd.com/936/

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Temporary password too short

Happy Melon-2
On 30 October 2011 15:46, Thomas Dalton <[hidden email]> wrote:

> On 30 October 2011 15:38, Neil Harris <[hidden email]> wrote:
>


> > However, this is way, way, way lower risk than the current risk of
> > brute-forcing low-hanging-fruit user passwords...
>
> A password from /dev/random is extremely insecure.
>

I don't believe these two statements are in any way mutually exclusive.
There are degrees of "extremely insecure" in which "password1" ranks
significantly higher than "the password I keep on the post-it in my desk
drawer".  One is very weak in the face of anyone connected to the internet,
one is very weak in the face of anyone who has access to your office.
Significantly more people have access to the internet than have access to
your office/home/phone/filesystem.  Neither threat is negligible, both are
worth taking sensible measures to counter.  But the point where the
conversation loses all sense of perspective is when it loses all level of
utility.

--HM
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
12