Re: storing passwords
On Fri, 2002-11-22 at 01:05, RXZ JLo wrote: I want to introduce the concept of users in my web application. I want to know how to store passwords securily on the server side. How do people deal with passwords usually? Any documentation/guides on this would also do. It all depends on what kind of access you are trying to protect. If this is a low-security thing, it might be useful to be able to mail users their passwords if they forget them. In that case you would store them in plain text. If it's higher security, you might store them as a SHA1 hash, so that if they lose a password, they have to have a new one generated. If it's even higher security, maybe you shouldn't be using passwords at all. As in ALL areas related to security, how you do it depends on the value of what you are trying to protect. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: storing passwords
Normally you generate a hash of the password and store that. Thus the actual password is not stored, then when a user logs in you generate a hash and compare the two. -Original Message- From: RXZ JLo [mailto:[EMAIL PROTECTED]] Sent: 22 November 2002 11:06 To: [EMAIL PROTECTED] Subject: storing passwords I want to introduce the concept of users in my web application. I want to know how to store passwords securily on the server side. How do people deal with passwords usually? Any documentation/guides on this would also do. thanks rf. __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: storing passwords
You could just store them in your database.
All you need to do is encrypt them using a simple encryption method
public static byte[] encrypt(String x) throws Exception
{
java.security.MessageDigest d =null;
d = java.security.MessageDigest.getInstance(SHA-1);
d.reset();
d.update(x.getBytes());
return d.digest();
}
[EMAIL PROTECTED] 11/22/02 09:05am
I want to introduce the concept of users in my web
application. I want to know how to store passwords
securily on the server side. How do people deal with
passwords usually? Any documentation/guides on this
would also do.
thanks
rf.
__
Do you Yahoo!?
Yahoo! Mail Plus Powerful. Received: from APC_DOM-MTA by
AVCMAIL.appleyard-contracts.co.uk
Affordable. Sign up now.
http://mailplus.yahoo.com
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
The information contained in this communication is intended solely for the use of the
individual or entity to whom it is addressed and others authorized to receive it. It
may contain confidential or legally privileged information. If you are not the
intended recipient you are hereby notified that any disclosure, copying, distribution
or taking any action in reliance on the contents of this information is strictly
prohibited and may be unlawful. If you received this communication in error, please
notify us immediately by responding to this email and then delete it from your system.
Appleyard Finance Holdings Ltd or its subsidiaries are neither liable for the proper
and complete transmission of the information contained in this communication nor for
any delay in its receipt.
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: storing passwords
Thanks to all of you for the responses. apart from this password I will be storing some other things too(they too are passwords but for some other things in the application). I cant use one way hash as I cant use them further. what mechanism should I follow in this case? Also, for the login case should I bother about encryption in the login form? Can I just use input type=password/ and rely on the brower? What are the pros and cons for this? If you see yahoo login, they generate md5 using javascript on the client side itself - is this really necessary? Thanks again. rf __ Do you Yahoo!? Yahoo! Mail Plus Powerful. Affordable. Sign up now. http://mailplus.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: storing passwords
It's all qualified. As the first response to your question said, it completely depends on what you want to do and how secure you want things to be. If you just use the input type=password then your password will be sent over the web in plain text. That is only of any use for people looking over the user's shoulder, but if that's all you think you need then go ahead. I would put it something like this: Weak: input type=password only. = no encryption. This should always be done anyway. MD5 (or other 1-way encryption) at server = plain text while in transit to server but useless to hacker of your system. MD5 in JavaScript = encrypted while being sent but the same hash can be sent by others so not perfect. SSL = Fully Encrypted connection between browser and server. Strong: Hopefully others will suggest other methods and add to my scale. Andoni. - Original Message - From: RXZ JLo [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Sent: Friday, November 22, 2002 9:50 AM Subject: Re: storing passwords Thanks to all of you for the responses. apart from this password I will be storing some other things too(they too are passwords but for some other things in the application). I cant use one way hash as I cant use them further. what mechanism should I follow in this case? Also, for the login case should I bother about encryption in the login form? Can I just use input type=password/ and rely on the brower? What are the pros and cons for this? If you see yahoo login, they generate md5 using javascript on the client side itself - is this really necessary? Thanks again. rf __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: storing passwords
On Fri, 2002-11-22 at 02:09, Andoni wrote: It's all qualified. As the first response to your question said, it completely depends on what you want to do and how secure you want things to be. If you just use the input type=password then your password will be sent over the web in plain text. That is only of any use for people looking over the user's shoulder, but if that's all you think you need then go ahead. I would put it something like this: Weak: input type=password only. = no encryption. This should always be done anyway. MD5 (or other 1-way encryption) at server = plain text while in transit to server but useless to hacker of your system. MD5 in JavaScript = encrypted while being sent but the same hash can be sent by others so not perfect. SSL = Fully Encrypted connection between browser and server. Strong: Hopefully others will suggest other methods and add to my scale. There are three possible factors to authentications: Something you know (a password), something you have (a token) and something you are (biometic). In theory, the strongest is to use all three factors. Passwords sent over the net (even with ssl) are the weakest. People pick weak passwords, passwords can be snooped, etc. Biometrics look cool but in practice they are not nearly as effective as they look like in the movies. Something you have, a token, is very effective if used properly. There are quite a few tokens out there which simply have a DES key inside. The user activates the token with a PIN. The server sends a challenge string. The user types in the challenge, and the card encrypts it, and the user types that in to the web form and is authenticated. Other tokens actually do a full RSA process. It's easy to do, cheap, and vastly more secure than passwords. Of course, every year billions of dollars are transacted with credit cards, which have basically no real security mechanisms, but they just pass the costs on to customers and taxpayers Conversely, a lot of sites that have minimal security needs (a casual messageboard site, for example) have excessive security (they don't allow you to recover lost passwords easily, etc). Security decisions are business decisions, or at least they should be. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: storing passwords
-Original Message- From: RXZ JLo [mailto:[EMAIL PROTECTED]] Sent: Friday, November 22, 2002 4:51 AM To: Tomcat Users List Subject: Re: storing passwords Thanks to all of you for the responses. apart from this password I will be storing some other things too(they too are passwords but for some other things in the application). I cant use one way hash as I cant use them further. what mechanism should I follow in this case? Have you considered LDAP? I haven't used it myself but it might be a better solution if you have to store a variety of user information that will be used in more than one context. Also, for the login case should I bother about encryption in the login form? Can I just use input type=password/ and rely on the brower? What are the pros and cons for this? If you see yahoo login, they generate md5 using javascript on the client side itself - is this really necessary? Generating the md5 on the client side doesn't really do too much, since if I know the MD5 then basically I know the password. I just can't type it into Yahoo's UI since then *that* will get MD5'd and it will change the value sent. (Of course, I could use Mozilla and disable the JavaScript that does this... or write my own page... etc.) If you use SSL then you don't need to do the JavaScript trick -- the passwords will be sent over the wire encrypted. But if you can't or don't want to use SSL, then just remember that it is SUPER easy to listen in on HTTP connections and watch the data go back and forth. There's dozens of scripts that basically do this and hunt down likely passwords. So you want to implement *some* level of encryption unless everything you're doing is within a secure environment like behind a corporate firewall (note the quotes, that indicates a level of facetiousness). Erik -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
