Domenico Viggiani <viggiani @
hotmail .
com> queried the List:
|>What is 'the best way' to authenticate an user on a Web Server in order
|>to allow using of *distributed* resources like databases, reports, etc.?
|>
|>Transmission of passwords in clear-text over the network is not allowed.
The value of the resources you are protecting; the size of your
user population; whether your users will be regulars (employees, clients,
customers) or transients; whether your users will be US-based or from
elsewhere in the world; and what other Internet services are being provided
from this site; and most of all, what your local resources for web savvy
and programming might be -- all this factors into any meaningful reply to
your query.
Are you limited to admin-friendly COTS (commercial off the shelf)
products or can you, so to speak, roll your own? "Best" is a distinctly
relative term -- and no comment on security is meaningful out of a specific
context.
As Frank Willoughby warned, encrypted passwords are usually not
enough when the user's http session can be highjacked post-authentication.
And if full crypto is a given, I lean toward Craig Wright's solution: X.509
v.3 certificates under SSL. For most web apps today, SSL (RSA/RC4) is a
no-brainer.
SSL is a low-level encryption scheme used to encrypt transactions
in higher-level protocols like as HTTP, NNTP and FTP. The SSL protocol
includes provisions for server authentication (verifying the server's
identity to the client), encryption of data in transit -- and optional
client authentication (verifying the client's identity to the server based
upon a digital certificate.) This digital certificate documents and
certifies to a possessive link between the user's public-key pair and a
specific human or corporate entity.
The trustworthiness or appropriateness of a digital cert (and the
binding it documents) for your application or any commercial app is gaged
by who issued it and under what explicit conditions and assurances it was
issued. You could issue your own user certificates from a local
Certificate Authority (CA); or you could buy certs from one of the big
commercial CAs like GTE or Verisign; or you could use some sort of "virtual
CA" like SDTI's Onsite, which outsources X509 certificate generation to
Verisign but administers them locally.
Most web servers and most browsers now offer SSL. Netscape and
Microsoft both also offer S/MIME e-mail encryption in their browsers, which
relies upon the same PK pair and a digital cert for its confidentiality,
authentication, and integrity functions. (If you are not a US-based site
serving users based in the US, this discussion gets much more complicated.
The US government probably won't let US vendors supply you with strong
crypto. <sigh> Buy elsewhere.)
PKI and X509 certs (with strong encryption, and digital-signature
based authentication) is where we are all going. Whether you want to be a
pioneer is still a valid question, however. If you are not ready to buy or
issue digital certs for your users, you may still use SSL just for a
secure pipeline (although there are wide variety of alternative crypto
options available at several OSI layers.) Lacking PKI certs, you will need
a more tradition mechanism for user authentication.
Within the SSL pipe, your user authentication options range from
the simple passwords; to HTTP Digest Authentication; up thru encrypted
cookies; and even custom Java applets dropped to the user. Then there are
the various out-of-band I&A techniques which give the user either a
physical token to generate a one-time password (time-synch or
challenge/response), or software (token-emulators or D-H "strong-password"
systems) which can also generate OTPs.
Two-factor authentication ("something you have" plus "something you
know") is the generally accepted standard for "strong" user authentication.
Rob Davis <rdavis @
lucentncg .
com> steered you toward commercial
off-the-shelf devices:
>Use https (secure http) to encrypt information transmitted over the
>Internet (increases overhead though...). This is a start.
Terisa's Secure HTTP is an extension of HTTP. It's another
webserver-based crypto option, but operates at a level above SSL, focused
on the HTML document. (SHTTP is something like an envelope; while SSL is
more like a locked mail truck in transit.) SHTTP is considerably more
restrictive in terms which web server you can use, but it has other
strengths. SHTTP relies upon a PKC exchange -- but does not depend on the
browser's public key pair or a registered digital certificate for user
authentication. For that, you'll need another mechanism.
>Next decide
>what method to use to authenticate people - strong or weak.
>
>Weak authentication uses reusable passwords. Strong authentication uses
>one-time passwords. Which type depends on how much many you want to
>spend, which in turns depends on the nature of the information you are
>sharing.
Strong and weak are the extremes. There is now a healthy (albiet
confusing) spectrum of choices in between, with various levels of security
and different price/performance models.
>1) A lot of money (~60 bucks person, plus training, plus a server, plus
>administrative costs) will buy you Security Dynamics SecurID. An
>excellent system using strong authentication, but works on a limited
>number of web servers (only IIS and maybe Netscape).
ACE/SecurID systems are popular because buyers find the SecurIDs
easy to use; the ACE/Server scalable -- and because corporate buyers like
the vendor's size, stability, and active development effort for a
mission-critical function. I like SDTI's WebID kit. It not only requires
SecurID authentication before it allows access selected objects on a web
server (directories, pages, parts of pages,) but it can also _require_ a
user to make an SSL connection before it allows access to the whole or
restricted portions of a website. (Fair Warning: I'm not without prejudice
here. I've been a regular consultant to SDTI for years.)
SDTI today also offer its own spectrum of I&A options, at different
prices, with different levels of assurance -- software SoftIDs at one end;
SecurID Smartcards at the other -- as well as their traditional line of
SecurID two-factor tokens. This is all relatively new. The ACE/Server no
longer requires all users to have SecurIDs. Some users may be using static
passwords; some SoftIDs; some SecurID tokens; some smartcards. This gives
the network admin or webmaster more flexibility and more control over both
budget and security policy.
(SDTI -- which now owns both RSA Data Security and Dynasoft -- has
also promised to evolve its authentication server over the next year to
support PKI key and cert management. Their Onsite "virtual CA" is the
first step on that road.)
>2) Weak authentication using username/password combination - very easy
>to implement!
Yup. Digest Authentication (see the rfc) is also worth exploring,
although I think it's only available on NCSA or maybe Apache servers.
>3) Strong authentication using something like S-Key. I haven't
>implemented this, but I don't think it would be that hard.
Probably not. And the cost of the freeware product will never be
underbid. But no one ever said S/key (aka OPIE or OTP) is particularly
easy on the users -- and the web's slick graphic culture is not one in
which users easily accept complicated administrative procedures as off-line
housekeeping chores. Other S/key issues (admin, security, training) are
better addressed by others.
Just to state it clearly: there are now a great number of sometimes
complementary options available for mix and match to meet a particular
site's needs for either encryption or user authentication. As Nick
Simichich wrote: it's impossible to know if what Mr. Viggiani needs is a
bicyle or a Porsche. Above is just a broad sketch of options and opinions
(and I didn't even touch on VPNs and IPsec or a variety of emerging
options.)
Again, Courtney's Law: No security solution can be meaningfully
discussed except in the context of a particular application; a specific
environment; a particular need. Those app-specific discussions are what
keeps bread on the table for a good number of the battle-scarred infosec
consultants who lurk on this List.
Suerte,
_Vin
Vin McLellan + The Privacy Guild + <vin @
shore .
net>
53 Nichols St., Chelsea, MA 02150 USA <617> 884-5548
-- <@><@> --
References:
|
|
