[ale] OT - New encryption technology using a piece of paper

[Michael Trausch]

On 09/03/2011 06:01 PM, Ron Frazier wrote:
> Hi Mike,
> 
> Your posts always make me think about my positions.  I like that.  I'll 
> stipulate right off the bat that you know more about cryptography than 
> me, as is apparent by your reply.  However, I do have some further 
> thoughts.  Steve Gibson's Password Haystacks page at 
> https://www.grc.com/haystack.htm can be used to do the calculations to 
> determine the brute force "attackability" of any password, strictly from 
> a length and # of possible symbols point of view.

Even a broken clock...

> The page does not 
> account for intelligent use of patterns, ie, they know your password is 
> always an Uncle's first name followed by an Aunt's last name, etc.  At 
> the bottom of your post, you mention using a high entropy password 
> card.  When I see the term high entropy, I presume the password looks 
> like gibberish, so, I'm going to assume that the passwords on such a 
> card, as well as those from Steve Gibson's off the grid card will be 
> equally non memorable to the user, even though the user may not like 
> it.  One advantage of the grid over a password card is that the grid can 
> be used to create passwords for any number of sites, whereas a password 
> card can only hold a fixed number of passwords and still fit in your pocket.

Incorrect.  I'm guessing you couldn't find it within yourself to google
for "password card".  Here is the site, which is also the first result
at Google:  http://www.passwordcard.org/en

If you check the box that includes symbols, you have a card that fits in
your wallet from which you can generate pseudorandom passwords.  You can
have memorable patterns based on the symbols along the top, the row
numbers on the left, the colors, or anything else that you find that you
can remember.  This system _works_ even with people who hate trying to
remember passwords.  Using the password card, you don't have to remember
the password; you only have to remember how to derive it.

I have been using the password card system for some time now.  I use as
many characters in my passwords as I can get away with when I am unable
to use pass phrases.  (I prefer pass phrases, because they are longer,
more memorable, more effective, and if you pick them nonsensically
enough, are virtually impossible to guess.)  Passphrases are really good
for protecting private keys.  For Web sites, I mostly use my password
card.  Good luck cracking the passwords at any of the sites that I have
an account on (unless they are in plaintext, but even so, you can't get
to any of my other accounts that way).

You know what I would really love to see?  I would really love it if SSH
keys, or OpenPGP keys, or even client SSL certificates would be
commonplace for authentication through a Web browser.  Except for that
tiny little tidbit that your SSL client certificate is almost always
stored unencrypted, which is a major issue.  So yeah, I'd prefer SSH
keys or OpenPGP keys.

> By the way, if you just want a good string of high entropy gibberish, 
> you can get that at https://www.grc.com/passwords.htm , up to 64 
> characters.  These make good WPA passwords.  Another source of random 
> data that Steve mentioned in the podcast is http://www.random.org .

I use passphrases for wireless networks; they cannot be guessed, but if
I have given you my passphrase one time, you'll likely never forget it.
 I also do not have to go digging through files to find where I put the
stupid thing when I have to tie something else to my network.  I am a
member of the school of thought of working smart, not working hard.

It is also prudent to mention here that there are TWO essential keys to
security, other than the obvious technical ones: Simplicity and
transparency.  Without simplicity, even the most secure sites in the
world are easily bypassed because humans suck and will find ways to
automate the security away (and since very few people are aware of what
it means to truly be secure, they'll inevitably do so in any one of the
most insecure ways possible).

> For those that haven't looked at Steve's site, I'll just share a bit of 
> background.  His objective is to start with the domain name of a 
> website, and using only a piece of paper with a special grid on it, to 
> create a password for the site.  As a baseline, he uses a 26 x 26 Latin 
> Square.  This is a chart with 26 rows and 26 columns.  Each row contains 
> the full alphabet and each column contains the full alphabet with no 
> duplications in either row or column.  You can print your own custom and 
> unique Latin Square from his website or use your own algorithm.  Using a 
> procedure he gives, which you also could change, you traverse into the 
> grid to a certain starting point using part of the domain name of 
> interest.  Then, you traverse through the grid either up and down or 
> left and right, also using the domain name to trigger your movements.  
> At each point, you encipher the character you're working on by choosing 
> 2 other characters from the grid.  Thus, amazon, in his example, gets 
> enciphered into a 12 character password that can be used for that website.

Password cards are simpler, with higher available entropy, and have no
requirements on algorithm or process.  Therefore, they are more robust
systems which can be employed by more people for less time investment,
and thus they can actually increase security because people will
actually _use_ them.

> Now, continue below.  See further comments inline:
[big snip]

