Passwords jump-started Fumo probe

2006-10-13 Thread Nick Owen
http://www.philly.com/mld/inquirer/news/local/states/pennsylvania/counties/philadelphia_county/philadelphia/15727557.htm

The feds were unable to break the encrypted email files until one admin
came up with a password list on a portable drive.  I wonder if they
tried to brute-force the password?

nick

-- 
Nick Owen
WiKID Systems, Inc.
404.962.8983
http://www.wikidsystems.com
Commercial/Open Source Two-Factor Authentication
https://www.linkedin.com/in/nickowen

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: NSA knows who you've called.

2006-05-13 Thread Nick Owen
Perry E. Metzger wrote:
 [EMAIL PROTECTED] writes:
 While I agree with you, the public does not,
 so far as I can tell, find itself willing to
 risk insecurity for the benefit of preserving
 privacy, as this article in today's Boston
 Globe would tend to confirm.
 
 I'm sure. On the other hand, I think it is our place, as security
 professionals, to explain why the tradeoff is a false one. Respect for
 individual rights is not something we do in good times because it is a
 luxury we can afford when there is stability. It is something we need
 most in bad times, because it is what keeps us safe and maintains
 stability itself.

Or to teach pollsters to ask the correct questions.  Take this survey:
http://www.washingtonpost.com/wp-srv/politics/polls/postpoll_nsa_051206.htm

What it this question from the poll:
It's been reported that the National Security Agency has been collecting
the phone call records of tens of millions of Americans. It then
analyzes calling patterns in an effort to identify possible terrorism
suspects, without listening to or recording the conversations. Would you
consider this an acceptable or unacceptable way for the federal
government to investigate terrorism? Do you feel that way strongly or
somewhat?

Was instead:
The NSA has been collecting the phone call records of tens of millions
of Americans possibly in violation of the law.  Would you consider it
acceptable for the government to break the law to investigate terrorism?

Nick

-- 
Nick Owen
WiKID Systems, Inc.
404.962.8983
http://www.wikidsystems.com
Commercial/Open Source Two-Factor Authentication
https://www.linkedin.com/in/nickowen

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: HTTPS mutual authentication alpha release - please test

2005-11-07 Thread Nick Owen
James A. Donald wrote:
 --
 It seems to me that mutual authentication is pretty much
 irrelevant to HTTPS and certificates.  You mutually
 authenticate by both knowing the password, as in SPEKE.
 
 Of course, SPEKE is patented, so is this scheme a way of
 getting around the patents?

We're not that smart - well, perhaps I should speak only for myself.  We
originally developed WiKID to target corporate VPNs with the WiKID
client running on a wireless device (the Wi in WiKID) with no thought of
mutual authentication because phishing was only getting under way.  Only
after we added the client support for Windows, Mac  linux and phishers
started getting really active did we think about adding MA.

 
 --digsig
  James A. Donald
  6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
  a5RzA9UesxiZw+cjRsz+8yPLKwJdTMfUjcQq0iZf
  4ybo9wAzZZNG5YyF69jzKw/oXw3fL7FGj86oXey46
 
 
 -
 The Cryptography Mailing List
 Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
 

-- 
Nick Owen
WiKID Systems, Inc.
404.962.8983 (desk)
404.542.9453 (cell)
http://www.wikidsystems.com
At last, two-factor authentication, without the hassle factor
Now open source: http://sourceforge.net/projects/wikid-twofactor/

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: HTTPS mutual authentication alpha release - please test

2005-11-04 Thread Nick Owen
cyphrpunk wrote:
 On 11/3/05, Nick Owen [EMAIL PROTECTED] wrote:
 
The token client pulls down a hash of the certificate from the
WiKID server. It pulls the certificate from the website and performs a
hash on it.  It compares the two hashes and if they match, presents the
user with the OTP and the message:
This URL has been validated. It is now safe to proceed.
 
 
 Let me see if I understand the attack this defends against. The user
 wants to access https://www.citibank.com. The phisher uses DNS
 poisoning to redirect this request away from the actual citibank
 machine to a machine he controls which puts up a bogus citibank page.
 To deal with the SSL, the phisher has also managed to acquire a fake
 citibank certificate from a trusted CA(!). He fooled or suborned the
 CA into granting him a cert on citibank.com even though the phisher
 has no connections with citibank. He can now use this bogus cert to
 fool the client when it sets up the SSL connection to citibank.com.
 
 Is this it? This is what your service will defend against, by
 remembering the hash of the true citibank certificate?

