[2932] in WWW Security List Archive
Re: Passwords encrypted with SSL??
daemon@ATHENA.MIT.EDU (John Haggard)
Thu Sep 12 13:58:22 1996
Date: Thu, 12 Sep 1996 10:36:18 -0500
From: John Haggard <jch@vdsi.com>
To: rob schuldt <rschuld@uhc.com>
CC: www-security@ns2.rutgers.edu
Errors-To: owner-www-security@ns2.rutgers.edu
rob schuldt wrote:
>
> The basic authentication mechanism of HTTP protocol is fine except that it sends the password over the wire in the clear and would make it
> vulnerable for sniffers. Hence I was just wondering if you know of any
> initiatives/product that allows s/key authentication access for web
> pages.. I've seen implementations of JAVA S/key calculators around the
> web and was just curious to find out if anyone has integrated it into
> a S/KEY authentication mechanism for web pages?
>
> Charles Lai
> ------------------------------
>
> Someone correct me if I'm wrong here, If you have an SSL connection between
> the server and the client browser. When the client attempts to access protected
> documents on your site, the server will prompt for the username and password
> to authenticate the user, the user then fills in this info and sends it across
> the wire encrypted by SSL. So the password is (relatively) safe going across
> the wire. Someone Please tell me if I'm wrong on this one.
> Rob Schuldt humble intern
>
>
Rob,
You are indeed correct in that the userid and password are sent
encrypted and hence
the threat of a sniffer obtaining the password is minimimal at best.
This however isn't
the problem. The problem is that if you are using a static password that
you remember
you are at risk for attack. I won't go into the age old methods for
getting your password,
but I can't help but point out that if you rely on SSL for securing
sessions
for more than one web server, you probably will use the same password.
Imagine power users
signing on to dozens of web servers. Discovering your password is just a
matter of time.
It should be interesting when companies in the same market, such as
brokerage houses, discover
that their web users are savy and register themselves to multiple firms
to compare services. When
they couple that discovery with the discovery that users tend to reuse
passwords and ids so they
can remember them, then they will then realize that they have the userid
and passwords for
accounts of their competitors and vice versa. Imagine what is now
possible.
In some cases firms in the same market niche are really asking for it. I
won't name the banks, but
several of them take assigning the userids into their own hands so users
can't select them. That
is not a bad idea except they all use the same naming convention - your
social security number.
Now all I have to do is put up a free internet banking tips web site and
simply ask users who
use my services to register themselves. Just tell me your name and
select a password, I'll do the
rest.
Now having said all of this, you've probably guessed that I'm a vendor
with a solution and you
are right, however this isn't a sales pitch so I'll leave our products
out of this discussion.
You should know that there are a variety of one time password solutions
on the market that
address a number of environments with the web servers being but one.
Searching for token devices
is easy to do so I'll leave that to you.
Hope this helps.
John Haggard
President
VASCO Data Security, Inc.
http://www.vdsi.com
