Dear everybody,
I would like to find a way to hide password on command line when user type password. There is a way that use another thread to output '\b*'. However, it has some bugs. And I can't use Console class which has a method to hide password. Because my JDK is 1.5 and I can't change it because of some reasons.
Does anybody know a way to hide password on command line?
Thanks very much!
> Dear everybody,
>
> I would like to find a way to hide password on
> command line when user type password. There is a way
> that use another thread to output '\b*'. However, it
> has some bugs. And I can't use Console class which
> has a method to hide password. Because my JDK is 1.5
> and I can't change it because of some reasons.
> Does anybody know a way to hide password on command
> line?
> Thanks very much!
In Java 1.5? You can't.
Like you already said: this can only be done with the new Java version (1.6) with the Console class.
> Because my JDK is 1.5 and I can't change it because of some reasons.
Look how sweet Console is in 1.6:
import java.io.Console;
public class ConsoleExample {
public static void main(String[] args) {
Console console = System.console();
char[] password = console.readPassword("Please enter password:");
//don't do this: passwords shouldn't be stringified
String s = new String(password);
console.format("password =[%s]%n", s);
}
}
Find a way to install 1.6! We believe in you!
> > //don't do this: passwords shouldn't be
> stringified
> >
> > How do you pass it to the DB if it's not a String?
>
> That is a dilli of a pickle.
I vaguely remember reading something about this but cant remember the details - why should they not be stringy but it is OK to have them in a character array?
> I would like to find a way to hide password on command line when user type password.
Why are you reading the data from the console? Just display a simple GUI asking for the password. Then you don't have the problem. It will work in any version of the JDK.
Otherwise maybe this will be acceptable:
http://forum.java.sun.com/thread.jspa?forumID=256&threadID=264992
That's an interesting article that I'd seen before and yes, public char[] getPassword()
supercedes public String getText()
for the JPasswordField in swing. But not in AWT for TextField, and all the getConnection methods in java.sql.DriverManager class take Strings for URLs or PWDs. Would JPasswordField jpf = new JPasswordfield(" ... ");
// ...
String url,
user;
char[] pwd = jpf.getPassword();
DriverManager.getConnection(url, user, new String(pwd));
... do the trick ... I don't know.
> > > //don't do this: passwords shouldn't be
> > stringified
> > >
> > > How do you pass it to the DB if it's not a
> String?
> >
> > That is a dilli of a pickle.
>
> I vaguely remember reading something about this but
> cant remember the details - why should they not be
> stringy but it is OK to have them in a character
> array?
Because you can explicitly clear out the characters in the array as soon as you're done with it. You can't do this with a String.
As for sending it to the DB, you'd have to setBytes or setBlob or setObject. Never tried it, but one of those should work.
> new String(pwd)
*Ding*! I assume the point is to avoid creating a java.lang.String,
because it will hang around in memory for a spell and could be sniffed out
by another process examining the JVM process' memory.
I wonder if the DriverManager.getConnection method that takes a Properties
object would be willing to have it map "user" to a char[]?
> > > > //don't do this: passwords shouldn't be
> > > stringified
> > > >
> > > > How do you pass it to the DB if it's not a
> > String?
> > >
> > > That is a dilli of a pickle.
> >
> > I vaguely remember reading something about this
> but
> > cant remember the details - why should they not
> be
> > stringy but it is OK to have them in a character
> > array?
>
>
> Because you can explicitly clear out the characters
> in the array as soon as you're done with it. You
> can't do this with a String.
>
> As for sending it to the DB, you'd have to setBytes
> or setBlob or setObject. Never tried it, but one of
> those should work.
HuH? ... no, I was talking about logging in / you know, creating a Connection - sorry that was not clearer - see my other post that clarifies a bit more.
> > new String(pwd)
>
> *Ding*! I assume the point is to avoid creating a
> java.lang.String,
> because it will hang around in memory for a spell and
> could be sniffed out
> by another process examining the JVM process'
> memory.
>
> I wonder if the DriverManager.getConnection method
> that takes a Properties
> object would be willing to have it map "user" to a
> char[]?
If that was preferred, then why don't they depcrecate the other methods for this reason?
> > As for sending it to the DB, you'd have to setBytes
> or setBlob or setObject. Never tried it, but one of
> those should work.
>
> I think the point here is that the password is not
> data but the user password
> to connect to the database.
D'OH!
> > I vaguely remember reading something about this
> but
> > cant remember the details - why should they not
> be
> > stringy but it is OK to have them in a character
> > array?
>
>
> Because you can explicitly clear out the characters
> in the array as soon as you're done with it. You
> can't do this with a String.
Of course! Thanks.
Although I guess this shouldn't be much of an issue in practice. The DB should only be accessed from a trusted app on a trusted host, where we have control over and knowledge of what apps are running. If the password is entered at that host's console, capturing it into a char[] vs. a String isn't really an issue.
But if the password is entered at a different host, then we'd want the char[], encrypt it, send it to the host that will connect to the db, decrypt, and turn it into a string where it's "safe."
> Although I guess this shouldn't be much of an issue
> in practice. The DB should only be accessed from a
> trusted app on a trusted host, where we have control
> over and knowledge of what apps are running. If the
> password is entered at that host's console, capturing
> it into a char[] vs. a String isn't really an issue.
>
> But if the password is entered at a different host,
> then we'd want the char[], encrypt it, send it to the
> host that will connect to the db, decrypt, and turn
> it into a string where it's "safe."
I think that is a very reasonable way to view it.
Actually there is. It is not very clean but it works. It involves using a thread that writes a back space and a * constantly while your waiting for input. When a user types a character it is pretty much immediately deleted and replaced with a '*'. See: http://java.sun.com/developer/technicalArticles/Security/pwordmask/ for details on how to implement.
> Actually there is. It is not very clean but it works.
> It involves using a thread that writes a back space
> and a * constantly while your waiting for input. When
> a user types a character it is pretty much
> immediately deleted and replaced with a '*'. See:
> http://java.sun.com/developer/technicalArticles/Secur
> ty/pwordmask/ for details on how to implement.
Did you read the original question? The OP says that he tried that, but it's not a good solution.
Kaj
