Boston Linux & UNIX was originally founded in 1994 as part of The Boston Computer Society. We meet on the third Wednesday of each month at the Massachusetts Institute of Technology, in Building E51.

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss] Most common (or Most important) privacy leaks



I have not checked in on the conversation for some time so I'm sorry if
this message is no longer relevant /redundant.
Malware is a huge threat. The employees are your front line troops.
Training is #1. If you start with how to secure themselves personally. Any
hack of an employee secondarily exposes the company to a breach. How to
avoid malware, and phishing? How large and real is the threat is to them
and to the company? Tell them why they should care about security. They
should know what to do if a stranger that "looks like they belong" but they
don't recognize comes walking through the office. Malware is no different.
The passwords are no different than locks on the data. These are real
threats to them and the company.

Only in the context of introducing good practices I would give examples of
what not to do. Passwords are a complex issue, and that is how my interests
were piqued. I want to address some misconceptions and why minimum
standards are important.


*Passwords are central and important and I believe it's best to have a
strong password policy. *
Strong passwords are very important regardless of if two-factor
authentication is used, and of course it should be used on critical systems
especially by system administrators wherever possible.

The point of these guidelines is to gently lead all users to choose
passwords out of a large pool of permutations. You don't aim to maximize
the space, you aim to lead users to use passwords out of
a sufficiently large pool that meets your needs, so that the pool used in
practice is a good one. In this respect, common guidelines have a sound
basis in math an logic.  It's easy to calculate the pool you choose with
some calculations. I tend to use Python so that is what I've used in
expressions.

It's true that these guidelines lead users to choose from a pool that is
smaller than something like
*print("{:,}".format(sum([62**x for x in range(1,21)])))*
*715,971,350,555,965,203,672,729,121,413,359,850  *
That pool is unnecessarily huge. Even the passwords up to 19 characters has
a pool of 1.154793e+34 is bigger than the speed of light squared or
avogadro's number. As the logic shows below that the longest passwords
allowed add the most, by far, to the chosen pool and 20 is pretty long
password. The point is to start with a pool that is larger than needed and
then lead users to choose passwords from a sub-pool that is hard to hack at
using known methods.

A minimum length requirement eliminates the  security risk of short
passwords. People are busy and they won't take on much more hassle than
they must. The assertion that requiring passwords of minimum length lowers
security by eliminating the simpler passwords from the pool, but the truth
is that you are requiring a password to be chosen from a much larger pool
that is harder to guess. It's large enough to do a dance on the grave of
the shorter password pools. Here is why.

A permutation over alphabet *A *(containing *a* possible symbols) that is
*n* digits long would have *a**n* possible permutations.
The passwords smaller than *n* digits would be *a**(n-1) + a**(n-2)+...+a^1*
Even those this seems this sum of all shorter passwords would be large,
maybe even larger, it's not. The longer sequence of just the minimum number
of characters has a much larger permutation space that all the previous
ones combined. In fact the difference increases exponentially with n.

for n,row in [(longer,all_shorter,math.log(longer-all_shorter,10)) for
(longer,all_shorter) in [(26**y , sum([26**x for x in range(1,y)])) for y
in range(2,16)]]:
   .....:     print(n+1,row)     .....[Output Improved ]......Editing...
done. Executing edited code...
 *n                       q = 26**n     r = sum(26**(n-1)+...26**1)
log(q-r,10)*
 2                             676                              26
 2.81
 3                          17,576                             702
 4.23
 4                         456,976                          18,278
 5.64
 5                      11,881,376                         475,254
 7.06
 6                     308,915,776                      12,356,630
 8.47
 7                   8,031,810,176                     321,272,406
 9.89
 8                 208,827,064,576                   8,353,082,582
11.30
 9               5,429,503,678,976                 217,180,147,158
12.72
10             *141,167,095,653,376*               *5,646,683,826,134*
    14.13
11           3,670,344,486,987,776             146,813,779,479,510
15.55
12          *95,428,956,661,682,176*           *3,817,158,266,467,286*
    16.96
13       2,481,152,873,203,736,576          99,246,114,928,149,462
18.38
14      64,509,974,703,297,150,976       2,580,398,988,131,886,038
19.79
15   1,677,259,342,285,725,925,376      67,090,373,691,429,037,014
21.21

*Seriously* don't be concerned over the loss of the shorter passwords. You
are not helping hackers by eliminating them, you are improving security.
Again you are discarding the number of digits in column r if you choose n
as the minimum number of digits in favor of requiring the selection of a
password in a pool with q members. This is just over the lower case letters
so far.

Now let's consider the assertion that you loose permutations by requiring
one numeric digit, which of course is from 0-9 ( an alphabet of 10 rather
than an alphabet of 26 lower case letters). It seems obvious enough that
this would result in fewer permutations in the space our guidelines lead
users to use, however in the way it's applied, it doesn't.

First let *p* be a permutation of *n-1* digits over alphabet *A* with
*a* symbols
and one digit from alphabet *B* with *b* symbols *that may appear only as
the first digit*. The permutation has *n* digits total.  What is the number
of permutations?
*a**(n-1) * b*
As expected since *b < a* (10<26) this expression is less than *a**n*.
However this is not the situation we are given.

Let *p* be a permutation of *n-1* digits over alphabet *A* (with *a* symbols)
and one digit from alphabet *B* with *b* symbols that may appear at any
place in the n digit (total) permutation.  What is the number of
permutations?
*a**(n-1) * (b *n)*
and further more its simple to prove that
*a**(n-1) * (b *n) < a**n if and only if (b*n) < a*
in the case of *n=8, b= 10*, and *a=26* it's not, *10*8=80 > 26* !  and in
fact it rather counter intuitively results in
?In * ((26**7 * 10)*8)- 26**8 = 433,717,749,504* more permutations in the
minimum space than 8 digits over alphabet *A*
It should be clear that requiring an uppercase letter results in even more
permutations used in practice.

In summary the point is to lead users to choose passwords from a pool that
is "large enough" and "hard to hack", In doing so the passwords in practice
will more closely resemble the ideal permutation space of *62**n*,but
approximating this space is not the goal. The idea is to trim way the
easy-to-guess sub-sets by leading users to a minimum sub-set of passwords
that is large enough to be hard to crack. It is not as hard with a bit of
 Python  to calculate the size of the set that results from minimum
standards you choose.

On Tue, Feb 17, 2015 at 8:42 AM, Edward Ned Harvey (blu) <blu at nedharvey.com>
wrote:

> I see a lot of people and businesses out there, that just don't care about
> their own privacy.  They email passwords to each other, W2's with salary
> and social security information, photocopies of drivers' licenses and
> passports to be used by HR to complete I-9 forms...
>
> As an IT person advising a business to be more responsible, what areas do
> you advocate securing most urgently?  IT admin credentials?  HR records?
> Financial records?  Other stuff?  Simply everything, bar none?
>
> Email is obviously a huge area of insecure information sharing.  Do you
> also see a lot of people storing information that should be secured in
> other non-private services like Dropbox, Google Drive, Box, etc?
> _______________________________________________
> Discuss mailing list
> Discuss at blu.org
> http://lists.blu.org/mailman/listinfo/discuss
>



BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org