Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsWhite Papers
Discussion GroupsFirst AidDatabasesJavaBeansGUIJava 3DVirtual MachineCORBASecurityToolsGeneral
Java DirectoryOpen Source ProjectsSample Book ChaptersUser GroupsWeb Resources
Related Topics
Databases.NETMore Topics ...

Java Forum / General / February 2006

Tip: Looking for answers? Try searching our database.

password questions

Thread view: 
Roedy Green - 04 Feb 2006 03:59 GMT
I would like to update the passwords entry in the java glossary.

I have handled passwords myself at the socket level using digest
comparisons and date salting to prevent snoops from reusing them.

I have used the magic AccessController that lets you pretend to be a
browser and it transparently handles http userid/passwords.

I have passed passwords through to SQL engines.

What I am puzzled about is how passwords look when you write a
Servlet.  I presume there are classes that handle login details or
features of the womb that handle it. What are they?

I am only after a broad brush here.

How does the server remember that a client is logged in? Does the
browser send a cookie each time?  Is some sort of login dance done on
ever transaction?  is the userid/pasword embedded in the URL every
time?
Signature

Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.

Roedy Green - 04 Feb 2006 14:38 GMT
On Sat, 04 Feb 2006 03:59:43 GMT, Roedy Green
<my_email_is_posted_on_my_website@munged.invalid> wrote, quoted or
indirectly quoted someone who said :

>I would like to update the passwords entry in the java glossary.
I have done some digging and have updated
http://mindprod.com/jgloss/password.html
http://mindprod.com/jgloss/authentication.html

One thing I found out is the server announces the password scheme it
wants to use e.g. basic or digest then the Authenticator in the
calling Applet transparently takes it from there. I have not found out
if Authenticator understands any other schemes besides basic and
digest.

I have also not yet found out what I have to do on the Server end.
Signature

Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.

Raymond DeCampo - 04 Feb 2006 21:48 GMT
> On Sat, 04 Feb 2006 03:59:43 GMT, Roedy Green
> <my_email_is_posted_on_my_website@munged.invalid> wrote, quoted or
[quoted text clipped - 13 lines]
>
> I have also not yet found out what I have to do on the Server end.

This is usually specific to each application server.  Most will provide
a rudimentary, unsuitable for production flat file scheme.  The better
ones will always provide a means of configuring a database for the
users.  Almost all allow you to extend a class to provide a custom source.

Also, there is configuration to be done in the web.xml file to configure
the login process.

The best approach (for expandability) is to incorporate a third party
SSO (single sign-on) (some AS come with this).  This allows you to add
new applications and share the log in across them with a minimum of
effort.  Also, they typically plug into an existing LDAP taking user and
password management out of the apps hands.  This allows corporations to
take advantage of existing LDAP data when deploying applications.

HTH,
Ray

Signature

This signature intentionally left blank.

Juha Laiho - 05 Feb 2006 21:55 GMT
Roedy Green <my_email_is_posted_on_my_website@munged.invalid> said:
>I would like to update the passwords entry in the java glossary.
...
>What I am puzzled about is how passwords look when you write a
>Servlet.

Often, you don't see password handling in servlets.

>I presume there are classes that handle login details or
>features of the womb that handle it. What are they?

I hope this is of any help:
http://groups.google.com/group/comp.infosystems.www.servers.unix/msg/f1505128136
cb500?dmode=source


>How does the server remember that a client is logged in? Does the
>browser send a cookie each time?  Is some sort of login dance done on
>ever transaction?  is the userid/pasword embedded in the URL every
>time?

A session id (generated by the container) is used. It'll be passed
in a cookie, or within the request URL.

For more information, see the Tomcat documentation on security as well
as the security-related chapters of Java Servlet Specification.
Signature

Wolf  a.k.a.  Juha Laiho     Espoo, Finland
(GC 3.0) GIT d- s+: a C++ ULSH++++$ P++@ L+++ E- W+$@ N++ !K w !O !M V
        PS(+) PE Y+ PGP(+) t- 5 !X R !tv b+ !DI D G e+ h---- r+++ y++++
"...cancel my subscription to the resurrection!" (Jim Morrison)

Oliver Wong - 08 Feb 2006 17:54 GMT
> How does the server remember that a client is logged in? Does the
> browser send a cookie each time?  Is some sort of login dance done on
> ever transaction?  is the userid/pasword embedded in the URL every
> time?

   What's usually done in the PHP world is that the first time a browser
goes to a site, it has no cookie, and says so when asked for one. So the
server then asks for username and password, which the browser provides. The
server then gives a cookie which contains a random number between 1 and a
gazillion. The server stores all relevant information (e.g. username and
password) in a file whose filename is the same as the number given to the
browser. Let's say, for example, the server gave the browser the number "42"
for the cookie.

   The next request, the browser ask for a page, and gives the cookie with
the number "42". The server then looks a its files, finds the one labelled
"42", and now has the username and password and any other useful information
locally, all without the browser re-sending it.

   Periodically, the server may delete all the files which are older than 5
minutes, for example.

   A cracker makes a request, trying to masquerade as the authenticated
user. The server will ask for the number in the cookie. Since the cookie
number is any random number between 1 and a gazillion, and there are only,
say, 1 million active users at a time, the chances of the cracker guessing a
number that is currently in use is 1 million divided by 1 gazillion.

   Generally, it's easier for the cracker just to say he doesn't have a
cookie, and try to guess the passwords, rather than guessing the cookie
number, because people tend to choose insecure passwords.

   - Oliver


Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2009 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.