You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Yo...@lifeisgreat.com.sg on 2003/04/24 12:27:52 UTC
Thanks Re: Password Encryption
Thanks to all for the response and 4 being great critics.
Think need to look more thoroughly to handle all security issues and
concerns which everybody has rightly raised.
Appreciate your responses.
Regards.
"Phil Steitz"
<phil@steitz.c To: "Struts Users Mailing List" <st...@jakarta.apache.org>
om> cc:
Subject: Re: Password Encryption
24/04/2003
12:20 PM
Please respond
to "Struts
Users Mailing
List"
YogeshChawla@lifeisgreat.com.sg wrote:
> The other system basically contain OEM Products which require Password in
> original form for anthentication at their end.
> These of course I cannot recode ! ! Also do not have the option of change
> over of these products. (My first choice would have been to avoid such
> products)
>
> I have some additional checks in mind for the url hacking part.
> Still as you say "The problem remains for the hacking of the URL". Would
> need to check further into this part.
>
> How can a url be made unique, meaning LOWERING the security concerns -
what
> all can be done to make it unique
> @ Random Numbers, Expiration Date..Any other ideas ...
>
Understanding that user identification is NOT authentication and there
is no really secure way to do this, here are two progressively more
effective ways to prevent users from hacking the id strings that you
send them in emails, querystrings or cookies:
1. Generate the strings randomly, using an algorithm that makes them
more or less unpredictable, so if a user makes a change to the string,
the probability that s/he will "hit" a valid id string is very low.
Tomcat's session ID generation algorithm is a good example of this. You
can see the source at http://cvs.apache.org/viewcvs/jakarta-tomcat-4.0/
Navigate to /src/share/org/apache/catalina/session/ManagerBase.java and
look at the generateSessionId method.
2. To make things even harder for the would-be hacker, you can push a
string that has the form S1|S2, where S1 is an ID string generated as
above; but S2 is a hash of S1 + some "secret" bytes maintained in your
code. When the user sends the full string back, you compute the hash of
S1 + "secret" and compare this with S2. If they match, there has been
no tampering.
Once again, as Brian and others have pointed out, enabling "auto-login"
via special querystrings is NOT a secure way to authenticate users. No
matter how you do it, if someone intercepts the message (which will most
likely be transmitted at some point along the way in clear text), they
will be able to "auto login" to the intended recipient's account. The
techniques presented above just make it harder for whoever gets hold of
these emails to get into accounts other than the ones that they are set
up for.
> Are there any Providers for Encryption for which I do not need to make
any
> changes to the java.policy file regarding their usage. This is also a
> concern.
>
> Appreciate your response.
>
> Regards.
>
>
>
>
> "Brian Lee"
> <brian_a_lee@ho To:
struts-user@jakarta.apache.org
> tmail.com> cc:
> Subject: Re: Password
Encryption
> 23/04/2003
> 09:54 PM
> Please respond
> to "Struts
> Users Mailing
> List"
>
>
>
>
>
>
> If there's no cookie or other method to identify a user, what prevents a
> malicious user from "hacking" the url or stealing your user's link? If
you
> code something like this in your system you are opening yourself up to
> serious problems in the future.
>
> If you want to use a single sign-on system between your app and another
you
>
> can do that without knowing the user's password (ie- your app sends the
> hashed password to other app that sends back auth/no-auth or something
like
>
> that).
>
> If you must store password to other sites then use pki to secure the
> sensitive data, but they should still have a different password to access
> your site (and that password should be hashed).
>
> BAL
>
>
>>From: YogeshChawla@lifeisgreat.com.sg
>>Reply-To: "Struts Users Mailing List" <st...@jakarta.apache.org>
>>To: "Struts Users Mailing List" <st...@jakarta.apache.org>
>>Subject: Re: Password Encryption
>>Date: Wed, 23 Apr 2003 11:22:55 +0800
>>
>>
>>
>>Cannot do as suggested - for accessing other systems.
>>Until user is signed in and I also require access to other systems thro'
>>the password, I cannot go forward.
>>The preexisting cookie can also be set only if user accesses the
>>application thro normal login procedure. The first time scenario would
not
>>work - If the user never accesses the application thro' common logging.
>>
>>Regards.
>>
>>
>>
>>
>> "Brian
>> Alexander Lee" To: "Struts Users Mailing
>>List" <st...@jakarta.apache.org>
>> <brian_a_lee@ho cc:
>> tmail.com> Subject: Re: Password
>>Encryption
>>
>> 23/04/2003
>> 11:08 AM
>> Please respond
>> to "Struts
>> Users Mailing
>> List"
>>
>>
>>
>>
>>
>>
>>You don't need the decrypted password to fulfill the scenario you
describe
>>below. If you want to send out an "auto-login" link, you don't need their
>>password. Just make the link like http://mysite.com/login.do?userid=1234.
>>Of
>>course this direct login creates an extreme security problem and should
>
> not
>
>>be used unless coupled with a preexisting cookie set on the user's
>
> machine.
>
>>BAL
>>----- Original Message -----
>>From: <Yo...@lifeisgreat.com.sg>
>>To: "Struts Users Mailing List" <st...@jakarta.apache.org>
>>Sent: Tuesday, April 22, 2003 9:24 PM
>>Subject: Re: Password Encryption
>>
>>
>>
>>>Thanks for your reply.
>>>I completely understand your suggestions on the password for one way
>>>hashing. The problem lies in the functionality.
>>>
>>>There are certain functionalities whereby users need to auto login into
>>
>>the
>>
>>>system wherein I would need the decrypted passwords to be able to log
>>
>>them
>>
>>>on.
>>>E.g. A mail sent to a particular user whereby clicking on the link in
>>
>>the
>>
>>>Email would allow them to directly being logged on to the system.
>>>So I guess that this is going to require access to decrypted passwords.
>>>Are there any other possible options.
>>>
>>>Appreciate your response.
>>>
>>>Regards.
>>>
>>>
>>>
>>>
>>> "Ian Hunter"
>>> <ihunter@hunte To: "Struts Users Mailing
>>
>>List" <st...@jakarta.apache.org>
>>
>>> rweb.net> cc:
>>> Subject: Re: Password
>>
>>Encryption
>>
>>> 22/04/2003
>>> 09:04 PM
>>
>>> Please respond
>>> to "Struts
>>> Users Mailing
>>> List"
>>>
>>>
>>>
>>>
>>>
>>>
>>>There is really no reason to ever require the decrypted password; what
>>
>>is
>>
>>>it you're doing that requires it? If you have to interface with
>>
> another
>
>>>login system (like RADIUS or something), use the other login system to
>>>authenticate your users.
>>>
>>>If you make the password "decryptable" then it is possible that you
>>
> will
>
>>>decrypt the passwords, and assuming that users reuse their passwords,
>>
>>you
>>
>>>could gain access to users' other accounts. You might not think it's a
>>>problem that you yourself can decrypt the passwords, but as a user I
>>
> can
>
>>>assure you that knowing that would make me go use a different system.
>>>
>>>Short version is, hash your passwords with SHA1 and only compare
>>
>>hashes...
>>
>>> ----- Original Message -----
>>> From: Nagendra Kumar O V S
>>> To: struts-user@jakarta.apache.org
>>> Sent: Tuesday, April 22, 2003 7:15 AM
>>> Subject: Re: Password Encryption
>>>
>>>
>>> HI,
>>> I have gone thro' all ur messages , and i always suggest,
>>> 1. Always use MD5 or SHA1 Hashing algorigthms for storing the
>>>passwords, which ofcourse is one way hashing.
>>> 2. But if ur particular that u need the passwords at some
>>
> point,
>
>>>always use a single symmetric for encrypting and decrypting. This
>>>maintaining of this key is very important. using a different symmetric
>>
>>key
>>
>>>for each password leads to key management problems.
>>>
>>> but i still suggest u to rethink to implement hashing alg. for
>>
>>ur
>>
>>>passwords.
>>>
>>> bye
>>>
>>> -------Original Message-------
>>>
>>> From: Struts Users Mailing List
>>> Date: Tuesday, April 22, 2003 03:41:02 PM
>>> To: Struts Users Mailing List
>>> Subject: Re: Password Encryption
>>>
>>> Well, still looking for the Encryption part , but would be able
>>
>>to
>>
>>>manage
>>> that.
>>> Need to know one thing. Is is better to have one generated key
>>>which can be
>>> used to encrypt and decrypt all messages. Or to generate one
>>
> key
>
>>>for each
>>> password and storing it
>>> Also the issue fo randomness for mixing the password with some
>>
>>salt
>>
>>>? Is
>>> that suitable..And should that be implemented.
>>>
>>> I am using DES as the algo . Would be storing the encrypted
>>>password in the
>>> database.
>>> The generated key I am planning to store in a file and that I
>>
>>would
>>
>>>be
>>> picking up for decrypting the password.
>>> I am also mixing some keys with the password before storing.
>>>
>>> Thanks
>>>
>>> Yogesh
>>>
>>>
>>>
>>>
>>> "Cheng Xu"
>>> <xu_cheng_cn@ho To: struts-user@jakarta.apache.org
>>> tmail.com> cc:
>>> Subject: Re: Password Encryption
>>> 22/04/2003
>>> 03:49 PM
>>> Please respond
>>> to "Struts
>>> Users Mailing
>>> List"
>>>
>>>
>>>
>>>
>>>
>>>
>>> You can try JCE. I use JCE to do symmetric key
>>>encryption/decryption in my
>>> application.
>>>
>>> Sample code:
>>>
>>> public String decrypt(InputStream ciphertextstream) throws
>>> DecryptorException {
>>> byte[] ciphertext;
>>>
>>> SecretKey key = new SecretKeySpec(default_key,
>>> Decryptor.DEFAULT_CIPHER_TYPE);
>>>
>>> try {
>>> ObjectInputStream ois = new
>>
> ObjectInputStream(ciphertextstream);
>
>>> int length = ois.readInt();
>>> ciphertext = new byte[length];
>>>
>>> ois.read(ciphertext);
>>>
>>> cipher = Cipher.getInstance(ciphertype);
>>> cipher.init(Cipher.DECRYPT_MODE, key);
>>> byte[] plaintext = cipher.doFinal(ciphertext);
>>> return new String(plaintext);
>>> }
>>> catch (IOException e) {
>>> throw new DecryptorException(e.getMessage());
>>> }
>>> catch (Exception e) {
>>> throw new DecryptorException(e.getMessage());
>>> }
>>>
>>> Guess you can figure out the encryption part easily after
>>
>>looking
>>
>>>into JCE.
>>>
>>> >From: YogeshChawla@lifeisgreat.com.sg
>>> >Reply-To: "Struts Users Mailing List"
>>><st...@jakarta.apache.org>
>>> >To: "Struts Users Mailing List"
>>
>><st...@jakarta.apache.org>
>>
>>> >Subject: Password Encryption Date: Tue, 22 Apr 2003 15:21:21
>>
>>+0800
>>
>>> >
>>> >
>>> >Thanks to all for your response.
>>> >However there seems to be a problem which I am facing and
>>
> which
>
>>>basically
>>> >reflects what Voytek has written in the mail below.
>>> > - - Not to refer to MD5 as encryption.
>>> >
>>> >The issue is that I do not have any option of converting the
>>>hashed MD5
>>> >password back to its original form. Therefore it seems that I
>>>cannot just
>>> >only use MD5 for hashing the password and storing in the
>>
>>database
>>
>>>since I
>>> >require the original password in certain cases.
>>> >
>>> >I would like to know what is the best option for the
>>
>>functionality
>>
>>>of both
>>> >encrypting and decrypting the password.
>>> >Any small sample program or link would also be a great help.
>>> >
>>> >Really would appreciate your responses asap.
>>> >
>>> >Regards,
>>> >
>>> >Yogesh
>>> >
>>> >
>>> >
>>> > Jarnot Voytek Contr
>>> > AU HQ/SC To: "'Struts Users
>>> >Mailing List'" <st...@jakarta.apache.org>
>>> > <Voytek.Jarnot@MAXWE cc:
>>> > LL.AF.MIL> Subject: RE: Password
>>> >Encryption using MD5
>>> >
>>> > 17/04/2003 08:56 PM
>>> > Please respond to
>>> > "Struts Users
>>> > Mailing List"
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >We convert the result of the hash into a string of hex, so we
>>
>>can
>>
>>>store it
>>> >in a varchar2 field... otherwise the weird chars seemed to
>>
>>confuse
>>
>>>oracle.
>>> >
>>> >It's also a really good idea to not refer to MD5 as
>>
>>'encryption',
>>
>>>your
>>> >passwords are not encrypted - they are hashed...
>>> >
>>> >--
>>> >Voytek Jarnot
>>> >Quidquid latine dictum sit, altum viditur.
>>> >
>>> > > -----Original Message-----
>>> > > From: YogeshChawla@lifeisgreat.com.sg
>>> > > [mailto:YogeshChawla@lifeisgreat.com.sg]
>>> > > Sent: Thursday, April 17, 2003 2:50 AM
>>> > > To: Struts Users Mailing List
>>> > > Subject: Password Encryption using MD5
>>> > >
>>> > >
>>> > > Hello,
>>> > >
>>> > > Need one important info. Really would appreciate your help
>>
>>on
>>
>>> > > this one.
>>> > >
>>> > > If I need to store Message Digest encrypted passwords in a
>>> > > database, what
>>> > > database datatypes can be used and what should be the size
>>
>>of
>>
>>> > > the column
>>> > > for storage.
>>> > > What is the possible Maximum length of the generated digest
>>
>
>>?
>>
>>> > >
>>> > > Can anybody reply on this asap.
>>> > >
>>> > > Thanks,
>>> > >
>>> > > Yogesh
>>> > >
>>> > >
>>> > >
>>> > >
>>
>>--------------------------------------------------------------
>>
>>> > > --------------
>>> > > -----
>>> > >
>>> > > CONFIDENTIALITY CAUTION :
>>> > > The email is only for the use of the person or entity to
>>
>>whom
>>
>>>it is
>>> > > addressed and contains information that is privileged and
>>> > > confidential. If
>>> > > you, the reader of this email are not the intended
>>
>>recipient,
>>
>>>any
>>> > > distribution, copying or dissemination of this email is
>>>strictly
>>> > > prohibited. If you have received this email in error,
>>
> please
>
>>> > > contact the
>>> > > sender immediately by return email and delete this email.
>>> > > Thank you. Please
>>> > > visit our website at http://www.lifeisgreat.com.sg.
>>> > >
>>> > >
>>
>>--------------------------------------------------------------
>>
>>> > > --------------
>>> > > -----
>>> > >
>>> > >
>>> > >
>>> > >
>>>---------------------------------------------------------------------
>>> > > To unsubscribe, e-mail:
>>>struts-user-unsubscribe@jakarta.apache.org
>>> > > For additional commands, e-mail:
>>>struts-user-help@jakarta.apache.org
>>> > >
>>> > >
>>> > > This transmission (and any information attached to it) may
>>
>>be
>>
>>> > > confidential and is intended solely for the use of the
>>> > > individual or entity to which it is addressed. If you are
>>
>>not
>>
>>> > > the intended recipient or the person responsible for
>>> > > delivering the transmission to the intended recipient, be
>>> > > advised that you have received this transmission in error
>>
>>and
>>
>>> > > that any use, dissemination, forwarding, printing, or
>>
>>copying
>>
>>> > > of this information is strictly prohibited. If you have
>>> > > received this transmission in error, please immediately
>>> > > notify LabOne at the following email address:
>>> > > securityincidentreporting@labone.com
>>> > >
>>> > >
>>> > >
>>> > >
>>>---------------------------------------------------------------------
>>> > > To unsubscribe, e-mail:
>>>struts-user-unsubscribe@jakarta.apache.org
>>> > > For additional commands, e-mail:
>>>struts-user-help@jakarta.apache.org
>>> > >
>>> >
>>> >
>>>---------------------------------------------------------------------
>>> >To unsubscribe, e-mail:
>>
>>struts-user-unsubscribe@jakarta.apache.org
>>
>>> >For additional commands, e-mail:
>>>struts-user-help@jakarta.apache.org
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>>---------------------------------------------------------------------
>>> >To unsubscribe, e-mail:
>>
>>struts-user-unsubscribe@jakarta.apache.org
>>
>>> >For additional commands, e-mail:
>>>struts-user-help@jakarta.apache.org
>>> >
>>>
>>>
>>>
>>_________________________________________________________________
>>
>>> Find gifts, buy online with MSN Shopping.
>>>http://shopping.msn.com.sg/
>>>
>>>
>>>
>>>---------------------------------------------------------------------
>>> To unsubscribe, e-mail:
>>
>>struts-user-unsubscribe@jakarta.apache.org
>>
>>> For additional commands, e-mail:
>>>struts-user-help@jakarta.apache.org
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>---------------------------------------------------------------------
>>> To unsubscribe, e-mail:
>>
>>struts-user-unsubscribe@jakarta.apache.org
>>
>>> For additional commands, e-mail:
>>>struts-user-help@jakarta.apache.org
>>>
>>>
>>>
>>>
>>> .
>>>
>>>
>>> ____________________________________________________
>>> IncrediMail - Email has finally evolved - Click Here
>>>
>>>
>>>
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
>>>For additional commands, e-mail: struts-user-help@jakarta.apache.org
>>>
>>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: struts-user-help@jakarta.apache.org
>>
>>
>>
>>
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: struts-user-help@jakarta.apache.org
>>
>
>
>
> _________________________________________________________________
> STOP MORE SPAM with the new MSN 8 and get 2 months FREE*
> http://join.msn.com/?page=features/junkmail
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-user-help@jakarta.apache.org
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-user-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org