"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 pa
On Sun, Oct 12, 2008 at 7:39 AM, Ben Laurie <[EMAIL PROTECTED]> wrote:
>
> One argument that I
> have increasing sympathy with is that SSO (or if you want to be modern,
> federated login)
Federated identity is the fancy modern term for cross-domain SSO.
> Obviously the end game here is that the u
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: Tak
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
>> st
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 chall
"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
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 th
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
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
"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 pass
"Steven M. Bellovin" <[EMAIL PROTECTED]> writes:
>[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
>> c
Eric Rescorla wrote:
This is precisely the issue.
There are any number of cryptographic techniques that would allow
clients and servers to authenticate to each other in a phishing
resistant fashion, but they all depend on ensuring that the
*client* has access to the password and that the attacke
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
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 s
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 orde
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 tha
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,
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, ope
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, t
> ... 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, 'investmen
"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 d
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 pa
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
[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.
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 wor
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
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 (o
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 browse
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 ea
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 o
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 ou
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... ?
Su
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
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" (
http:/
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
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
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 explanation
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?
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 expla
39 matches
Mail list logo