No, this is not it.  It is this attack and similar:

http://tinyurl.com/a3b89

The phishers are not using valid certificates, but users are so immune
to warnings about certificates that they don't pay attention to them.
It may be a DNS cache poison or the typical email; it could be any
mechanism to send the user to a fraudulent site.  What is being provided
is a mechanism to route the users to the correct site by providing a way
to validate the certificate for them.

nick


-- 
Nick Owen
WiKID Systems, Inc.
404.962.8983 (desk)
404.542.9453 (cell)
http://www.wikidsystems.com
At last, two-factor authentication, without the hassle factor
Now open source: http://sourceforge.net/projects/wikid-twofactor/

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: HTTPS mutual authentication alpha release - please test

2005-11-03 Thread Nick Owen
cyphrpunk wrote:
 On 10/31/05, Nick Owen [EMAIL PROTECTED] wrote:
 
The system works this way: Each WiKID domain now can include a
'registered URL' field and a hash that website's SSL certificate.  When
a user wants to log onto a secure web site, they start the WiKID token
and enter their PIN. The PIN is encrypted and sent to the WiKID server
along with a one-time use AES key and the registered URL.  The server
responds with a hash of the website's SSL certificate.  The token client
fetches the SSL certificate of the website and compares it the hash.  If
the hashes don't match, the user gets an error.  If they match, the user
is presented with registered URL and the passcode.  On supported
systems, the token client will launch the default browser to the
registered URL.
 
 
 What threat is this supposed to defend against? Is it phishing? I
 don't see how it will help, if the bogus site has a valid certificate.

Yes, phishing.  The token client isn't checking to see if the cert is
valid, it's only checking to see if it's the same as the one that is on
the WiKID authentication server.  The cert doesn't have to be valid or
have the root CA in the browser.

 
 
Most one-time-password systems suffer from man-in-the-middle attacks
primarily due to difficulties users have with validating SSL
certificates. The goal of this release is to validate certificates for
the end user, providing an SSH-esque security for web-enabled
applications such as online banking.
 
 
 What does it mean to validate a certificate? Aren't certs
 self-validating, based on the key of the issuer? Again, what is this
 protecting against?

Bad choice of words on my part - validate is a loaded word vis-a-vis
certs.  The token client pulls down a hash of the certificate from the
WiKID server. It pulls the certificate from the website and performs a
hash on it.  It compares the two hashes and if they match, presents the
user with the OTP and the message:
This URL has been validated. It is now safe to proceed.

Does that clarify?

 
 CP
 

-- 
Nick Owen
WiKID Systems, Inc.
404.962.8983 (desk)
404.542.9453 (cell)
http://www.wikidsystems.com
At last, two-factor authentication, without the hassle factor
Now open source: http://sourceforge.net/projects/wikid-twofactor/

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: HTTPS mutual authentication alpha release - please test

2005-11-03 Thread Nick Owen


What threat is this supposed to defend against? Is it phishing? I
don't see how it will help, if the bogus site has a valid certificate.

Yes, phishing.  The token client isn't checking to see if the cert is
valid, it's only checking to see if it's the same as the one that is on
the WiKID authentication server.  The cert doesn't have to be valid or
have the root CA in the browser.
 
 
 But this would only help in the case that an old URL is used and a new
 certificate appears, right? That's what would be necessary to get a
 match in your database, pull down an old certificate, and find that it
 doesn't match the new certificate.

The token client has the true URL as well, so the traditional phish of
sending users to the wrong site shouldn't work either.  The user would
have to ignore the launched browser and use the fake site.
 
 Phishers don't do this. They don't send people to legitimate URLs
 while somehow contriving to substitute their own bogus certificates.
 They send people to wrong URLs that may have perfectly valid
 certificates issued for them. I don't see how your system defends
 against what phishers actually do.

They do this too by attacking DNS servers with cache poisoning.  In this
case the token client will not be able to validate the certificate.

nick

-- 
Nick Owen
WiKID Systems, Inc.
404.962.8983 (desk)
404.542.9453 (cell)
http://www.wikidsystems.com
At last, two-factor authentication, without the hassle factor
Now open source: http://sourceforge.net/projects/wikid-twofactor/

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


HTTPS mutual authentication alpha release - please test

