Develop Reference

Obfuscating password LDAP AD

I have my parameters in a properties file.
managerDn=cn=read-only-admin,dc=example,dc=com
managerPassword=69BPoqG3sWr/MNspi4ZsDw==
server=ldaps://server.local:636
groupSearchBase=ou=test,dc=example,dc=com
base=dc=example,dc=coms
My password is encrypted, but the client told me: all you have done is encrypt the password and we need it Obfuscating ie making so that no one can read it.
Any idea?

Maybe the best option is to base64 encode the entire property file. It's not encryption but and more "obfuscation". To do this you could do something like this:
//encode:
def encoded = file.text.bytes.encodeBase64().toString()
//decode:
def password = new String(file.text.decodeBase64())
Your property file would like this:
bWFuYWdlckRuPWNuPXJlYWQtb25seS1hZG1pbixkYz1leGFtcGxlLGRjPWNvbQ0KbWFuYWdlclBhc3N3b3JkPTY5QlBvcUczc1dyL01Oc3BpNFpzRHc9PQ0Kc2VydmVyPWxkYXBzOi8vc2VydmVyLmxvY2FsOjYzNg0KZ3JvdXBTZWFyY2hCYXNlPW91PXRlc3QsZGM9ZXhhbXBsZSxkYz1jb20NCmJhc2U9ZGM9ZXhhbXBsZSxkYz1jb21z
here is a link that might help with base64 in Groovy.
NOTE: This really doesn't make anything more secure it's just hiding the plain text. Anyone that knows what they're looking at would decode it the same way you would. It would seem your client isn't familiar with this type of security. There are more secure ways of doing this. You may want to look into salting the actual encryption process or using a token exchange with another service to give you the password.

How to obscure Database password?

I am using JPA2.0 (Eclipselink) to interact with DB and I have persistence.xml file which has some DB configuration. I want to obscure the password used for accessing DB. I am using eclipse IDE. The following config tags are used in persistence.xml file.
<property name="javax.persistence.jdbc.user" value="app"/>
<property name="javax.persistence.jdbc.password" value="password"/>
I don't want to mention the password here in xml. How do I go about it?
Note: My application is composed of Swing with Apache's Derby Embedded DB.

You could let the server store the password and then you can retrieve it using JNDI.
It would also be possible to encrypt the password, and decrypt in the client. Although this would be susceptible to dictionary attacks, or even straight out reversing the process by decompiling your program.

