How to crypt and De-crpyt a password with a key?

[Zsolt Koppany]

Hi,

how can I crypt a password that can be de-crypted only if a key is known?

Zsolt

 

[Oliver Wong]

how can I crypt a password that can be de-crypted only if a key is known?

The question is vague, so this answer is vague. Assuming you wish to
write a program in Java that does encryption/decryption type stuff, I
recommend you take a look at the documentation for java.security on Sun's
API reference (http://java.sun.com/j2se/1.5.0/docs/api/index.html).

 

[Tor Iver Wilhelmsen]

how can I crypt a password that can be de-crypted only if a key is known?

Generally you never decrypt passwords: You store the encrypted/hashed
version, then use the same algorith on a clear-text password provided,
and compare the two.

Why do you think you need to decrypt it?

 

[Danijel]

Tor have right.
You never encrypt or decrypt passwords.
You only make MD5 or SHA1 hash of the password and then compare if input
also produces that hash.
You should also know that this method can bee broken for passwords that are
too small or dont have nubers and different characters inside.
If you use word from dictionary for your password it can bee broken in few
seconds.
Strong password is at least 10 character have Upercase,lowercase, numbers
and special characters.
This kind of password can't bee broken in 100 years.

 

[Roedy Green]

how can I crypt a password that can be de-crypted only if a key is known?

see http://mindprod.com/jgloss/encryption.html

Unfortunately, the answer to that simple question takes entire books
to answer. The people who know how seem to want you explain the gory
details of how, rather than just give you recipes.

 

[Roedy Green]

Generally you never decrypt passwords: You store the encrypted/hashed
version, then use the same algorith on a clear-text password provided,
and compare the two.

see http://mindprod.com/jgloss/digest.html

The strange things about digests, is even though everyone has access
to the algorithm to compute the digest, nobody can, given a digest,
figure out the text that it came from.

The can crack it of course by brute force, computing the digest of
every possible password.

A plain digest is not much extra help over the wire, since a snoop can
pick out the digest and send it again later.

So what you do is append the time to the password and send the digest
of that. The password digest is only valid for a few seconds. You
need to pass the time undigested too since the clocks are not in
perfect sync and it takes time for the message to arrive.

 

[Zsolt Koppany]

I do have to decrypt passwords because I have to start programs (for example
subversion) that need passwords.

 

[Oliver Wong]

I do have to decrypt passwords because I have to start programs (for
example subversion) that need passwords.

Rather than have the user supply a password to unlock a password to
unlock subversion, why not just have the user supply the password to
subversion in the first place?

What you want to do is probably possible, but note that storing
passwords, even in encrypted form, is a security risk.

- Oliver

 

[Zsolt Koppany]

I unstand that it is a security risk but some process are runnning every
night and nobody can provide a password.

zsolt

 

[Oliver Wong]

I unstand that it is a security risk but some process are runnning every
night and nobody can provide a password.

Okay, if you have no user available to provide the password then
SOMEWHERE, you have to store a password in plaintext, right? Either the
password for the process, or the password to unlock the password for the
process, or the password to unlock the password to unlock the password for
the process, and so on.

So basically encrypting passwords for this purpose is just a big joke.
If the passwords don't change often, the best I can think of is to hardcode
the passwords directly into the program, so that at the very least, an
attacker would need to decompile the program to get the passwords.

Alternatively, encrypt the passwords in a file, and then decrypt them
using a password hardcoded in the program.

Or encrypt the passwords in a file, and encrypt the password for THAT
file in a file, and then hardcode the password in your program.

And so on.

There should be a better way of what you want to do though, so if you'd
actually explain what it is you're trying to do (e.g. what processes you're
running, what environment you're working in, etc.), you might get more
advice. But I think this is no longer a Java issue.

- Oliver

 

[Raymond DeCampo]

Okay, if you have no user available to provide the password then
SOMEWHERE, you have to store a password in plaintext, right? Either the
password for the process, or the password to unlock the password for the
process, or the password to unlock the password to unlock the password for
the process, and so on.

So basically encrypting passwords for this purpose is just a big joke.
If the passwords don't change often, the best I can think of is to hardcode
the passwords directly into the program, so that at the very least, an
attacker would need to decompile the program to get the passwords.

Alternatively, encrypt the passwords in a file, and then decrypt them
using a password hardcoded in the program.

Wouldn't the most sensible approach be to encrypt the password in a file
(or other configuration artifact) with a public key and decrypt it with
the private key?

Or encrypt the passwords in a file, and encrypt the password for THAT
file in a file, and then hardcode the password in your program.

And so on.

There should be a better way of what you want to do though, so if you'd
actually explain what it is you're trying to do (e.g. what processes you're
running, what environment you're working in, etc.), you might get more
advice. But I think this is no longer a Java issue.

I don't think the environment really comes into play. The problem of an
automated process needing to access a password-protected resource is
both generic enough to be common and specific enough to describe the
needs of the OP.

HTH,
Ray

 

[Oliver Wong]

Wouldn't the most sensible approach be to encrypt the password in a file
(or other configuration artifact) with a public key and decrypt it with
the private key?

You'd still need to store the private key somewhere; either in an
external file, or hardcoded in the Java program itself, so you basically end
up in the same situation.

I don't think the environment really comes into play. The problem of an
automated process needing to access a password-protected resource is both
generic enough to be common and specific enough to describe the needs of
the OP.

Needing to supply a password, but not having a user around to supply the
password is a bad situation to be in, IMHO. Depending on what
password-protected resources the OP is trying to access, I'd recommend he
change his environment so that an administrator (or some other trusted
invididual) can install the program, and have the program inherit his rights
(operating system permitting), and then have the resource check for whether
the requestee has rights, rather than checking for an explicit password
(again, OS permitting, and resources permitting).

For example, if the user's running Linux, and the resources are files,
this is certainly possible. Under Windows, AFAIK, it's not, because you
cannot run program under another user's privilege without explicitly
providing a password WHEN the program gets executed. In this latter
environment, you'd probably need to have the program running continuously in
the background, so that it always maintains its original permission
settings.

- Oliver

 

[Raymond DeCampo]

You'd still need to store the private key somewhere; either in an
external file, or hardcoded in the Java program itself, so you basically end
up in the same situation.




Needing to supply a password, but not having a user around to supply the
password is a bad situation to be in, IMHO. Depending on what
password-protected resources the OP is trying to access, I'd recommend he
change his environment so that an administrator (or some other trusted
invididual) can install the program, and have the program inherit his rights
(operating system permitting), and then have the resource check for whether
the requestee has rights, rather than checking for an explicit password
(again, OS permitting, and resources permitting).

This solution is probably unrealistic as the protected resource is most
likely a remote service like a database or such which maintains its own
user/password scheme.

For example, if the user's running Linux, and the resources are files,
this is certainly possible. Under Windows, AFAIK, it's not, because you
cannot run program under another user's privilege without explicitly
providing a password WHEN the program gets executed. In this latter
environment, you'd probably need to have the program running continuously in
the background, so that it always maintains its original permission
settings.

Ray

 

[Zsolt Koppany]

We just start subversion and cvs clients to checkout sources from remote
servers because we have to provide statistical data (number of files etc).
Please understand that I DO NEED the passwords. It would be great if that
was not the case but it is, and I cannot do anything about that.

I like for example UNIX crypt that crypts a file with a key. Do you know
such a java solution?

Zsolt

 

[Oliver Wong]

We just start subversion and cvs clients to checkout sources from remote
servers because we have to provide statistical data (number of files etc).
Please understand that I DO NEED the passwords. It would be great if that
was not the case but it is, and I cannot do anything about that.

I like for example UNIX crypt that crypts a file with a key. Do you know
such a java solution?

I don't know much about UNIX, but according to
http://www.opengroup.org/onlinepubs/007908799/xsh/crypt.html it looks like
Crypt doesn't encrypt a file or anything like that, but rather just hashes
up a key with a given salt.

That is to say, once you have a key that was hashed by crypt(char*,
char*), you cannot "un-crypt" it. All you can do is re-crypt ANOTHER string
and check if it matches the original key (i.e. the user needs to resupply
the password).

Of course, I may be completely wrong about my interpretation of the
documentation for crypt, and if so, I apologize.

- Oliver

 

[Joan]

We just start subversion and cvs clients to checkout sources
from remote servers because we have to provide statistical data
(number of files etc). Please understand that I DO NEED the
passwords. It would be great if that was not the case but it
is, and I cannot do anything about that.

One place I worked some time ago had a nicely typed list of all
user account
names and passwords scotch taped to the side of the line printer.
Or ask
your boss for a list. After all, you can't polish her shoes if
she doesn't have any.

 

[Oliver Wong]

One place I worked some time ago had a nicely typed list of all user
account
names and passwords scotch taped to the side of the line printer. Or ask
your boss for a list. After all, you can't polish her shoes if she doesn't
have any.

If my understanding of Zsolt's problem is correct, there will be no
users around to enter in the password, so having the password written down
on a piece of paper isn't going to be much help. (S)he wants to write a Java
program to programmatically enter in the password.

- Oliver

 

[Shane Petroff]

If my understanding of Zsolt's problem is correct, there will be no
users around to enter in the password, so having the password written down
on a piece of paper isn't going to be much help. (S)he wants to write a Java
program to programmatically enter in the password.

It seems to me that your interpretation is correct. The OP should just
XOR, CRC32 or Base64 encode the passwords. It is not encryption since
the clear text are very easily recovered, but at least it keeps the
values hidden from a casual observer.

If that is not sufficiently secure, I can't imagine anything better
beyond compiling some native code to hold the password. Even that is
just slightly more 'security through obscurity'. Real security would
involve human intervention via passphrase or token pin.

 

[Raymond DeCampo]

We just start subversion and cvs clients to checkout sources from remote
servers because we have to provide statistical data (number of files etc).
Please understand that I DO NEED the passwords. It would be great if that
was not the case but it is, and I cannot do anything about that.

I like for example UNIX crypt that crypts a file with a key. Do you know
such a java solution?

Please do not top post.

Take a look at javax.crypto.Cipher. Another good precaution to take is
to use the facilities of the OS to protect the file containing the
passwords as much as possible.

HTH,
Ray