Testing a password
Locked
 
|
Hi everyone,
I'm trying to develop some code to allow the user to type in a string password and then test the string. I wrote the following: GenericDialog GetPassword = new GenericDialog("Password"); GetPassword.addStringField(" Password: ", "password"); GetPassword.showDialog(); String ToPass = GetPassword.getNextString(); //Message for troubleshooting purposes int TestToPass = 0; if (ToPass == "password"){ TestToPass = 1; } IJ.showMessage("Password",ToPass); String StrTestToPass = Integer.toString(TestToPass); IJ.showMessage("TestToPass",Integer.toString(TestToPass)); Below this troubleshooting code I have the additional actions, but what's become clear is that whatever string is part of the dialog isn't being tested properly by the IF statement. If I make a string that equals "password" within the code, the IF statement triggers fine, but not when "password" is acquired from the getNextString() function. Thanks, Kevin Hallock |
|
|
Hi Kevin,
you stumbled into one of the famous Java gotchas! You cannot compare a string in Java with "==", it will check if it is exactly **the same** object, not directly the contents! (The compiler tries to reuse the "same" strings, so it sometimes seems to work somehow, as you found out!) You need to use "equals()", see for ex. here: http://leepoint.net/notes-java/data/strings/12stringcomparison.html Cheers Mit freundlichen Grüßen / Best regards Joachim Wesner Projektleiter Optik Technologiesysteme ____________________________________________ Leica Microsystems CMS GmbH | GmbH mit Sitz in Wetzlar | Amtsgericht Wetzlar HRB 2432 Geschäftsführer: Dr. Stefan Traeger | Dr. Wolf-Otto Reuter | Dr. David Roy Martyr | Colin Davis www.leica-microsystems.com hallockk <[hidden email]> Gesendet von: An ImageJ Interest [hidden email] Group Kopie <[hidden email]. GOV> Thema Testing a password 06.04.2010 21:01 Bitte antworten an ImageJ Interest Group <[hidden email]. GOV> Hi everyone, I'm trying to develop some code to allow the user to type in a string password and then test the string. I wrote the following: GenericDialog GetPassword = new GenericDialog("Password"); GetPassword.addStringField(" Password: ", "password"); GetPassword.showDialog(); String ToPass = GetPassword.getNextString(); //Message for troubleshooting purposes int TestToPass = 0; if (ToPass == "password"){ TestToPass = 1; } IJ.showMessage("Password",ToPass); String StrTestToPass = Integer.toString(TestToPass); IJ.showMessage("TestToPass",Integer.toString(TestToPass)); Below this troubleshooting code I have the additional actions, but what's become clear is that whatever string is part of the dialog isn't being tested properly by the IF statement. If I make a string that equals "password" within the code, the IF statement triggers fine, but not when "password" is acquired from the getNextString() function. Thanks, Kevin Hallock -- View this message in context: http://n2.nabble.com/Testing-a-password-tp4860684p4860684.html Sent from the ImageJ mailing list archive at Nabble.com. ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ |
|
|
Thanks!
Kevin
|
|
|
In reply to this post by Joachim Wesner
Hi,
On Tue, 6 Apr 2010, Joachim Wesner wrote: > You cannot compare a string in Java with "==", it will check if it is > exactly **the same** object, not directly the contents! FWIW this is only one of several gotchas that typically hit C++ programmers. We listed quite a few of the gotchas here: http://pacific.mpi-cbg.de/wiki/index.php/Tips_for_C%2B%2B_developers Ciao, Johannes |
|
|
On Tue, 6 Apr 2010, Joachim Wesner wrote:
> You cannot compare a string in Java with "==", it will check if it is > exactly **the same** object, not directly the contents! And one should be aware that retrieving the password from the class file is trivial, so it would not be secure at all. Cheers G. |
Antwort: Re: Testing a password
|
|
Yes,
I did not want to comment on that, actually as a minimum I would recommend some simple "garbling" of the stored password with some secret "constant" to avoid that the password will directly stand out in any text dump of the class file. Mit freundlichen Grüßen / Best regards Joachim Wesner Projektleiter Optik Technologiesysteme Leica Microsystems CMS GmbH | GmbH mit Sitz in Wetzlar | Amtsgericht Wetzlar HRB 2432 Geschäftsführer: Dr. Stefan Traeger | Dr. David Roy Martyr | Colin Davis www.leica-microsystems.com Gabriel Landini <[hidden email] C.UK> An Gesendet von: [hidden email] ImageJ Interest Kopie Group <[hidden email]. Thema GOV> Re: Testing a password 07.04.2010 10:21 Bitte antworten an ImageJ Interest Group <[hidden email]. GOV> On Tue, 6 Apr 2010, Joachim Wesner wrote: > You cannot compare a string in Java with "==", it will check if it is > exactly **the same** object, not directly the contents! And one should be aware that retrieving the password from the class file is trivial, so it would not be secure at all. Cheers G. ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ |
|
|
On Wednesday 07 April 2010, you wrote:
> I did not want to comment on that, actually as a minimum I would recommend > some simple "garbling" of the stored password with some secret "constant" to > avoid that the password will directly stand out in any text dump of the > class file. I was thinking of the risk of somebody using a decompiler that will retrieve some version of the code. In that case any procedural garbling of the string would be retrievable as well. Cheers G. |
|
|
In reply to this post by Joachim Wesner
Hi,
On Wed, 7 Apr 2010, Joachim Wesner wrote: > I did not want to comment on that, actually as a minimum I would > recommend some simple "garbling" of the stored password with some secret > "constant" to avoid that the password will directly stand out in any > text dump of the class file. Actually, making it secure would be trivial: byte[] getSHA1(String text) { try { MessageDigest digest = MessageDigest.getInstance("SHA-1"); digest.update(text.getBytes("UTF-8")); return digest.digest(); } catch (Exception e) { return null; } } ... and then only storing the SHA-1 of the password and comparing with that (via equals(), of course). Ciao, Johannes |
|
|
In reply to this post by Gabriel Landini
Why keep the actual password at all? Use **java.security.MessageDigest**
to create a hash, e.g. MD5. When you get the user's password you encrypt that and see if it comes to the same hash. Chris Mawata Gabriel Landini wrote: > On Wednesday 07 April 2010, you wrote: > >> I did not want to comment on that, actually as a minimum I would recommend >> some simple "garbling" of the stored password with some secret "constant" to >> avoid that the password will directly stand out in any text dump of the >> class file. >> > > I was thinking of the risk of somebody using a decompiler that will retrieve > some version of the code. In that case any procedural garbling of the string > would be retrievable as well. > Cheers > > G. > > |
«
Return to ImageJ
|
1 view|%1 views
| Free forum by Nabble | Edit this page |