Jeffrey Altman wrote:
Solving the phishing problem requires changes on many levels:
(1) Some form of secure chrome for browsers must be deployed where
the security either comes from a trusted desktop or by per-user
customizations that significantly decrease the chances that the
exactly unrelated.
re:
http://www.garlic.com/~lynn/aadsm23.htm#45 Status of SRP
http://www.garlic.com/~lynn/aadsm23.htm#49 Status of SRP
http://www.garlic.com/~lynn/aadsm23.htm#50 Status of SRP
http://www.garlic.com/~lynn/aadsm23.htm#53 Status of SRP
the financial standards x9a10 working group had been
On Wed, 7 Jun 2006, John Brazel wrote:
What we really need is something similar to the built-in remember
my password functionality of current web browsers: the browser keeps
track of a login/password/certified (ie TLS certificate-backed) DNS name
tuple...
[...]
The downside, of course, is
--
Anne Lynn Wheeler wrote:
part of x9.59 retail payment standard requires the
transaction to be authenticated. another part of the
x9.59 retail payment standard requires that the
account number in x9.59 retail payments can't be used
in non-authenticated transactions. it as been
| ...This is the trusted-path problem. Some examples of proposed
| solutions to trusted-path are:
|
| - Dim the entire screen.
| - Use special window borders.
| - Use flashing window borders.
| - Use specially shaped windows.
| - Attach a warning label to all untrusted
* Anne Lynn Wheeler:
Florian Weimer wrote:
FINREAD is really interesting. I've finally managed to browse the
specs, and it looks as if this platform can be used to build something
that is secure against compromised hosts. However, I fear that the
support costs are too high, and that's why
#49 Status of SRP
http://www.garlic.com/~lynn/aadsm23.htm#50 Status of SRP
i got involved in tracking down a virus/trojan like problem in the 70s
on the internal network
http://www.garlic.com/~lynn/subnetwork.html#internalnet
basically if you are going to allow loading of stuff that can do its
On 6/3/06, Florian Weimer fw-at-deneb.enyo.de |Perry's Cryptography mailing
list| ... wrote:
We have no real-world studies how
users make their day-to-day trust decisions when using the Internet.
We do have a beginning, in the study done by Garfinkel, Miller and Wu at MIT
James A. Donald wrote:
--
Jeffrey Altman wrote:
Unfortunately, SRP is not the solution to the phishing
problem. The phishing problem is made up of many
subtle sub-problems involving the ease of spoofing a
web site and the challenges involved in securing the
enrollment and password
--
Jeffrey Altman wrote:
Unfortunately, SRP is not the solution to the phishing
problem. The phishing problem is made up of many
subtle sub-problems involving the ease of spoofing a
web site and the challenges involved in securing the
enrollment and password change mechanisms.
With SRP,
--
Lance James wrote:
Here's where SRP fails:
1) SSL is built into the browser - doesn't stop
phishers
SSL protects true names, SRP protects true
relationships. Protecting true names turned out to be
not very useful.
Hi, we're having a problem with your account system
as our SRP
* Ka-Ping Yee:
Passpet's strategy is to customize a button that you click. We
are used to recognizing toolbar buttons by their appearance, so
it seems plausible that if the button has a custom per-user icon,
users are unlikely to click on a spoofed button with the wrong
icon. Unlike other
* Anne Lynn Wheeler:
Florian Weimer wrote:
If you've deployed two-factor authentication (like German banks did in
the late 80s/early 90s), the relevant attacks do involve compromised
customer PCs. 8-( Just because you can't solve it with your technology
doesn't mean you can pretend the
On Thu, 1 Jun 2006, Jeffrey Altman wrote:
Solving the phishing problem requires changes on many levels:
I agree.
(1) Some form of secure chrome for browsers must be deployed where
the security either comes from a trusted desktop or by per-user
customizations that significantly
Florian Weimer wrote:
FINREAD is really interesting. I've finally managed to browse the
specs, and it looks as if this platform can be used to build something
that is secure against compromised hosts. However, I fear that the
support costs are too high, and that's why it hasn't caught on in
://www.garlic.com/~lynn/aadsm23.htm#49 Status of SRP
another aspect was that there was a program in the past to give away
smartcards and card readers to consumers as part of doing smartcard
financial transactions. the issue at the time was that deployed support
for pc/sc standard only supported pc serial
James A. Donald wrote:
The obvious solution to the phishing crisis is the widespread deployment
of SRP, but this does not seem to happening. SASL-SRP was recently
dropped. What is the problem?
Unfortunately, SRP is not the solution to the phishing problem.
The phishing problem is made up of
Here's where SRP fails:
1) SSL is built into the browser - doesn't stop phishers
2) Chrome or no chrome good luck getting it in there and having every
user understand it.
3) Traditional phishing works, but if you force them to change, the
malware propagation will only be higher than it is now,
On Thu, 1 Jun 2006, James A. Donald wrote:
Florian Weimer wrote:
There is no way to force an end user to enter a
password only over SRP.
Phishing relies on the login page looking familiar. If
SRP is in the browser chrome, and looks strikingly
different from any web page, the login page
On Thu, 1 Jun 2006, Florian Weimer wrote:
That is an all purpose argument that is deployed
selectively against some measures and not others.
If you've deployed two-factor authentication (like German banks did in
the late 80s/early 90s), the relevant attacks do involve compromised
customer
--
Ka-Ping Yee wrote:
Passpet's strategy is to customize a button that you
click. We are used to recognizing toolbar buttons by
their appearance, so it seems plausible that if the
button has a custom per-user icon, users are unlikely
to click on a spoofed button with the wrong icon.
--
Ka-Ping Yee wrote:
Passpet's strategy is to customize a button that you
click. We are used to recognizing toolbar buttons by
their appearance, so it seems plausible that if the
button has a custom per-user icon, users are unlikely
to click on a spoofed button with the wrong icon.
Florian Weimer wrote:
If you've deployed two-factor authentication (like German banks did in
the late 80s/early 90s), the relevant attacks do involve compromised
customer PCs. 8-( Just because you can't solve it with your technology
doesn't mean you can pretend the attacks don't happen.
EU
On Wed, May 31, 2006 at 09:41:57AM +1000, James A. Donald wrote:
The obvious solution to the phishing crisis is the widespread deployment
of SRP, but this does not seem to happening. SASL-SRP was recently
dropped. What is the problem?
The obvious solution is perhaps more difficult to
On Wed, 31 May 2006, James A. Donald wrote:
The obvious solution to the phishing crisis is the widespread deployment
of SRP, but this does not seem to happening. SASL-SRP was recently
dropped. What is the problem?
Phishing can mean a few different things. If by phishing you
mean the
James A. Donald wrote:
The obvious solution to the phishing crisis is the widespread
deployment of SRP, but this does not seem to happening. SASL-SRP was
recently dropped. What is the problem?
I disagree here, I don't think this will stop phishing for many reasons.
Please explain how it
Lance James wrote:
James A. Donald wrote:
The obvious solution to the phishing crisis is the widespread
deployment of SRP, but this does not seem to happening. SASL-SRP was
recently dropped. What is the problem?
I want to clarify, because by typing to fast, i think my
Quoting James A. Donald [EMAIL PROTECTED]:
The obvious solution to the phishing crisis is the widespread
deployment of SRP, but this does not seem to happening. SASL-SRP was
recently dropped. What is the problem?
Patents.
-derek
--
Derek Atkins, SB '93 MIT EE, SM '95 MIT Media
- Original Message -
From: James A. Donald [EMAIL PROTECTED]
Subject: Status of SRP
The obvious solution to the phishing crisis is the widespread deployment
of SRP, but this does not seem to happening. SASL-SRP was recently
dropped. What is the problem?
The problem is that you're
* James A. Donald:
The obvious solution to the phishing crisis is the widespread
deployment of SRP, but this does not seem to happening. SASL-SRP was
recently dropped. What is the problem?
There is no way to force an end user to enter a password only over
SRP. That's why SRP is not
--
Ka-Ping Yee wrote:
Phishing can mean a few different things. If by
phishing you mean the stealing of passwords, then
yes, SRP would help to eliminate that problem, but
users could still be fooled into giving away their SRP
passwords if the user interface for entering the
password is
--
James A. Donald wrote:
The obvious solution to the phishing crisis is the
widespread deployment of SRP
Lance James
I disagree here, I don't think this will stop phishing
for many reasons. Please explain how it would. It will
stop man-in-the-middle attacks on the protocol, but
--
Florian Weimer wrote:
There is no way to force an end user to enter a
password only over SRP.
Phishing relies on the login page looking familiar. If
SRP is in the browser chrome, and looks strikingly
different from any web page, the login page will not
look familiar.
Fortunately, it
On Thu, 1 Jun 2006, James A. Donald wrote:
SRP necessarily runs in the chrome, in the client
software, not in the web page, therefore the chrome,
should put up an image that cannot be convincingly
imitated by html
Sure, i agree. I only brought this up to point out that SRP
alone doesn't
The obvious solution to the phishing crisis is the widespread deployment
of SRP, but this does not seem to happening. SASL-SRP was recently
dropped. What is the problem?
-
The Cryptography Mailing List
Unsubscribe by sending
35 matches
Mail list logo