2005-10-31 Thread Nick Owen
Happy Halloween! In what we hope will be a Halloween tradition, we have
new release available for testing. WiKID is pleased to announce the
alpha release of a major upgrade under the GPL featuring a cryptographic
method of mutual authentication for HTTPS:

WiKID-2.1: SOMETHING_WiKID_THIS_WAY_COMES

The token client is available at sourceforge:
http://prdownloads.sourceforge.net/wikid-twofactor/WiKID_Token_Client-2.1-prerelease.zip?download

The system works this way: Each WiKID domain now can include a
'registered URL' field and a hash that website's SSL certificate.  When
a user wants to log onto a secure web site, they start the WiKID token
and enter their PIN. The PIN is encrypted and sent to the WiKID server
along with a one-time use AES key and the registered URL.  The server
responds with a hash of the website's SSL certificate.  The token client
fetches the SSL certificate of the website and compares it the hash.  If
the hashes don't match, the user gets an error.  If they match, the user
is presented with registered URL and the passcode.  On supported
systems, the token client will launch the default browser to the
registered URL.

We are currently seeking testers for this early release.  You do not
need to set up a WiKID server to test. We have set up a WiKID server for
you.  Testers will need to download the latest J2SE WiKID token from
sourceforge.  Testing information can be found here:

https://sourceforge.net/forum/forum.php?thread_id=1376617forum_id=484250

Most one-time-password systems suffer from man-in-the-middle attacks
primarily due to difficulties users have with validating SSL
certificates. The goal of this release is to validate certificates for
the end user, providing an SSH-esque security for web-enabled
applications such as online banking.

Any feedback is much appreciated.

Sincerely,

Nick
-- 
Nick Owen
WiKID Systems, Inc.
404.962.8983 (desk)
404.542.9453 (cell)
http://www.wikidsystems.com
At last, two-factor authentication, without the hassle factor
Now open source: http://sourceforge.net/projects/wikid-twofactor/

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: US Banks: Training the next generation of phishing victims

2005-10-12 Thread Nick Owen
Peter Gutmann wrote:
 
 Can anyone who knows Javascript better than I do figure out what the mess of
 script on those pages is doing?  It looks like it's taking the username and
 password and posting it to an HTTPS URL, but it's rather spaghetti-ish code so
 it's a bit hard to follow what's going where.
 

Why have the log on your homepage at all? Why not just a link to the
https login???  If the goal is to not have SSL overhead on the homepage,
don't.  Or is there some extra overhead for login processing that I
don't know about?  Is there some user dissatisfaction with an extra
click to login?

I suppose if you really wanted non-SSL logins, you could use a one-time
passcodes system with variable length passcodes to prevent race attacks.


-- 
Nick Owen
WiKID Systems, Inc.
404.962.8983 (desk)
404.542.9453 (cell)
http://www.wikidsystems.com
At last, two-factor authentication, without the hassle factor

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


update: GPL'd two-factor system

2005-10-04 Thread Nick Owen
Greetings:

Here is a brief update on the open source version of the WiKID Strong
Authentication System:

* New PHP network client released
* SugarCRM network client released (based on PHP network client)
* Citrix Web Interface network client released
* Java token client binary released
* Minor code fixes and clean up on the server
* Added the WiKID white paper to the downloads section

All this and more available for download on sf.net:

http://sourceforge.net/projects/wikid-twofactor/

The project home page is http://www.wikidsystems.net/, which includes a
poll on what applications people would like to see WiKID-enabled.
Work is progressing on C and Python network clients to add to the Java
and COM objects and those listed above. Our focus is on adding network
clients in new languages and implementing those into applications.

Regards,

Nick


-- 

Nick Owen
WiKID Systems, Inc.
404.962.8983 (desk)
404.542.9453 (cell)
http://www.wikidsystems.com
At last, two-factor authentication, without the hassle factor


-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: ECC patents?

2005-09-15 Thread Nick Owen
James A. Donald wrote:
 --
 Whyte, William:
 
It hints that only some particular curves have been 
licensed. It could be that NSA has decided not to buy 
a license for the other curves, or it could be that 
operations on those curves aren't patented. The 
presentation doesn't give enough information to 
establish which.
 
 
 If the NSA paid anything significant for any of the 
 curves, we would be told.  Therefore the NSA paid
 nothing or almost nothing, and therefore if the NSA 
 licensed anything, it would have licensed everything.
 
 I doubt that the NSA paid any money whatsoever for this 
 license, making it profoundly unimpressive as evidence 
 that *any* curves have a plausible valid patent.  If the 
 NSA paid real money, the patent holders would be 
 sticking it in our face as a price setting precedent. 