Please trim emails to relevant context.  We have archives, in case
anyone misses parts of the thread they can look back in their own MUA or
on the archives.

>> This system is, from the very outset, not very difficult to use.  But it
>> is time-consuming in that the human is very error-prone, and humans can
>> not be relied upon to perfectly follow the steps to any algorithm with
>> efficiency.  But that's just the start.
>>
>> He shows an example on his site where he creates a password using
>> "amazon" as the input, presumably for amazon.com.  The resulting
>> password that he came up with was "gcznegmacmzg".  This is a horrible
>> password.  And the "full scale" grid uses only 52 possible characters
>> for output; that is, upper and lower case letters.
>>    
> I don't think Steve is advocating using a 12 character password with 
> only upper and lower case letters if you have a choice.  He is simply 
> acknowledging that many websites will not accept anything else.

Then do not use those sites.  Period.  It is far worse to take part in
the acceptance and propagation of sheer stupidity than it is to take a
slight hit to one's own convenience and find another vendor to provide
them with services.

I realize that I am in the minority there, even in my industry.

Funny thing, you know, I came across this the other day:

  http://www.skorks.com/2009/08/is-basic-authentication-really-insecure/

Some moron *ACTUALLY* thinks that there is no security disadvantage to
having plaintext passwords stored on a server.

What can I say?  The world is full of stupid people.  Not lazy; lazy
people get their stuff done correctly the first time because they don't
want to go through the process of doing it correctly the second, or the
third, or the fourth...

>  I am 
> sorry to say that both my bank (which shall remain nameless)

Please, tell.  I want to know who NOT to go to for an account should I
have to hunt in the future.  (Unless it's Chase, which I am already
aware of.)

> as well as 
> the job posting website of a major national defense lab (which shall 
> also remain nameless) both limit me to 8 characters.

Then clearly they are not a worthwhile place of employment because they
either do not know what they are talking about, or they feel that they
(like many other alleged security companies) are somehow above the way
the world works.

>  I find this 
> abominable, but it is what it is.

And so it will stay if people accept it as such.

> There are many many examples of 
> websites that won't allow numbers or symbols, while others will require 
> it.  I will explain later how Steve's grid can be used to a) add length 
> to the password, b) add symbols, or c) add numbers; all of which 
> increase the entropy and security.  The method Steve describes will 
> allow a reasonably secure high entropy password (within the constraints 
> of the length) to be created for any website based on the domain name, 
> or recreated if necessary, assuming you don't lose the grid.  He's 
> trying to make it so it can be put into any site without it complaining 
> about length, symbols, or numbers.

It follows his usual pattern, unfortunately.  Instead of working to help
improve things, he is working to solidify things the way they are.  What
makes *me* curious is what sort of motivation does he have for doing so?

His system creates low entropy passwords, end of story.  Unless you're
using 50 characters, it is really not worthwhile to attempt to use a
password where the characters come from a pool of only 52 possibilities.

>  He's also trying to make the 
> procedure easy to remember so you don't have to remember 20 different 
> methods to traverse the grid for 20 different websites.  Adding length, 
> symbols, or numbers will certainly help your security, but will make 
> more an more sites reject the password.

His system essentially solves the same problem by lowering the quality
of passwords.  I submit to you that a real solution is:

  * To use passwords that are strong.  (Hell, today you can use Unicode
    for passwords on MANY systems.  It don't get better than that,
    kids.)
  * To use only ONE password for ONE site.
  * To NOT USE sites that require your password be insecure for ANY
    reason.  It isn't good enough to say "oh, they don't have anything
    but my name and email, it's okay," or any other sort of rationale.
    Reject, reject, reject.

> The password haystacks page agrees with your math with one exception 
> which I'll describe below.  If I put the password used in Steve's 
> example, gcznegmacmzg, into the password haystacks page, it says the 
> following:

The page requires you to put the password INTO THE SITE?  And people
ACTUALLY DO IT?  Please, stop.  You're hurting me.

> Count of all possible passwords with this alphabet: 99,246,114,928,149,462
> Time to crack it - Online attack - 1000 guesses / second: 31.56 thousand 
> centuries

So he's off by about 38,000 quadrillion.  But that's okay, because it's
not like the site knew that the pool was as limited as it was.

Nobody is going to crack a password like that online unless the site
programmer didn't know WTF a lockout was, period.  SSH gets attacked
like that regularly, but most (sane) Web sites will lock the account out
after between 3 and 10 failed attempts.  If one does not, DON'T USE IT.
 Seriously!

> Note that this is the exact scenario that the grid was designed to 
> defend against.

Then it is flawed from the start.  The scenario that needs defending
against is where the attacker has the user database.  That's what needs
to stand up to brute force attacks.

