Delayed password disclosure technique

On 3/2/05 9:56 AM, "George Wade" <georgewade1mac.com> wrote:

> Here's an interesting approach for increasing password security and reducing
> phishing.
>
> <http://www.nature.com/news/2005/050221/full/050221-6.html>

Nice idea but it's going to be useless unless you build it into every email
client and web site.

--
John C. Welch Writer/Analyst
Bynkii.com Mac and other opinions
jwelchbynkii.com

At this point it is a discussion in a journal... Possibilities. And
of course the possibilities are not yet final solutions. In fact final
solutions are not final, either and require modifying to keep up with
developments.

On 3/4/05 6:39 AM, "George Wade" <georgewade1mac.com> wrote:

>>> Here's an interesting approach for increasing password security and
>>> reducing
>>> phishing.
>>>
>>> <http://www.nature.com/news/2005/050221/full/050221-6.html>
>>
>> Nice idea but it's going to be useless unless you build it into every
>> email
>> client and web site.
>
> If possibilities don't get discussed no solutions get to see the light
> of day.

There are already solutions, but since they aren't NEW and COOL, no one wants
to use them

--
John C. Welch Writer/Analyst
Bynkii.com Mac and other opinions
jwelchbynkii.com

At 4:33 AM -0800 2005/03/03, John C. Welch wrote:
>On 3/2/05 9:56 AM, "George Wade" <georgewade1mac.com> wrote:
>> Here's an interesting approach for increasing password security and reducing
>> phishing.
>> <http://www.nature.com/news/2005/050221/full/050221-6.html>
>
>Nice idea but it's going to be useless unless you build it into every email
>client and web site.
>

        It sounds a lot like the SRP project which dates from as early as
1996, and they still seem to be active. In addition to the SRP protocol
information, they have drop-in, backward compatible replacements for FTP
and Telnet that provide for secure password negotiation without exposing
the shared password. Unfortunately they do not seem to have an Mac OS X
software pre-compiled - but there are a variety of links to other
implementations and source code.

<http://srp.stanford.edu/project.html>
<http://srp.stanford.edu/links.html>
<http://srp.stanford.edu/>

        It would be nice if more server software supported this type of
protocol, so that client software support would become more attractive to
developers.

        I would encourage anyone involved in either client or server
software development to add SRP support to their software, if only to gain
a slight competitive advantage by being able to add one more checkbox on
their list of features. None of the Mac OS X software that I am familiar
with (Fetch, Cyberduck, Fugu, Interarchy, transmit, RBrowser, Captain FTP,
NetFinder, SimpleFTP, etc.) supports the SRP system - it seems like someone
can get a leap on the competition.

        NetFinder and Fetch (and maybe others?) at one time had support for
OTP and s/key ("one time use" passwords) which provide similar protections.

s/key onetime passwords - RFC 2289 - here is some info from the SkeyCalc
pages - SkeyCalc does OTP calculations in Mac OS X and NEXTSTEP:
<http://www.orange-carb.org/SkeyCalc/documentation.html>

One Time Passwords In Everything ( OPIE )
<http://inner.net/opie>


--
* Johann Beda - contact link: <http://public.xdi.org/=j-beda> *
* Johann's MostlyMac Computer Consulting - <http://mmcc.beda.ca/> *

On 3/4/05 9:35 AM, "Johann Beda" <st-tidbitsbeda.ca> wrote:

> It sounds a lot like the SRP project which dates from as early as
> 1996, and they still seem to be active. In addition to the SRP protocol
> information, they have drop-in, backward compatible replacements for FTP
> and Telnet that provide for secure password negotiation without exposing
> the shared password. Unfortunately they do not seem to have an Mac OS X
> software pre-compiled - but there are a variety of links to other
> implementations and source code.
>
<snip>

FTP and Telnet and SSH can all be used with Kerberos which has solved this
problem for many, many years.

--
John C. Welch Writer/Analyst
Bynkii.com Mac and other opinions
jwelchbynkii.com

At 10:10 AM -0800 2005/03/04, John C. Welch wrote:
>On 3/4/05 9:35 AM, "Johann Beda" <st-tidbitsbeda.ca> wrote:
>> It sounds a lot like the SRP project which dates from as early as
>> 1996, and they still seem to be active. In addition to the SRP protocol
>> information, they have drop-in, backward compatible replacements for FTP
>> and Telnet that provide for secure password negotiation without exposing
>> the shared password. Unfortunately they do not seem to have an Mac OS X
>> software pre-compiled - but there are a variety of links to other
>> implementations and source code.
>
>FTP and Telnet and SSH can all be used with Kerberos which has solved this
>problem for many, many years.

        Good point. I seem to recall that Kerberos needed a key-server or
something like that to operate, while SRP is completely built into
compliant software. For the user without an IT department to maintain a
dedicated server, this might be an issue. I can't easily find an info on
this, so I cannot say for sure.

        According to the Mac FAQ at MIT, it does seem as though Eudora and