I had a recent discussion with a person in a government agency that
indicated we would not be able to use them as a reference and that they
would probably want an unlimited license - because there could be no
reference to a number of users within the agency.  They did say that
they would get GSA pricing.  I suspect that Certicom got GSA pricing for
the deal as is, I assume, required by law.

Nick


-- 

Nick Owen
WiKID Systems, Inc.
404.962.8983 (desk)
404.542.9453 (cell)
http://www.wikidsystems.com
https://sourceforge.net/projects/wikid-twofactor/

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Another entry in the internet security hall of shame....

2005-08-29 Thread Nick Owen
I would appreciate your thoughts on WiKID.  We use asymmetric keys to
encrypt PINs and one-time passcodes between a client and the server. The
server talks to various network clients using protocols such as LDAP,
Radius, or using our own SSL-tunneled wAuth protocol.  We believe that
replacing passwords is the right economic model to fund PK deployment
widely to consumers.  The client can then be extended to provide
encryption for apps such as the credit card app described below.

We have just released version of WiKID under the GPL.  The GPL client
uses RSA encryption.  The non-GPL version uses Ntru, making it suitable
for wireless clients (RSA key gen on a java cell phone is a bitch).

We have set up http://www.wikidsystems.net as our open source home page
and https://sourceforge.net/projects/wikid-twofactor/ is the sourceforge
project page as well - which includes a white paper and documentation.
Comments and contributions are much appreciated.

tia,

Nick

Ian G wrote:
 Anne  Lynn Wheeler wrote:
 
 the major ISPs are already starting to provide a lot of security
 software to their customers.

 a very straight forward one would be if they provided public key
 software ... to (generate if necessary) and register a public key in
 lieu of password ... and also support the PPP  radius option of having
 digital signature authentication in lieu of password checking
 http://www.garlic.com/~lynn/subpubkey.html#radius
 
 
 Right.  And do the primary authentication of the key
 using some other mechanism that is outside the strict
 crypto.
 
 (IOW, Dave, your plan will work, as long as it is
 built from ground up with no prior baggage!  IMHO!)
 
 This is such a no-brainer that when I first came
 across the solution over a decade ago now, I never
 gave a thought as to how it could be anything but
 the one way to do things.  It just works, and very
 little else works anywhere as well.
 
 Yet, we are still grubbing around like cavemen in
 the mud.  And then there is this:
 
 http://www.business2.com/b2/web/articles/print/0,17925,1096807,00.html
 
 $5M  Mobile ID for Credit Card Purchases
 WHO: John Occhipinti, Woodside Fund, Redwood Shores, Calif.
 WHO HE IS: A former executive at Oracle and Netscape, Occhipinti is a
 managing director and security specialist, leading investments in
 BorderWare and Tacit.
 WHAT HE WANTS: Fraudproof credit card authorization via cell phones and
 PDAs.
 WHY IT'S SMART: Credit card fraud is more rampant than ever, and
 consumers aren't the only ones feeling the pain. Last year banks and
 merchants lost more than $2 billion to fraud. Most of that could be
 eliminated if they offered two-part authentication with credit and debit
 purchases -- something akin to using a SecureID code as well as a
 password to access e-mail. Occhipinti thinks the cell phone, packaged
 with the right software, presents an ideal solution. Imagine getting a
 text message on your phone from a merchant, prompting you for a password
 or code to approve the $100 purchase you just made on your home PC or at
 the mall. It's an extra step, but one that most consumers would be happy
 to take to safeguard their privacy. More important, Occhipinti says, big
 banks would pay dearly to be able to offer the service. It's a killer
 app no one's touched yet, Occhipinti says, but the technology's within
 reach.
 WHAT HE WANTS FROM YOU: A finished prototype application within eight
 months. I'm looking for the best technologists in security and
 wireless, the top 2 percent in their industry, Occhipinti says. The
 team would need to be working with a handful of banks and merchants
 ready to start trials, in hopes of licensing the technology or selling
 the company.
 SEND YOUR PLAN TO: [EMAIL PROTECTED]
 
 The funniest part of all is that even though we
 know how to do it in our sleep, Paypal actually
 built one as their original offering and threw
 it away...
 
 at that point your public key is now registered with your ISP ... and
 possibly could be used for other things as well ... and scaffolding for
 a certificateless trust infrastructure.
 
 
 Yup.  But this will only work if you go back to
 basics and build the structure naturally around
 the keys.  IOW, not using anything from PKI.
 
 lots  lots of past postings on SSL landscape
 http://www.garlic.com/~lynn/subpubkey.html#sslcert
 
 
 Watching security thinking advance is like watching
 primates evolve from close distance.  Either we die
 of old age before anything happens, or we get clubbed
 to death...
 
 iang
 
 -
 The Cryptography Mailing List
 Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
 