> Note also that, if you're trying to crack my Amazon 
> account with a password like this, it is highly likely that the system 
> will lock you out after 3 or 10 guesses for anywhere from 30 minutes to 
> a day.  This will substantially lengthen the time frame you'll need to 
> crack it.

Which is why nobody would even try.

> OK, now you're talking about an offline attack, and things change a 
> bit.  I presume you're referring to a Key Derivation Function (thanks 
> Wikipedia) to slow down the user's password tries just enough to 
> discourage brute force attack.  So let's see what password haystacks 
> says.  This page gives two more numbers as follows (using a 52 character 
> symbol set of length 12):

Offline attacks are the only ones that really matter.  Online attacks,
given proper system administration and systems engineering, are
impossible for all but the stupidest, most popular passwords.

For that matter, nobody would try an on-line attack unless it was a VERY
directed attack (unless they're looking for low-hanging fruit on SSH
servers, anyway) and such a directed attack will very likely succeed as
they'll have done their homework FIRST.

> Time to crack it - Offline fast attack - 100 BILLION guesses / sec: 1.27 
> centuries.  Still pretty secure, I think.  (I'm assuming this is 1 machine.)

I've already demonstrated that to be false; most brute force attacks
don't care about people who care about their security.  The mere
introduction of a $, ., !, #, or @ in your password will exclude it from
probably 75% of brute force attacks; put two or three symbols in and
guess what?  It ain't gonna happen; it's just not feasible.

Most brute attacks are limited to dictionary words and alphanumeric
ASCII only.  If that don't crack it, they don't really care, again,
unless it is a quite directed attack.

> Time to crack it - Massive cracking array - 100 TRILLION guesses / sec: 
> 1.52 months.  (I'm assuming this is 1000 machines.)  (Note, if I go back 
> to the lower case "g" as the last character, this drops to 16.54 
> minutes, so I could understand how you'd be skeptical.)

Gibson seems to be in the business of making people feel safer than they
have any business feeling.  He seems to be in the business of making
people like me out to be "paranoids".

Well, I'll tell you this:  I've only been compromised twice: PlayStation
Network (plaintext passwords, plain text credit card numbers, UTTER
FSCKING MORONS) and Gawker Media (plaintext passwords).  No biggie.  I
use different passwords for EVERYTHING.  Impact: Zero.  Impact of future
events for places I don't know are being stupid with my data:  Zero.
That has something to do with the fact that I don't host my data
anywhere else anymore, though, with the sole exception of my email, and
someday when I have enough time, that too will change.

> OK, now we have a potential problem with that last item.
> 
> IF every query from every machine is subjected to a KDF, as you 
> mentioned, and if only 100 queries / sec. can be done, there is no 
> problem.  We're working at 1/10 the speed of the original example (with 
> 52 characters), so it will take 12.7 hundred million centuries to 
> crack.  No problem.
> 
> If every machine is subjected to a KDF but you can submit 1000 
> simultaneous queries from different machines, that's a bit different.  
> I'm not sure how to do that math, but I THINK, you're still talking 
> about a hundred million centuries.  Still no problem.

1,000 queries is nothing.  Have you heard of botnets?  Those things are
used for these things.  Try thinking about things on the order of 1 to
100 million attempts a second even with a strong KDF.  That said,
anything requiring a KDF is likely to be beyond the reach of the
software running on the botnets in the first place.  They are interested
in low-hanging fruit nearly exclusively.

> The big problem is if there is no KDF and all 1000 machines can submit 
> queries at the maximum speed.  This is how we might crack the password 
> in 1.52 months.  So, I will admit that if you have 1000 computers at 
> your disposal AND you want to crack my Amazon account with a 12 
> character Upper / Lower case password AND their system doesn't foil you 
> with KDF's or lockouts, then I could be in danger.  So, I should 
> probably increase the length of the password or add symbols or numbers.  
> I'll post something later (after supper) to show how to do that with 
> Steve's grid.  For, now, if I just add one number and one symbol to the 
> password on the password haystacks page, which increases the potential 
> symbol set to 95 symbols and length to 14, even a massive cracking array 
> will take 15.67 thousand centuries to crack my password.  I think that's 
> secure enough now.  More later.

I'm no longer interested.  I've evaluated his grid enough to see that it
is worthy of his reputation, and that's really all I need to know.  I
will continue going about my business and using strong passwords and
passphrases because honestly, I have a system that works better and
requires less time and know-how, meaning that I can focus on my work and
not on useless bull like password management.

	--- Mike

-- 
A man who reasons deliberately, manages it better after studying Logic
than he could before, if he is sincere about it and has common sense.
                                   --- Carveth Read, “Logic”