This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
It looks like encryption. For example, "my password" gets encoded as "bXkgcGFzc3dvcmQ=". But if you know you are dealing with BASE64 encoding (equal signs at the end are a giveaway), then you can easily convert it back to the original text. See http://www.robertgraham.com/tools/base64coder.html for an example.
Hi Jim, I was in a position a while ago where we were told not to store the password required to connect to our backend systems in a readable from on our web/app servers. in the end i just used the base64 encoder becasue it satisifed their requirment but to be honest was a prettyweak measure. if someone is good enough to hack onto your network, and find the encoded properties file, they will have no trouble getting a your servlet/jsp class file, decomiling it, and finding out exactly what encoder you used. i cant really advise you on how you would use encryption to do a simliar thing. i know that encryption invloves digital certificates, which i assume need to be purchased ? cheers, dean
i cant really advise you on how you would use encryption to do a simliar thing. i know that encryption invloves digital certificates, which i assume need to be purchased ?
Historically there have been encryption techniques successfully used that are even weaker than Base64 encoding, but anyone who's REALLY planning to wreak mayhem already knows how to break them. As an encrpytion scheme, however, I doubt it's in any danger from John Ashcroft. For password encryption, the practice most highly thought of is ONE-WAY encrpytion. That is, a scheme where you can ENCRYPT a password, but not DECRYPT it. For verification purposes, that's all you need - a database table holding the userID and encypted password can be subjected to a search:
If the returned "gotcha" is not zero, there's a match. This minimizes copies of unencrypted passwords (and even encypted ones, to a degree) that will be floating around in your system. Certificates are not neccessary for many of these schemes. The Unix /etc/passwd file (or its shadow equivalents) works using the same technique listed above - minus the SQL. For algorithms that do require certificates, you can create a "self-signed" cert. Signing is only a requirement when you want the signing agency to vouch for you to a third party that doesn't know you well.
An IDE is no substitute for an Intelligent Developer.
Joined: Jan 31, 2002
hi tim, i wondered if you could explain how i might make use of one way password encryption in the following exapmle... Before I can use the EJB's for a backend database, I must first connect to the EJB server, and the connect method takes amongst others 2 string arguments: username and password. these are read from a properties file, only we cannot store a plainly readable password in the proerties file (incase someone hacks) therefore i do the following (decoding the Base64 encoded password). encodedPwd = props.getString("apiLinkPwd"); apiLinkPwd = new Base64Decoder(encodedPwd).processString(); APIAccessInfo apiAccessInfo = APIConnection.connect(apiLinkDomain, apiLinkUser, apiLinkPwd, apiLinkUrl); How would I use one way encryption in this scenario ?? cheers, dean
One way to do this is: 1) generate a key and save it in a file (make sure you have a backup) 2) encrypt your password and store it in your properties file 3) when you want to send the password, use the key to decrypt it Now to crack the password, someone would need the properties file, the key file, and the algorithm you used.
I think there is some confusion here between "encryption" and "authentication". The one-way encryption that you suggested is really not encryption. It's a simple message digest (or a one-way hash function) like MD5 or SHA. It is one-way because you cannot compute back the original data from it's message digest. Basically it amounts to that you never store user passwords in a database or file, but instead a message digest. When someone tries to authenticate himself, he presents you with a password, for which you calculate the digest value and compare it with the value stored in the database. This technique cannot be used to encrypt data, but can simply serve as an easy and effective authentication mechanism. [ May 02, 2002: Message edited by: Junaid Bhatra ]
Joined: May 05, 2000
Originally posted by Junaid Bhatra: I think there is some confusion here between "encryption" and "authentication".
The one way digest allows you to store a password in a way that is useless if someone discovers it. Since there is no way to take the message digest and turn it back into its original value, knowing the message digest won't get you into the system. user password ---> digest function ----> message digest The message digest is what is stored in the DB as the user's password. In the case here, this doesn't really help. You need to encrypt the version stored in your properties file and decrypt it when you present it.
Joined: Mar 10, 2002
Thanks to all of you for the discussion. I learnt from you.
Joined: Mar 10, 2002
But, I think the old UNIX password encryption is a kind of encoding. No certificate is required. Right? JB
I recommend you find a book or two on data encryption and study up on the java.security package. According to my Linux man page, passwd was using DES, but I seem to recall that there's also the option for MD5 and maybe other schemes as well. A Certificate is not basically about encryption - it's about authentification. A certificate is something a trusted third party issues in order to assure a second party (client) that the first part (you) is in fact, worthy of trust. For strictly internal work, if you can't trust yourself, you have bigger problems than encryption. Personally, I'm not sure how much storing encrypted passwords for internals systems use is worth. Anyone who can get to those databases for browsing is probably already in so deep that it no longer matters. And if security is that tight, it's probably better to have a trusted officer manually enter the password and not keep a computer-readable copy at all.