On 25/09/11 10:09 AM, James A. Donald wrote:
On 2011-09-25 4:30 AM, Ben Laurie wrote:
I'm just saying I think its hard to detect when a password is being
asked for as part of the risk assessment.
http and https do not know there are such things as logons. Logons
need to be built into the protocol, rather than added on top. Your
browser should know you are logged on.
When using client certs, it works: the browser, the server and https do
know if you're logged on [0].
The problem with HTTPS login is that it was sacrificed at the alter of
some unworkable commercial dream, thus forcing developers to rely on
passwords. Any client cert is better than the current best saved
password situation, because the technical security of a public key pair
always exceeds a password [1]. But while vendors will slave to make
saving passwords easier (so as to cope with the explosion of sites &
contexts) ... they won't work to make client certs better.
All of this (again) aligns well with key continuity / pinning / and
various other buzzwords. But, really, you have to try it. There's no
point in talking about it.
iang
[0] Where, logged in means, is using an appropriate client cert. This
involves an amount of code in the application to figure out, but it
seems about the same amount of code as doing the login the other way,
via passwords and so forth. There are some additional complications
such as new certs, but this is just coding and matching on the names.
[1] this deliberately ignores 1980s advice to remember your password...
_______________________________________________
cryptography mailing list
[email protected]
http://lists.randombit.net/mailman/listinfo/cryptography