-- 

Nick Owen
WiKID Systems, Inc.
404.962.8983 (desk)
404.542.9453 (cell)
http://www.wikidsystems.com
At last, two-factor authentication, without the hassle factor

-
The Cryptography Mailing List
Unsubscribe by sending

Re: the limits of crypto and authentication

2005-07-11 Thread Nick Owen
I think the failure of Amex Blue is due to poor timing and the
requirement for hardware on the end-user's PC.  At the time of it's
introduction ecommerce and online banking were just getting started and
consumers were more worried about whether the store was real or not than
having their card stolen.  It wasn't until identity theft and the rush
of disclosures due to SB1386 et al here in the US that people cared
about security and privacy (in some way).

What I can't understand is why Visa and Amex haven't started to push
their one-time credit card software solutions again - this time as
protection for your privacy.  I would think people would be much more
receptive to it now.  Little has changed, except the market's perception
of the risk of using credit cards online. Amex actually pulled their
program in 2004, IIRC.

[EMAIL PROTECTED] wrote:
 Nick Owen writes:
  | I think that the cost of two-factor authentication will plummet in the
  | face of the volumes offered by e-banking.
 
 Would you or anyone here care to analyze
 what I am presuming is the market failure
 of Amex Blue in the sense of its chipcard
 and reader combo?
 
 --dan
 
 
 -
 The Cryptography Mailing List
 Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
 

-- 

Nick Owen
WiKID Systems, Inc.
404.962.8983 (desk)
404.542.9453 (cell)
http://www.wikidsystems.com
At last, two-factor authentication, without the hassle factor

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: the limits of crypto and authentication

2005-07-11 Thread Nick Owen
I think the difference now is the number of vendors entering the market,
 the variety of solutions ( and their relative security), and demand
outside of Europe.  When we started in mid-2001, we were looking at the
existing hardware guys and that is it.  Now there a handful of
venture-backed software players with different solutions all targeting
the banking market, which didn't exist then.

We have not seen any interest in our two-factor solution from Germany or
any country where they have some form of two-factor authentication.
Perhaps this is similar to the US corporate market where companies that
have tokens aren't very interested in switching to save money - the CSO
only takes risk in switching and sees no personal benefit in reducing
costs (my theory at least) so there's no true vetting, only beating up
the current vendor for a slightly better deal. Thus your banks will
still complain that the price of mailing paper is too high, which of
course it is when compared to software tokens.

We are, however, seeing interest from US and South American banks and
the numbers are huge and we will be very aggressive in pricing.  We also
see that we are competing against companies that use IP address
verification, secure cookies and other things that are readily
compromised, but apparently easy to roll-out and maintain and
inexpensive.  So, we have to compete against those substitutes that
don't even use cryptography or two-factor authentication but would be
better termed as fraud detection and prevention.



Florian Weimer wrote:
 * Nick Owen:
 
 
I think that the cost of two-factor authentication will plummet in the
face of the volumes offered by e-banking.
 
 
 I doubt this is true.  In Germany, we already use some form of
 two-factor authentication for Internet banking transaction (account
 number/password and a one-time password for each transaction).  Yet
 banks are desperately looking for alternatives because distributing
 those one-time password lists is too expensive (!).  To me, this was
 quite surprising because it's just one sheet of paper every 200
 transactions or so.
 
 Even worse, this scheme has failed, and there are successful attacks
 in the wild (involving compromised client PCs).  Right now,
 time-dependent tokens do help, but only because you outrun the other
 guy.  The real-time requirements imposed by them are not a fundamental
 obstacle to the attackers, and even now, the way they route the money
 makes it very hard to detect things in real-time (at least on the
 money side).
 
 Well, you can imagine my surprise when Howard Schmidt praised
 two-factor authentication as a solution to our current problems at the
 FIRST 2005 conference. 8-/
 
 -
 The Cryptography Mailing List
 Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
 

