★ wanayoo — archive 1999 http://developer.java.sun.com/developer/qow/archive/28/index.htmlNouvelle recherche | Portail wanayoo
Java Technology Home Page
A-Z Index

Java Developer Connection(SM)
Question of the Week

Downloads, APIs, Documentation
Java Developer Connection
Tutorials, Tech Articles, Training
Online Support
Community Discussion
News & Events from Everywhere
Products from Everywhere
How Java Technology is Used Worldwide
 

Question of the Week No. 28
Researched by Calvin Austin


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.


[ This page was updated: 12-Jan-2000 ]
Products & APIs | Developer Connection | Docs & Training | Online Support
Community Discussion | Industry News | Solutions Marketplace | Case Studies
Glossary - Applets - Tutorial - Employment - Business & Licensing - Java Store - Java in the Real World
FAQ | Feedback | Map | A-Z Index
For more information on Java technology
and other software from Sun Microsystems, call:
(800) 786-7638
Outside the U.S. and Canada, dial your country's AT&T Direct Access Number first.
Sun Microsystems, Inc.
Copyright © 1995-2000 Sun Microsystems, Inc.
All Rights Reserved. Terms of Use. Privacy Policy.