Subject: [http-auth] HTTP authentication: the next generation

From: [email-masked]
Date: Thu, 6 Jan 2011 12:14:51 -0800

This (attached) was sent to the wrong IETF HTTP auth mlist. :-)

(BTW, couldn't find this one through google, the other one turns
up as hit #1)
-- 
Good code works on most inputs; correct code works on all inputs.
My emails do not have attachments; it's a digital signature that your mail
program doesn't understand. | http://www.subspacefield.org/~travis/ 
If you are a spammer, please email [email-masked] to get blacklisted.

Subject: [ietf-http-auth] HTTP authentication: the next generation
From: [email-masked]
To: [email-masked]
Date: Wed, 5 Jan 2011 16:21:39 -0800
List-Id: <ietf-http-auth.osafoundation.org>

I second everything that Marsh Ray said in this thread (at least, what
he said on websec; I wasn't subbed here at the time).

Specifically, HTTP digest was better than basic, but still had a problem
with replay attacks, since HTTP is stateless.  I discussed this a little here:

http://www.subspacefield.org/security/security_concepts/index.html#tth_sEc28.6.4

If you understand why a PGP-encrypted email could be sent again, you
understand why HTTP Digest auth could, also.

Another point; if you can memorize or comfortably enter a secret, it's
not secure against many attacks:

http://www.subspacefield.org/security/security_concepts/index.html#tth_sEc36.5

In some cases, you can detect an online attack and therefore use a
shorter secret, but really, relying on the server admin to implement
this is not a very reliable strategy; no matter how good an idea it
is, most people won't implement it, because the system works without
it, and most people stop putting in effort when the system works.

(Probably ZKPs don't have this problem, but that's another discussion).

Finally, unless you're using PK, then the server has the secret you're
using to authenticate, or its equivalent (if you e.g. hash a password
before sending it over the wire).  In most cases, this is a bad thing;
it can allow the server (operator, or anyone who pwns it) to pretend
to be the client, and if the customer used the password elsewhere, it
could be used to impersonate them there.  You might be tempted to
think that combining it with the domain name (etc.) might help, but
unless the client automatically does that BEFORE sending it to the
server initially, it can be captured on TOFU.  Same deal with password
hashing and resistance-to-offline-cracking strategies - it has to be
sent to the server, and unless the protocol defines how the server
does this, and the client software does it once before sending it to
the server, then generally the customer ends up sending the secret en
clair on time of first use.

IMHO, any login stuff has to be in the browser chrome.  As Carsten
Borman pointed out, anything in the web page can be spoofed.  What we
need is the output analog of the "secure attention" key, where the
site can't spoof it.  Marsh mentioned the secure attention key
(ctl-alt-del) in NT through Vista, but it of course existed in other
systems:

https://secure.wikimedia.org/wikipedia/en/wiki/Secure_attention_key
http://www.mjmwired.net/kernel/Documentation/SAK.txt

And, whatever we use in the chrome has to become ubiquitous enough
that absence of it makes people pause.  This will take a while, but
it means that we have to get it right the first time, because security
is already too complicated for many users.

I'm not sure where I heard the idea (I'd like a URL or reference), but
I think what we need, if we need users to do anything to be secure, it
should be a clear, simple, well-defined security ritual that they can
perform each and every time.  We need rituals because we need to have
a simple answer to the question "what do I need to do to make sure I'm
secure?" (in the context of your use case).  If we can't answer that
question with a clear ritual or (ideally) "you are secure by default",
we have failed at security usability.
-- 
Good code works on most inputs; correct code works on all inputs.
My emails do not have attachments; it's a digital signature that your mail
program doesn't understand. | http://www.subspacefield.org/~travis/ 
If you are a spammer, please email [email-masked] to get blacklisted.
_______________________________________________
ietf-http-auth mailing list
[email-masked]
http://lists.osafoundation.org/cgi-bin/mailman/listinfo/ietf-http-auth

---

From: [email-masked]
Date: Thu, 6 Jan 2011 14:14:44 -0800

BTW, something may be off with this mailman.

I got a message with my post, saying I wasn't subscribed, a few
minutes after I got a confirmation email saying that I was.

Both were delievered to the same alias.

I also haven't seen anything here since subscribing but perhaps I'm
jumping the gun.... it has only been 2 hours.
-- 
Good code works on most inputs; correct code works on all inputs.
My emails do not have attachments; it's a digital signature that your mail
program doesn't understand. | http://www.subspacefield.org/~travis/ 
If you are a spammer, please email [email-masked] to get blacklisted.