[conspire] Password permutations (was: Correction)

[Michael Paoli]

Or, to perhaps make explaining it even easier, start super simple,
and then can build upon that.

So, say we have a combination lock, each separate exposed wheels,
say type you see on some combination padlocks with dial thingies at
the bottom.
Let's say we have a simple one, two wheels to spin, each has
possibility of digits 0 through 9 - so 10 possibilities each.
So we have a total of 100 combinations:
00 through 99.
If we had 5 such wheels,
00000 through 99999, for 100,000 combinations.
So, fairly easy so far, base 10, 10^N, where N is our number of
wheels, or "characters" in our password, but thus far restricted to
decimal digits (and here mandated a fixed length).

Let's say we change to binary, only digits are 0 and 1.
Let's say we have 3 such "wheels"(/toggles),
we have 000 through 111 in binary, or, in binary, a total of
1000 combinations - 8 in decimal.
How do we get that?
2^N - in our example, N=3, so we have 2^3=8.
Also easier to help think/visualize, e.g. 2^3=
2*2*2
likewise our earlier decimal examples
10*10
and
10*10*10*10*10
... which are, 10^2 and 10^5.
So far so good, right?  ;-)

Now take a pair of dice - 6-sided, 1-6 each,
so we have:
11 through 66,
6*6=6^2=36 possible combinations.

The base is our digits/character selection, the exponent, how many of
those selections we get to make.

Now go up to passwords.
Let's say we have password that's 8 characters long.
Let's say each character can be any isprint ASCII character,
so that's ... 128-33=95 characters.
so, we have 95^8=6,634,204,312,890,625 possible passwords.
Seems like a lot?  Well, until one thinks how many operations
per second a modern computer - or large cluster of computers,
can do how quickly.  But then it gets easier than that, as most
of the time, humans are picking the passwords, and tend to pick
much weaker more common passwords or portions thereof.  So, by
trying passwords more probably picked by humans first, often the
"guessing" can yield a match in quite quick order.

Let's say, again, for 8 character password, our human picks a
password that's just lowercase letters ...
26^8=208,827,064,576
compare that to, picking among 95 characters: 6,634,204,312,890,625
so ... by restricting the password to just lowercase letters,
it's about 31,769(~=6,634,204,312,890,625/208,827,064,576) times weaker.

So, also, various mitigations are used to make brute force password
attempts more difficult to infeasible.  But the first line of
defense is a good strong password.

Migitations often include measures such as:

password "rules", to try to "force" more complex passwords
(or at least prevent really bad ones)

algorithms/iterations - more computationally intensive per-password,
attempt, to make brute force attacks less feasible, while still allowing
valid authentication to be able to happen "fast enough".

salt (and pepper) passwords, to make it more difficult to "decrypt"/
reverse/"crack" passwords, and also make it more difficult to tell
if any two passwords are in fact the same, and to also make it
(more likely to be) infeasible to create a "rainbow table" of
all possible password hashes and a password that matches each.

limit rate at which password attempts can be made.

enforce lockouts for too many failed attempts

> From: "paulz at ieee.org" <paulz at ieee.org>
> Subject: Re: [conspire] Password permutations (was: Correction)
> Date: Wed, 15 Apr 2020 05:40:55 +0000 (UTC)

>  I recall that I got it wrong in a previous post and was corrected,  
> but let's work out the answer.
> Suppose the password can be selected from 26 upper case letters, 26  
> lower case letters, 10 digits and 8 punctuation marks for a total of  
> 70.
>
> If the password is 1 character there are 70 possibilities.
> If the password is 2 characters there are 70 * 70 = 70 ^2 possibilities.
> If the password is N characters, there are 70^N possibilities.
>
>     On Tuesday, April 14, 2020, 8:18:19 PM PDT, Texx  
> <texxgadget at gmail.com> wrote:
>
>
> Re Ricks not explaining how he does his passwords:Indeed you should  
> NOT tell us how you do it.  Otherwise would be a groos breach of  
> security.Dont appologize for being right....
> Regarding Ricks & Pauls posts, I see a conflict.Is it number of  
> pitibilities per digit to the power of the number of digits?Or is it  
> number of digits to the power of the number of possibilities per  
> digit?