Fetch seem to have some Kerboros support and "The Telnet that ships with
Mac OS X 10.2 and later has Kerberos support. The SSH that ships with Mac
OS X 10.3 and later has Kerberos support."

        MIT has a Mac Kerboros FAQ at:

<http://web.mit.edu/macdev/KfM/Common/Documentation/faq.html>

        There is also some MIT software to supplement the Apple version of
Kerberos included with Mac OS X. It addresses the problem that "While Mac
OS X 10.2 (Jaguar) and Mac OS X 10.3 (Panther) ship with most parts of
Kerberos for Macintosh, they do not include support for CFM-based
Kerberos-using applications (such as Eudora and Fetch), and the GUI
Kerberos management application is in a hard-to-find location. "
<http://web.mit.edu/macdev/KfM/Common/Documentation/download.html>


--
* Johann Beda - contact link: <http://public.xdi.org/=j-beda> *
* Johann's MostlyMac Computer Consulting - <http://mmcc.beda.ca/> *

On 3/4/05 12:56 PM, "Johann Beda" <st-tidbitsbeda.ca> wrote:

>> FTP and Telnet and SSH can all be used with Kerberos which has solved this
>> problem for many, many years.
>
> Good point. I seem to recall that Kerberos needed a key-server or
> something like that to operate, while SRP is completely built into
> compliant software. For the user without an IT department to maintain a
> dedicated server, this might be an issue. I can't easily find an info on
> this, so I cannot say for sure.
>

It's called a KDC, and it does what any secure system needs. It keeps track
of users. Without a centralized server, you have to replicate user
permissions and authentication credentials on each machine. As well,
Kerberos is more secure than 90% of authentication schemes available, since
your password never travels across the wire. If it's not available to sniff,
it's much harder to capture and track.

But one way or the other, you have to have your credentials working on every
machine. Even with ten or so machines, that gets to be far more painful than
you might think without a centralized box.

> According to the Mac FAQ at MIT, it does seem as though Eudora and
> Fetch seem to have some Kerboros support and "The Telnet that ships with
> Mac OS X 10.2 and later has Kerberos support. The SSH that ships with Mac
> OS X 10.3 and later has Kerberos support."

It's not "some". Both of those applications are kerberized. Mail.app
supports Kerberos as well.

It's a well-tested, well-known system that is an inherent part of two of the
four major directory systems, (Active Directory and Open Directory), and is
the heart of authentication in Mac OS X 10.3 and later. (It's in Jaguar, but
much less easy to use.), and is able to be implemented on every major OS
that you'll find.

Like I said, instead of reinventing the wheel because it's Friday, maybe
more people should look at what's available *now*.

--
John C. Welch Writer/Analyst
Bynkii.com Mac and other opinions
jwelchbynkii.com

At 4:46 AM -0800 2005/03/07, John C. Welch wrote:
>It's called a KDC, and it does what any secure system needs. It keeps track
>of users. Without a centralized server, you have to replicate user
>permissions and authentication credentials on each machine. As well,
>Kerberos is more secure than 90% of authentication schemes available, since
>your password never travels across the wire. If it's not available to sniff,
>it's much harder to capture and track.

        However, Kerberos [4] cannot (at least in my reading of the system)
address the difficulties of identity/password systems that operate OUTSIDE
of your personal/group control. My local network (and maybe even remote
members of my "team") can use Kerberos to great effect, but that does not
address the issues of connecting with my bank, my cousin's photo-blog, or
the FTP repository of my paper-clip-collection fan club, since none of
those are likely to be able to effectively interact with my Kerboros key
server. Even more difficult is the problem of my
clueless-relative/friend/assiciate connecting to similar services. Wider
adoption of authentication methods such as SRP [1], OTP [2], or the method
mentioned in "Nature" [3] that opened this discussion, would be of benefit
to all.

        As I have looked into it over the past few days, SRP seems to be
the way things are going - both SSH and Kerberos seem to be moving towards
using SRP or similar for at least part of their authentication dance. It
looks like there are a number of SRP patches [5] that include SRP in
OpenSSH, so perhaps that will lead to easier adoption. However it may be
that there are legal issues with intellectual property involved with SRP.
[7]

        (LaTeX [6] can take care of keeping my footnotes in order - why
can't Eudora do the same thing? I am too lazy to re-number them each time I
want to add one out of order, thus the first reference above is to #4
rather than #1...)


[That's a rhetorical question with an obvious answer, so let's leave it be. :-) -Adam]


[1]<http://www.ussrback.com/crypto/srp/telnet.html>
[2]<http://www.orange-carb.org/SkeyCalc/documentation.html>
[3]<http://www.nature.com/news/2005/050221/full/050221-6.html>
[4]<http://web.mit.edu/macdev/KfM/Common/Documentation/faq.html>
[5]<http://www.google.com/search?&q=OpenSSH+SRP>
[6]<http://www.esm.psu.edu/mac-tex/>
[7]<http://mailman.mit.edu/pipermail/krbdev/2004-January/002253.html>