What typically happens in this scenario is you store the hash in the XML file and on the backend you validate that the hashes match.
You should be able to do something like the following pseudocode:
String password = property.getParam(password);
String user = property.getParam(user);
function validateHash(String unhashedPassword, String unhashedUser)
{
String passHash = generateMD5(unhashedPassword);
String userHash = generateMD5(unhashedUser);
if(!password.equals(passHash) && !user.equals(userHash)
{
throw new SecurityException("Oh noez hackstar");
}
}
The discussion around which hashing algorithm to use is a lengthy one, there is nothing that bad about MD5 as long as you aren't trying to protect nuclear launch codes.

Updating LDAP encrypted password via JNDI

I need some pointers how to update an encrypted password in an LDAP (OpenLDAP) of a user within an LDAP tree. The passwords in the LDAP server are prefixed with {crypt} which I suppose indicates that it is encrypted (with DES?)
I need to write a method which updates a user's passwords. What is the right way to do this? Do I need to prefix the string with {crypt} myself? How do I encrypt the password for {crypt}?
UPDATE:
Just to clarify what I need is the Java code to encrypt the attribute so that it works with {crypt}. I also don't know if I have to prefix the attribute with the string {crypt} myself.

No, you just need to update the attribute, just like any other attribute, but remembering that unlike most attributes it is a byte[] not a String.
There is also an ExtendedOperation for password modification in association with the Password Policy IETF draft, but you haven't mentioned you're using that.

In some cases, using a pre-encoded password might prevent the directory server from enforcing password quality checks.

How to REALLY secure a PDF, using ItextPDF preferably?

I've been working on settting passwords on PDFs to prevent copy/paste and allow printing, add watermarks and set an owner password to prevent further changes.
Everything works well as expected, no issue there.
Then I downloaded this free for 15 days pdf removal tool, a-pdf. In a blink it removes all protection, no matter the complexity of the password (tried with 50 char length will all kind of chars).
I see there are other methods in itextPDF to encrypt a document. I used the following:
File f = new File("C:/TEMP/zip/waterMarked.pdf");
String hardPassword = "D 5BaIZQ# CqAk+NQCW)7Dkgb#i&02ifu!2TMX*d 0TGK(j(Kq";
byte[] hardPasswordByte = hardPassword.getBytes();
PdfReader reader = new PdfReader("C:/TEMP/zip/Original_document-9.pdf");
FileOutputStream out = new FileOutputStream(f);
PdfStamper stamp = new PdfStamper(reader, out);
//first argument is the user password. If set to something it asks for password when opening file, not wanted.
stamp.setEncryption(null, hardPasswordByte, PdfWriter.ALLOW_PRINTING, true);
//do stuff on the stamper, save file.
Does anyone knows a better way to protect PDF documents from Java code ?

PDF files support 2 passwords: user password and owner password. A user can view the PDF file if he knows any of these passwords. If the file has a user password, when the file is opened with a PDF viewer, the viewer asks the user to enter a password and either the user or owner passwords will work. If the file has only an owner password, the document is displayed automatically and the password is required when trying to change the file's access rights. This is the flow of operations suggested by PDF specification, but in reality it works like this: if the file is protected with a user password, brute force approach is required for password cracking, the longer the password is the longer it takes to crack. Problem is your real users need the password to open the file. If the file is protected only with an owner password, there is a default decryption key (remember, any viewer can display the PDF file without requesting a password) and the application that processes the PDF file decides whether to respect or not the document access rights. Once the file has been decrypted, it is saved without encryption and the output file has no longer a password. Since your documents have only the owner password, the tool removes it without problems using the default decryption key.
There are a few solutions (more or less related to iText) depending on your audience:
simple PDF encryption (with the problems above) if your audience is widespread, for example you publish papers on a website; 3rd party DRM solution, more complex and requires various plugins installed on your users' computers; certificate encryption (no sure if iText supports it), again complex, requires each user to have a digital certificate and documents access is defined for each user. Last 2 options work in a controlled enterprise environment.

Protect embedded password

I have a properties file in java, in which I store all information of my app, like logo image filename, database name, database user and database password.
I can store the password encrypted on the properties file. But, the key or passphrase can be read out of the jar using a decompiler.
Is there a way to store the db pass in a properties file securely?

There are multiple ways to manage this. If you can figure out a way to have a user provide a password for a keystore when the application starts up the most appropriate way would be to encrypt all the values using a key, and store this key in the keystore. The command line interface to the keystore is by using keytool. However JSE has APIs to programmatically access the keystore as well.
If you do not have an ability to have a user manually provide a password to the keystore on startup (say for a web application), one way to do it is to write an exceptionally complex obfuscation routine which can obfuscate the key and store it in a property file as well. Important things to remember is that the obfuscation and deobfuscation logic should be multi layered (could involve scrambling, encoding, introduction of spurious characters etc. etc.) and should itself have at least one key which could be hidden away in other classes in the application using non intuitive names. This is not a fully safe mechanism since someone with a decompiler and a fair amount of time and intelligence can still work around it but is the only one I know of which does not require you to break into native (ie. non easily decompilable) code.

You store a SHA1 hash of the password in your properties file. Then when you validate a users password, you hash their login attempt and make sure that the two hashes match.
This is the code that will hash some bytes for you. You can easily ger bytes from a String using the getBytes() method.
/**
* Returns the hash value of the given chars
*
* Uses the default hash algorithm described above
*
* #param in
* the byte[] to hash
* #return a byte[] of hashed values
*/
public static byte[] getHashedBytes(byte[] in)
{
MessageDigest msg;
try
{
msg = MessageDigest.getInstance(hashingAlgorithmUsed);
}
catch (NoSuchAlgorithmException e)
{
throw new AssertionError("Someone chose to use a hashing algorithm that doesn't exist. Epic fail, go change it in the Util file. SHA(1) or MD5");
}
msg.update(in);
return msg.digest();
}

No there is not. Even if you encrypt it, somebody will decompile the code that decrypts it.

You could make a separate properties file (outside the jar) for passwords (either direct DB password or or key passphrase) and not include that properties file with the distribution. Or you might be able to make the server only accept that login from a specific machine so that spoofing would be required.

In addition to encrypting the passwords as described above put any passwords in separate properties file and on deployment try to give this file the most locked down permissions possible.
For example, if your Application Server runs on Linux/Unix as root then make the password properties file owned by root with 400/-r-------- permissions.

Couldn't you have the app contact a server over https and download the password, after authenticating in some way of course?