aspose file tools*
The moose likes Servlets and the fly likes login/password question Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Servlets
Bookmark "login/password question" Watch "login/password question" New topic
Author

login/password question

Artemesia Lakener
Ranch Hand

Joined: Jun 21, 2005
Posts: 162
I have two basic login/password questions --

1. In J2EE, what's the most common implementation technique for login/pwd ? I read some servlet books, it says that you can use "FORM" or "BASIC" schema and create some user/pwd on web container server. But that doesn't sound like commercial style. How does yahoo handle it ? It can't use this mechanism because it allows users to create by themselves.

Basically, are those login/pwd stored in a database table or what ?

2. in my applications, we see those "after 3 times try, you will be blocked" scenario. wondering how that is implemented ?
Matt Gatten
Greenhorn

Joined: Oct 29, 2005
Posts: 7
More than likely they are using a database and sessions. In large workgroups like a major corporation headquarters, they'll have an 'active directory' to provide login authentication for logging onto the network as well as a whole bunch of 3rd party and homegrown apps. That's what we do where I work. Over 5000 employees across two buildings.
Anupam Sinha
Ranch Hand

Joined: Apr 13, 2003
Posts: 1088
I guess yahoo stores the username and the encrypted password in the database only.

Here's my approach.

1. Create a user.
2. Assign a password. User or system may assign one.
3. Encrypt the password and store the same on the DB. I have used MD5 for the same. MD5 digest encrypts the password into a one way hash. So that you can not decrypt back it into the orignal password.
4. On the login page you can add a javascript to encrypt the password and send the same back to the server or you can send the orignal password to the server and the server can encrypt. But the former one is what I would prefer. As I guess its more secure and would put the encyption load on the client rather than the server.
5. The server would then compare the hashed password recieved from the client and the one in the DB if both are same then grant access otherwise deny access and in the Session save an attribute about the incorrect try.
6. Increment the incorrect try each and every time there's a wrong password.
7. When the session incorrect value reaches 3 you can block the account.

The session thing would work only in case the user uses the same browser instance. If you need to block the account no matter what then you need save the incorrect try no. in the DB. In case you are saving the same in the DB remember to reset when a correct password is supplied.

You can also use salts to make the password authentication more strong.
Gerardo Tasistro
Ranch Hand

Joined: Feb 08, 2005
Posts: 362
Originally posted by Artemesia Lakener:
I have two basic login/password questions --

1. In J2EE, what's the most common implementation technique for login/pwd ? I read some servlet books, it says that you can use "FORM" or "BASIC" schema and create some user/pwd on web container server. But that doesn't sound like commercial style. How does yahoo handle it ? It can't use this mechanism because it allows users to create by themselves.



I find nothing unprofessional about that form. Ok basic is a bit too basic, but FORM can be made to look trully pro. FORM also has the feature of working as a filter and works across all the application. Which means you don't have to worry about login checks before each page.

It doesn't exclude that users can create themselves. FORM authentication works from a Realm. That ream can be pointed to a text file with passwords which is the most basic setup. But it can also be pointed to a JDBC connection, a JNDI resource and I believe a LDAP resource too (thus making active directory features available).

To work this way you can setup FORM authentication on your application (notice how Yahoo always sends you to the same login page no matter what point of entry use use). Now if the user doesn't have a login you can redirect hime to another application. A smaller one that just deals with the signup and inserts the data into a database. That database is later used for the Realm of the original application.
Dilpreet Singh
Greenhorn

Joined: Jan 21, 2004
Posts: 6
autheticate using BASIC approach is not secure. Batter to use Form or Digest based authentication. Rest of the logic for blocking a user if consective three attemp to login failed is quite easy take a static counter variable and increase if login failed if it goes more than 2 block the page for that user. next time(4th time) when request comes don not check the password display the blocked page. The password will be definitly be stored in encrypted form either in Database or above mentioned way.


DIL-A-NADAN
Roger Chung-Wee
Ranch Hand

Joined: Sep 29, 2002
Posts: 1683
FORM-based authentication is as insecure as Basic authentication as the username/password are not encrypted.

