|
Question of the Week presents answers to key questions posed by the
developer community. The intent is to pass this
important, but not always easy-to-find information on to JDC members.
The questions are selected from the JDC newsgroups generally because:
they are frequently asked, they are significant or timely, or their answers are not easily
accessible.
Note: If you have a question to which you need an answer, try the
JDC newsgroups. You can read through
the existing newsgroups, or with your free
JDC membership, you can post new messages or threads.
Question of the Week
Archive
Topic:
Encrypted Passwords
Question:
How can I store an encrypted password?
I am looking for a way to encrypt passwords so that I can store them
in a database, something like the UNIX password encryption scheme. I
understand that there are one-way hash algorithms to encrypt passwords,
but I don't have the foggiest idea of where to look for more information,
or how to even start!
Answer:
The JDKTM 1.1 and later releases include
a secure hash method based on the National Institute of Standards and
Technology's (NIST) Secure Hash Standard. A secure hash is a function
that works in only one direction. It is like a trap door--you can easily
fall in, but you can't climb back out.
The documentation for SHA is available in the
java.security.MessageDigest
class.
Here is an example that compares two strings that are supplied on the
command line:
import java.io.*;
import java.security.*;
public class PasswordTest {
public static void main(String args[]) {
if (args.length != 2) {
System.err.println("usage:
PasswordTest password testvalue");
System.exit(1);
}
byte[] buf= new byte[args[0].length()];
args[0].getBytes(0, args[0].length(), buf, 0);
MessageDigest algorithm=null;
try {
algorithm = MessageDigest.getInstance("SHA-1");
}catch (NoSuchAlgorithmException e) {
System.out.println(e);
}
algorithm.reset();
algorithm.update(buf);
byte[] digest1 = algorithm.digest();
algorithm.reset();
buf= new byte[args[1].length()];
args[1].getBytes(0, args[1].length(), buf, 0);
algorithm.update(buf);
byte[] digest2 = algorithm.digest();
if(digest1.length != digest2.length) {
System.out.println("They do not match!");
System.exit(0);
}
for(int i=0; i<digest1.length ;i++) {
if(digest1[i] != digest2[i]) {
System.out.println("They do not match!");
System.exit(0);
}
}
System.out.println("They match!");
}
}
An excellent book for budding cryptographers is Bruce Schneier's
Applied Cryptography.
Many thanks to JDC member grkuntzmd for contributing to this answer.
Fri Feb 12 19:29:54 PST 1999
cstaylor
Also, the two most common ways of storing
hashes is either a) serialize those byte arrays
or b) use the sun.misc.BASE64Encoder to encode
them in Base-64.
Mon Feb 15 00:54:14 PST 1999
karorach
that's just great
Mon Feb 15 09:31:19 PST 1999
Gregorach
Am I being totally dense, or is this array declaration wrong? I've noticed this type of mistake a number of times in the example source on the JDC.
byte digest1[] = algorithm.digest();
Mon Feb 15 23:36:44 PST 1999
unwin
it is two bits of code pasted together
byte[] buf= new byte[args[0].length()];
and then
byte digest1[] = algorithm.digest();
The first is the preferred declaration :*)
Tue Feb 16 07:51:10 PST 1999
lcm
He is correct from the thoretical point of view. But I think that the question was about the DES algorithm (which variation makes the crypt(3) function in most Unix systems).
Until the last time Ive checked the Suns JDK API documentation, this algorithm was not supported. I just got a Java crypt(3) working when I found an independent implementatio of it on the Net.
This is somethign that is really lacking in the sgcurity API.
Tue Feb 16 08:16:20 PST 1999
252555
We have an Oracle Web Server installed on a Unix Box. The Oracle Web Server generates a program over HTTP through a Java Applet Viewer 1.1.5 (Sun's Applet Viewer Product). You be familiar with Oracle Apps....This is the web program.
My question is: does Oracle Web Server support the Servlet API? If it doesn't, is there a way to install it on the Oracle web server so that we can write a cookie that can be understood by the Applet Viewer on the client desktop?
Can the Java Applet Viewer accept cookies generated through servlet code without help from a web browser (ex. IE or Netscape) and store them in a local temp file (i.e. C:\Temp\Cookie:CookieFile.txt)?
Please Help........Trying to understand servlets and the compatibility with Oracle Web Server and Sun's Java Applet Viewer!
Patrick Gresham
isaac.p.gresham@ac.com
patrick.gresham@gecapital.com
Tue Feb 16 20:31:53 PST 1999
nharaoka
I compiled this program under JDK1.1.7B and JDK1.2. On either case a warning that
getBytes() is not recommended is displayed. What is the alternative?
Wed Feb 17 16:16:27 PST 1999
DTS:clark
How about storing an encrypted password for retrieval later and unencrypting so that it can be used as the passwd for a user/passwd pair for access to a protected resource?
ie How can I store it for use as a CLIENT, not as the authenticator ?
Thu Feb 18 02:58:29 PST 1999
r_kannan48
good
Thu Feb 18 06:17:44 PST 1999
yammy
Thanks,I can use this method on my project!!1
Thu Feb 18 12:10:08 PST 1999
roncraig
I also need to be able to encrypt and decrypt
passwords that will be stored in XML config files.
Any ideas?
Thu Feb 18 12:52:50 PST 1999
JMauricio
May I use this outside the U.S. ?
THE INFORMATION PROVIDED IN THE JAVA DEVELOPER'S CONNECTION IS PROVIDED 'AS IS'
WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING WITHOUT
LIMITATION THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR, AND
NON-INFRINGEMENT.
THIS INFORMATION IS PROVIDED AT NO CHARGE. BY USE OF THE INFORMATION YOU AGREE
THAT NEITHER SUN MICROSYSTEMS, INC. NOR ITS LICENSORS WILL BE LIABLE FOR ANY
DAMAGES WHATSOEVER INCLUDING DIRECT, INDIRECT, INCIDENTAL, CONSEQUENTIAL, LOSS OF
BUSINESS PROFITS OR SPECIAL DAMAGES, EVEN IF SUN OR ITS LICENSORS HAVE BEEN
ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. SOME STATES DO NOT ALLOW THE EXCLUSION OR
LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL DAMAGES SO THE FOREGOING
LIMITATION MAY NOT APPLY.
THIS INFORMATION COULD INCLUDE TECHNICAL INACCURACIES OR TYPOGRAPHICAL ERRORS.
CHANGES ARE PERIODICALLY ADDED TO THE INFORMATION HEREIN. SUN MICROSYSTEMS, INC.
MAY MAKE IMPROVEMENTS AND OTHER CHANGES IN THE PRODUCTS AND THE PROGRAMS
DESCRIBED HEREIN AT ANY TIME WITHOUT NOTICE.
|