--
* Johann Beda - contact link: <http://public.xdi.org/=j-beda> *
* Johann's MostlyMac Computer Consulting - <http://mmcc.beda.ca/> *

On 3/7/05 9:15 AM, "Johann Beda" <st-tidbitsbeda.ca> wrote:

>> It's called a KDC, and it does what any secure system needs. It keeps track
>> of users. Without a centralized server, you have to replicate user
>> permissions and authentication credentials on each machine. As well,
>> Kerberos is more secure than 90% of authentication schemes available, since
>> your password never travels across the wire. If it's not available to sniff,
>> it's much harder to capture and track.
>
> However, Kerberos [4] cannot (at least in my reading of the system)
> address the difficulties of identity/password systems that operate OUTSIDE
> of your personal/group control. My local network (and maybe even remote
> members of my "team") can use Kerberos to great effect, but that does not
> address the issues of connecting with my bank, my cousin's photo-blog, or
> the FTP repository of my paper-clip-collection fan club, since none of
> those are likely to be able to effectively interact with my Kerboros key
> server. Even more difficult is the problem of my
> clueless-relative/friend/assiciate connecting to similar services. Wider
> adoption of authentication methods such as SRP [1], OTP [2], or the method
> mentioned in "Nature" [3] that opened this discussion, would be of benefit
> to all.

SSL and a host of other existing methods deal with this right now. I've yet
to see any of these new methods that were needed because they were the only
way to solve this problem. Rather people just want a new toy every couple
years.

--
John C. Welch Writer/Analyst
Bynkii.com Mac and other opinions
jwelchbynkii.com

At 3:09 PM -0800 2005/03/07, John C. Welch wrote:
>SSL and a host of other existing methods deal with this right now. I've yet
>to see any of these new methods that were needed because they were the only
>way to solve this problem. Rather people just want a new toy every couple
>years.

        To be fair, SRP systems are not really "new", in that they have
been in existing products for almost a decade (1997?)... but it is
certainly true that people have a tendency to look for something "new"
rather than using already existing products, and this is often not an
optimal method.

        A difficulty with SSL is that it requires an external certification
from one of the approved "authorities", which costs in both setup time and
real money.

        I am starting to sound like an evangelist for SRP, which was not
really my goal when this first started. In my reading, SRP currently is the
best system to be used in any password exchange, and can be used to enhance
the security of other systems (Kerebos and ssh for example), with little
downside beyond the gigantic difficulty of actually getting more widespread
adoption...

        More discussions of passwords and methods to address their limitations:
<http://www.spirit.com/Network/net0101.html>
<http://www-cs-students.stanford.edu/~tjw/srp/analysis.html>

--
* Johann Beda - contact link: <http://public.xdi.org/=j-beda> *
* Johann's MostlyMac Computer Consulting - <http://mmcc.beda.ca/> *

On 3/8/05 9:24 AM, "Johann Beda" <st-tidbitsbeda.ca> wrote:

> A difficulty with SSL is that it requires an external certification
> from one of the approved "authorities", which costs in both setup time and
> real money.

That is a misconception, but one that Verisign and Thawte encourage heavily.
Anyone can create a self-signed site cert, indeed it's trivial. The only
thing that paying money does is avoid the "I don't already know who this
cert belongs to" messages. Entities like MIT are self-signed and have been
for many many moons.

But there's no "requirement" that you write checks to people for
certificates

--
John C. Welch Writer/Analyst
Bynkii.com Mac and other opinions
jwelchbynkii.com

Quoting "John C. Welch" <jwelchbynkii.com>:

> On 3/8/05 9:24 AM, "Johann Beda" <st-tidbitsbeda.ca> wrote:
>
>> A difficulty with SSL is that it requires an external certification
>> from one of the approved "authorities", which costs in both setup time and
>> real money.
>
> That is a misconception, but one that Verisign and Thawte encourage heavily.
> Anyone can create a self-signed site cert, indeed it's trivial. The only
> thing that paying money does is avoid the "I don't already know who this
> cert belongs to" messages. Entities like MIT are self-signed and have been
> for many many moons.
>
> But there's no "requirement" that you write checks to people for
> certificates

I use self-signed certs for many of my websites and my smtp server and my IMAP
server, including the one with instructions on creating a self-signed cert:

<https://portal.vanhaaren.net/wiki/index.php/OpenSSL>

But one of the advantages of an authenticated cert is it can prevent certain
attacks.

For example, if I create a self-signed cert for citibank.com, then poison your
DNS server so references to citibank.com com to me instead of the real
citibank.com, then when you connect to my server instead of citibank's, you
should get a big warning that the certificate isn't valid. Of course if you
accept it....

Kevin