-- 

Nick Owen
WiKID Systems, Inc.
404.962.8983 (desk)
404.542.9453 (cell)
http://www.wikidsystems.com
At last, two-factor authentication, without the hassle factor

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: the limits of crypto and authentication

2005-07-09 Thread Nick Owen
It would seem simple to thwart such a trojan with strong authentication
simply by requiring a second one-time passcode to validate the
transaction itself in addition to the session.

Steven M. Bellovin wrote:
 There's been a lot of discussion about how to strengthen cryptography 
 and authentication, to get away from problems of phishing, pharming, 
 etc.  But such approaches can take you only so far, as this link 
 indicates:
 
 http://www.lurhq.com/grams.html
 
 Briefly, it's a Trojan that waits for you to log int o E-Gold, checks 
 your balance, and drains your account except for .004 grams of gold.
 
   --Steven M. Bellovin, http://www.cs.columbia.edu/~smb
 
 
 
 -
 The Cryptography Mailing List
 Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
 

-- 

Nick Owen
WiKID Systems, Inc.
404.962.8983 (desk)
404.542.9453 (cell)
http://www.wikidsystems.com
At last, two-factor authentication, without the hassle factor

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: the limits of crypto and authentication

2005-07-09 Thread Nick Owen
To validate the transaction, a receipt could be sent to the user
encrypted by the server's public key.  If the receipt is correct, the
user enters their PIN to 'sign' the transaction.

I'm assuming an asymmetric authentication system here outside the
browser. The attacker would have to steal the user's private key, their
PIN and the server's private key, correct?

I know that if the PC is compromised anything is possible, but I think
this raises the bar significantly - perhaps to an unprofitably level.

Steven M. Bellovin wrote:
 In message [EMAIL PROTECTED], Nick Owen writes:
 
It would seem simple to thwart such a trojan with strong authentication
simply by requiring a second one-time passcode to validate the
transaction itself in addition to the session.

 
 
 How does the user know which transaction is really being authenticated?
 (I alluded to this in a 1997 panel session talk; see
 http://www.cs.columbia.edu/~smb/talks/ncsc-97/index.htm )
 
   --Steven M. Bellovin, http://www.cs.columbia.edu/~smb
 
 
 

-- 

Nick Owen
WiKID Systems, Inc.
404.962.8983 (desk)
404.542.9453 (cell)
http://www.wikidsystems.com
At last, two-factor authentication, without the hassle factor

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: the limits of crypto and authentication

2005-07-09 Thread Nick Owen
I think that the cost of two-factor authentication will plummet in the
face of the volumes offered by e-banking.  Also, the more uses for the
token, the more shared the costs will be.  The question to me is will
the FIs go with a anything beyond secure cookies, IP address validation
and unique images.  Will they be forced to by the powers that be or by
disclosure requirements after the basic systems are thwarted?

I also think that the lower end cell phone is now capable of handling
the task.  While a PC client may not be very secure, it does offer some
potential benefits such as auto-validating SSL certs.  Whether the
carriers will bother with a potential revenue stream in two-factor
authentication when they can make more money in ringtones is another
question - back to the business model ;).

Ian Grigg wrote:
 FTR, e-gold were aware of the general makeup of this
 threat since 1998 and asked someone to look at it.  The
 long and the short was that it was more difficult to solve
 than at first claimed, so the project was scrapped.  This
 was a good risk-based decision.  The first trojans that I
 know of for e-gold weren't spotted until 12-18 months
 ago, so it was also a profitable decision.  What they are
 doing now I don't know.
 
 In the payments world we've known how to solve all
 this for some time, since the early 90s to my knowledge.
 The only question really is, have you got a business
 model that will pay for it, because any form of token is
 very expensive, and the form of token that is needed -
 a trusted device to put the application, display, keypad
 and net connection on - is even more expensive than
 the stop-gap two-factor authentication units commonly
 sold.
 
 iang

-- 

Nick Owen
WiKID Systems, Inc.
404.962.8983 (desk)
404.542.9453 (cell)
http://www.wikidsystems.com
At last, two-factor authentication, without the hassle factor

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]