[Cryptography] The default password of '1234'

[ianG]

On 21/09/2015 17:41 pm, Paul Madore wrote:
> ianG wrote:
>> I've been calling that click-thru syndrome since forever. > <snip> > Which is why I started promoting HTTPS Everywhere in 2005.
> Do you mean even on pages that require no authentication, such as a
> strictly HTML page? If so, is that because the server operator then has
> to have a certificate? But at the same time, those certificates can be
> falsified, so it kind of defeats the purpose to put it "everywhere."


Yes, on all HTML pages, and yes, the bottom line is that many pages will 
be using certificates that are self-signed and are thus vulnerable to MITM.


> If all one is doing is display text and images, and the user is able to
> disable any scripts and ads (they are), is HTTPS everywhere really a
> reasonable thing to expect?


Expect?  Well, in crypto we do what we can for free..  It's beyond clear 
that we can do encryption for free.  (See Ryan'd thread on Cycles for an 
example, or see the TCPInc project, or SSH or Skype or modern chat 
programs, etc.)  So the principle is that we should always encrypt.

What we can't do "for free" is authentication.  For that we need 
application and/or user help.

> Curious to hear your expanded perspective.

(old timers on the list can stop reading now, you've seen this 
discussion a thousand times...)



The perspective is complicated and historical.  HTTPS was designed to be 
a complete solution - assuming that you only used HTTPS.  But the day it 
was tried way back in 1994, the "high performance" sites of the times 
discovered that it actually cost a lot in performance.  HTTPS wasn't free.

So they bifurcated the web site.  They put only the secure stuff on 
HTTPS and went back to the non-secure stuff being on HTTP [0].

To solve this problem the user was "taught" to see the difference and 
secure herself.  Except, the teaching didn't stick.  Now, this was 
particularly exacerbated because the HTTP site started first, and only 
after the user was "qualified" was she eased across to HTTPS (to enter 
credit card, etc).

Which means that the second HTTPS phase was now vulnerable to a 
downgrade attack to HTTP, which succeeded if the user didn't follow her 
"training".

How often does the user not follow her "training" ?  Well, studies seem 
to put the error rate at around half [1].

What does that mean?  Well - it means that in the presence of on attack, 
there is a 50% chance the user won't notice, and enter her secret info 
into a scammer's site.

50% failure means in cryptographic terms 1 bit security, so HTTPS as 
delivered in browsers, provides about 1 bit of security, if one follows 
the above logic.

Hence phishing is an attractive attack, which first started in 2003-ish 
against HTTPS [2].

The only way out of this is to go HTTPS Everywhere - and then force the 
browser to correctly deal with unauthenticated versus authenticated 
sites.  This puts the website back to being one site not two, and thus 
authenticated from the start, and therefore the browser itself can see 
the downgrade attack.

(There's a bit more reasoning based on browser politics which we can 
leave for another day.)



iang




[0]  And, the user was taught that she didn't need encryption for the 
other stuff.  And, it was declared to be best practices.  And, and and. 
What was secure and what was non-secure is an interesting other 
discussion we can ignore for now, the point is that there were now two 
channels where the security model assumed one.

[1] I'm approximating here, so I'll go with half, you can plug in your 
own numbers.

[2] to be fair, phishing is a lot harder than the above 1 bit claim 
above.  I think we'd be safe saying that HTTPS in secure browsing 
delivers no more than about 10 bits of strength.  But also in 
cryptographic thinking, we're typically doomists and end-of-world-ists, 
so 1 bits is actually about fair for a lower bound for security planning.