Usability research about how to track web users? How Google-like.
Can't you just dump a 25-year cookie on them from twelve different
directions, and be done with it?
Federated Login has been a holy grail in the identity community
for a long time. We have known how to do the technical part
Peter Gutmann wrote:
If this had been done in the beginning, before users -- and web site
designers, and browser vendors -- were mistrained, it might have worked.
Now, though? I'm skeptical.
For existing apps with habituated users, so am I. So how about the following
strawman: Take an
Peter Gutmann wrote:
For existing apps with habituated users, so am I. So how about the following
strawman: Take an existing browser (say Firefox), brand it as some special-
case secure online banking browser, and use the new developments solution
above, i.e. it only talks mutual-auth
Combining several replies into one...
Nicolas Williams [EMAIL PROTECTED] writes:
On Mon, Sep 22, 2008 at 08:59:25PM -1000, James A. Donald wrote:
The major obstacle is that the government would want a strong binding
between sim cards and true names, which is no more practical than a
strong
Leichter, Jerry [EMAIL PROTECTED] writes:
The sitation today is (a) the decreasing usefulness of passwords - those
anyone has a chance of remembering are just to guessable in the face of the
kinds of massive intelligent brute force that's possible today and (b) the
inherently insecure password
Leichter, Jerry wrote:
The problem is what that something else should be. Keyfobs with
one-time passwords are a good solution from the pure security point
of view, but (a) people find them annoying; (b) when used with
existing input mechanisms, as they pretty much universally are, are
subject
Peter Gutmann wrote:
The problem is that the default has always been to be insecure, and there's no
effective way to get people to move to the secure non-default, or at least
none that isn't relatively easily circumvented by a bit of creative thinking
and/or social engineering.
If the user is
On Mon, Sep 22, 2008 at 08:59:25PM -1000, James A. Donald wrote:
The major obstacle is that the government would want a strong binding
between sim cards and true names, which is no more practical than a
strong binding between physical keys and true names.
I've a hard time believing that this
James A. Donald [EMAIL PROTECTED] writes:
If the user is used to logging in by a user interface that is not easy
for forge remotely - click on bookmark to bring up a user interface
that is difficult to remotely forge - then this does indeed work.
It might have been secure enough back in the
On Sun, 21 Sep 2008, Eric Rescorla wrote:
| - Use TLS-PSK, which performs mutual auth of client and server
| without ever communicating the password
| Once upon a time, this would have been possible, I think. Today,
| though, the problem is the user entering their key in a box that is
|
On Thu, 18 Sep 2008 17:18:00 +1200
[EMAIL PROTECTED] (Peter Gutmann) wrote:
- Use TLS-PSK, which performs mutual auth of client and server
without ever communicating the password. This vastly complicated
phishing since the phisher has to prove advance knowledge of your
credentials in order
At Sat, 20 Sep 2008 15:55:12 -0400,
Steven M. Bellovin wrote:
On Thu, 18 Sep 2008 17:18:00 +1200
[EMAIL PROTECTED] (Peter Gutmann) wrote:
- Use TLS-PSK, which performs mutual auth of client and server
without ever communicating the password. This vastly complicated
phishing since the
IanG [EMAIL PROTECTED] writes:
Any evidence of that? [People buying certs using stolen credit cards]
I don't know if anyone tracks the exact count (apart from the 2005 figure of
(at least) 450 recorded incidents of secure phishing) but every now and then
you get reports of particular ones that
Dirk-Willem van Gulik [EMAIL PROTECTED] writes:
As to technical options to accomplish this
The mechanisms for this actually already exist, they're just not used. First
of all, you need to admit that you have a problem: SSL certs by themselves are
more or less useless in providing assurance, the
Dirk-Willem van Gulik wrote:
... discussion on CA/cert acceptance hurdles in the UI
I am just wondering if we need a dose of PGP-style reality here.
We're really seeing 3 or 4 levels of SSL/TLS happening here - and whilst
they all appear use the same technology - the assurances, UI,
... discussion on CA/cert acceptance hurdles in the UI
I am just wondering if we need a dose of PGP-style reality here.
We're really seeing 3 or 4 levels of SSL/TLS happening here - and whilst
they all appear use the same technology - the assurances, UI,
operational
regimen,
James A. Donald [EMAIL PROTECTED] writes:
Visualize Obama, McCain, or Sarah Palin setting up your network security.
Then realize that whoever they appoint as Czar in charge of network security
is likely to be less competent than they are.
You're think about this from the wrong angle. We don't
Darren J Moffat wrote:
Warnings aren't enough in this context [ whey already exists ] the
only thing that will work is stopping the page being seen - replacing
it with a clearly worded explanation with *no* way to pass through
and render the page (okay maybe with a debug build of the browser
At 11:21 PM +0100 9/9/08, Dave Howe wrote:
Darren J Moffat wrote:
Warnings aren't enough in this context [ whey already exists ] the
only thing that will work is stopping the page being seen - replacing
it with a clearly worded explanation with *no* way to pass through
and render the page
Dave Howe wrote:
One thing that concerns me is that in the new release of firefox, there
appears to be NO way to get to a site that has a bad certificate (or
self signed certificate) other than overriding the warning permanently -
no ok let me see it, I have seen the warning and want to look
James A. Donald wrote:
Peter Gutmann wrote:
Unfortunately I think the only way it (and a pile of other things as
well) may get stamped out is through a multi-pronged approach that
includes legislation, and specifically properly thought-out
requirements
I agree. I'm sure this is a
[Moderator's note: with my other hat on, let me say that although I'm
a libertarian, I do not want to have this mailing list fill with
libertarianism vs. statism arguments. I'm going to cut this off pretty
quickly. --Perry-as-moderator]
William Allen Simpson [EMAIL PROTECTED] writes:
I agree.
On Wed, Sep 10, 2008 at 01:29:32PM -0400, William Allen Simpson wrote:
I agree. I'm sure this is a world-wide problem, and head-in-the-sand
cyber-libertarianism has long prevented better solutions. The market
doesn't work for this, as there is a competitive *disadvantage* to
providing
Paul Hoffman wrote:
At 11:21 PM +0100 9/9/08, Dave Howe wrote:
Darren J Moffat wrote:
Warnings aren't enough in this context [ whey already exists ] the
only thing that will work is stopping the page being seen - replacing
it with a clearly worded explanation with *no* way to pass through
On Mon, 8 Sep 2008, Adam Shostack wrote:
What makes now the perfect time to address an issue which has been
present for quite soem time?
I'd turn that question around, and ask what makes now such a bad time to
address an issue that's been present (and not addressed) for quite some
time... ?
Darren J Moffat [EMAIL PROTECTED] writes:
I believe the only way both of these highly dubious deployment practices will
be stamped out is when the browsers stop allowing users to see such web pages.
Unfortunately I think the only way it (and a pile of other things as well) may
get stamped out
Peter Gutmann writes, in part:
-+
| ... - the rate-limiting step is the fact that
| the crooks simply can't use all the stolen identities
| they have, not any security measures that may be present.
| ...
To my knowledge, you are correct. It seems that the
price
Peter Gutmann wrote:
Unfortunately I think the only way it (and a pile of other things as well) may
get stamped out is through a multi-pronged approach that includes legislation,
and specifically properly thought-out requirements rather than big-business-
bought legislation like UCITA/UCC or
I was shocked that several people posted in response to Peter
Gutmann's note about Wachovia, asking (I paraphrase):
What is the problem here? Wachovia's front page is only http
protected, but the login information is posted with https! Surely this
is just fine, isn't it?
I'm not going to
Perry E. Metzger wrote:
I was shocked that several people posted in response to Peter
Gutmann's note about Wachovia, asking (I paraphrase):
What is the problem here? Wachovia's front page is only http
protected, but the login information is posted with https! Surely this
is just fine, isn't it?
At 4:16 PM +0100 9/8/08, Darren J Moffat wrote:
Hopefully this is interesting enough to get forwarded on...
Ditto. :-)
Warnings aren't enough in this context [ whey already exists ] the
only thing that will work is stopping the page being seen -
replacing it with a clearly worded
Paul Hoffman wrote:
A less extreme solution would be to make the warning the user sees on a
mixed-content page more insulting to the bank. This page contains both
encrypted and non-encrypted content and is inherently insecure. The
owner of this web site has clearly made a very poor security
Arshad Noor wrote:
A more optimal solution is to have this vulnerability accepted by
the OWASP community as a Top 10 security vulnerability; it will
have the appropriate intended effect since mitigation to the OWASP
defined vulnerabilities is required in PCI-DSS:
6.5 Develop all web
Darren Lasko wrote:
Arshad Noor wrote:
6.5 Develop all web applications based on secure coding guidelines
such as the Open Web Application Security Project guidelines
Isn't this vulnerability already in the Top 10, specifically A7 - Broken
Authentication and Session Management (
On Mon, Sep 08, 2008 at 04:16:46PM +0100, Darren J Moffat wrote:
|
| I believe the only way both of these highly dubious deployment practices
| will be stamped out is when the browsers stop allowing users to see such
| web pages. So that there becomes a directly attributable financial
| impact
35 matches
Mail list logo
