Developer Forum

For a personal project, I'm creating a webapp that requires users to log
in. I'm using Spring Framework 2.5 as the application framework,
Hibernate for persistence, and Resin 3 as the application container.

Security isn't yet that much of a concern, but I'd like to make sure I'm
headed in the right direction if this ever gets off the ground.

So, I have a User class, which has username. I could store password in
this class too, but I was thinking about whether I should encrypt it/how
to encrypt it, or whether I should externalize the authentication
altogether.

I don't know much about secure authentication, so any suggestions on
libraries or best practices would be appreciated. Oh, and whatever
approach I use, I need to support self-service account
creation/maintenance.

Thanks,
Daniel.
--
Daniel Pitts' Tech Blog: < http://www.yqcomputer.com/ ;

I think you should consider container managed security.

http://www.yqcomputer.com/ #JdbcAuthenticator
http://www.yqcomputer.com/ #custom%20authentication

Arne

I've used acegi (now spring security) successfully

http://www.yqcomputer.com/

Regards

Marcelo Morales

On Jul 7, 2:46m, Daniel Pitts

Thanks,
It looks a little heavyweight for me. My project goal is for something
more like a high-traffic social network site, so I really don't need so
much.

--
Daniel Pitts' Tech Blog: < http://www.yqcomputer.com/ ;

I'm writing something comparable using JavaServer Faces, a Derby
database and Tomcat respectively.
Let me tell you what I have done so that either you can treat it as
useful advice or someone can tell me why it is insecure.

The user logs in with a user name and password and the password is put
through an MD5 hash then encoded into base64. The resulting string is
compared against the string stored in the database when the user first
registered. The actual password is not stored in the database and is
only in the computer's memory while it is being entered and encoded.
The MD5 hash is included in java.security and the base64 encoding is
from Mikael Grev's MiGBase64
< http://www.yqcomputer.com/ ;.

In article < XXXX@XXXXX.COM >,



I'm no security expert, but the people who are usually tell me, "Here
are some known security implications of what you're planning."


Presuming the name and password arrive unmolested, one goal is to
prevent unauthorized use of the passwords by someone who can obtain a
copy of the data. Using MD5 alone in this context has known limitations:

< http://www.yqcomputer.com/ ;

You can mitigate this effect somewhat by using a suitably chosen salt:

< http://www.yqcomputer.com/ %28cryptography%29>

I'm not aware of any security benefit to base64 encoding.

--
John B. Matthews
trashgod at gmail dot com
home dot woh dot rr dot com slash jbmatthews

A different salt for each user + SHA256 hashing should be pretty good.

Arne

In article <48755396$0$90262$ XXXX@XXXXX.COM >,





If I may add, iterating the hash function is also recommended: "A
minimum of 1000 operations is recommended in RSA PKCS5 standard." Here's
a recently updated article that discusses the trade-offs:

< http://www.yqcomputer.com/ ;

Every time I look, it seems, the minima go up!

--
John B. Matthews
trashgod at gmail dot com
home dot woh dot rr dot com slash jbmatthews

I just think it is a sub optimal approach. The reason is
that the work required is linear with the number of iterations.
Salt length and hash length has much better characteristics.

Arne

In article <487a8064$0$90275$ XXXX@XXXXX.COM >,




[...]

I don't understand what is sub-optimal. Your point about salt and key
length is cogent; iterating the hash function is an added measure. As
the article suggests, it's a trade-off: For the attacker, the extra work
must be done for reach password; for the user, the effort delays each
authentication only slightly.

--
John B. Matthews
trashgod at gmail dot com
home dot woh dot rr dot com slash jbmatthews