Digest authetication is more secure as an MD5 digest of the password is sent in. But the problems with this authentication are lack of browser support (I think it's only IE5 and later) and lack of servlet container support as the servlet spec does not mandate it.

HTTPS (HTTP over SSL) client authentication is the most secure as all the data is transmitted in the encrypted form using public-key cryptography. The big disadvantage is complexity: We use this form of authentication between remote Java clients and WebLogic Server, and it was a pain to set up.


SCJP 1.4, SCWCD 1.3, SCBCD 1.3
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
With forms, a second vote for SSL. Don't send the password in plain text from the form to the server. And if you think you have invented a clever new encryption algorithm in JavaScript before you send ... you haven't. It might be good enough to keep out a True Gentleman who wouldn't think of trying to hack another's password, but not a pro.


A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Gerardo Tasistro
Ranch Hand

Joined: Feb 08, 2005
Posts: 362
Originally posted by Roger Chung-Wee:
FORM-based authentication is as insecure as Basic authentication as the username/password are not encrypted.


Really? How about if you post over HTTPS?

Originally posted by Roger Chung-Wee:


Digest authetication is more secure as an MD5 digest of the password is sent in. But the problems with this authentication are lack of browser support (I think it's only IE5 and later) and lack of servlet container support as the servlet spec does not mandate it.


Really? So if I post the digest over http I'm safe? Not really! I just snatch your MD5 digest and send it myself. Since your app compares MD5 from client with MD5 in dbase I already have your access!!! Plus now all the MD5s in your database are good as password access codes by anyone.
Anupam Sinha
Ranch Hand

Joined: Apr 13, 2003
Posts: 1088
Originally posted by Gerardo Tasistro:


Really? So if I post the digest over http I'm safe? Not really! I just snatch your MD5 digest and send it myself. Since your app compares MD5 from client with MD5 in dbase I already have your access!!! Plus now all the MD5s in your database are good as password access codes by anyone.



Yeah for that reason you should use salts.

Basically this is how it works.

1. Server when displays the login page also sends in a random number/string. Which is tied to the session.
2. The browser encrypts the password to MD5 and then again encrypts the password with the random number/String and sends the resultant to the server.
3. The server encrypts the encrypted password with the random nymber/String it sent in step 1.
4. The resultant is compared with the request recieved from the server. If both of them are same you allow access.
Gerardo Tasistro
Ranch Hand

Joined: Feb 08, 2005
Posts: 362
Without SSL you're lost. The salt model without SSL still offers no security because I know the MD5 and the salt being used. If I get a hold of your MD5 database I can crack open any account instantly.
[ February 06, 2006: Message edited by: Gerardo Tasistro ]
Anupam Sinha
Ranch Hand

Joined: Apr 13, 2003
Posts: 1088
Originally posted by Gerardo Tasistro:
Without SSL you're lost. The salt model without SSL still offers no security because I know the MD5 and the salt being used. If I get a hold of your MD5 database I can crack open any account instantly.

[ February 06, 2006: Message edited by: Gerardo Tasistro ]


Couldn't get you. When the request would be sent the maximum info you can snoop out is

1. Username
2. Random Number/String
3. Resultant password which is MD5 of username and then the whole MD5'ed with the random number.

How would you get hold of the MD5 database?
Gerardo Tasistro
Ranch Hand

Joined: Feb 08, 2005
Posts: 362
Originally posted by Anupam Sinha:


How would you get hold of the MD5 database?


Sloppy, dishonest or disgruntled sys admin could be a good start. A database exploit actually being exploited is another mean.

Your list also lacks three things

- the server IP
- the session cookie
- all the other information that will be transfered

Those things can be snooped.

First is the server IP. I know what IP you connect to. Without an SSL certificate do I really know I'm connected to my server? I could very well put an entry in your PCs host file and clone your login page.

Secondly, the server also sends the session information back to the browser. If I can snatch that then I can clone your session.

Finally all this login security means nothing if all further info sent to and from the server can be snooped too.
Anupam Sinha
Ranch Hand

Joined: Apr 13, 2003
Posts: 1088
Yeah I see the point. But how would a SSL protect against an attack on the DB. Secondly if someone can access and modify the host file then someone can very well set up a keylogger as well. Though yeah the cloning thing is a potenial security risk.
[ February 06, 2006: Message edited by: Anupam Sinha ]
Gerardo Tasistro
Ranch Hand

Joined: Feb 08, 2005
Posts: 362
Originally posted by Anupam Sinha:
But how would a SSL protect against an attack on the DB.


It wouldn't. The issue with the DB is that for all practical purposes the passwords in it are "plain text". Since the server challenges the incoming string (md5-ved password+salt) with the salted string in the DB (which is the smae md5-ved password).


Originally posted by Anupam Sinha:


Secondly if someone can access and modify the host file then someone can very well set up a keylogger as well.

[ February 06, 2006: Message edited by: Anupam Sinha ]


Yes, but given that a lot of users run their Windows machines as admin and a host file change will not show up as a running process (which a key logger will) I find it a lot harder to find. Only now is MS Anti-spyware beta checking for host file changes and few other spyware removers list it as a top feature.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: login/password question