password

Easy String Encryption With Bouncy Castle and Jasypt

Posted on

At times you want a an easy and straightforward way to encrypt strings without the hassle of undocumented cryptographic libraries *cough* bouncy castle *cough*. This is where Jasypt comes in. It is a powerful encryption library that makes cryptography fun and easy! What makes Jasypt nice is that it can perform simple encryption using passwords very quickly. That is quickly in terms of development time.

Below is a simple example of using Jasypt to encrypt a string using BouncyCastle as the provider.

PooledPBEStringEncryptor encryptor = new PooledPBEStringEncryptor();
encryptor.setProviderName("BC");
encryptor.setAlgorithm("PBEWITHSHA256AND256BITAES-CBC-BC");
encryptor.setPoolSize(4);
encryptor.setSaltGenerator(new RandomSaltGenerator());
encryptor.setKeyObtentionIterations(100000);
encryptor.setPasswordCharArray("BadAssPassword12345!".toCharArray());
		
String crypted = encryptor.encrypt("Hello World!");
System.out.println(crypted);
		
String plain = encryptor.decrypt(crypted);
System.out.println(plain);

The above code should work, but you will need to download Jasypt and BouncyCastle libraries and set them on your classpath.

U.S. Nuke Silos Protected by Stupid All Zero Password

Posted on

The tile of this post says it all.

Please visit For Nearly Two Decades the Nuclear Launch Code at all Minuteman Silos in the United States Was 00000000 for more details.

I just cannot be bothered to write more about it, I hope they change it. I hope the Russians didn’t do anything this stupid as well.

Password Validation Practices

Posted on

It is usually quite rare for me to stumble upon some really bad code, but to stumble upon some really stupid code… well that happens almost everyday!

So while auditing someone else’s source code at work I found something very odd in the utility that validates passwords against our policy. We have a standard password policy that only allows passwords to be at least 8 characters in length, 1 upper case, 1 lower case, 1 digit or 1 special character and no spaces. The code that is used to validate this policy is what really blew my mind. I mean, it’s not that it does not work, it does. It’s that I could not comprehend how the code was brought to life by a "senior" developer with a university degree in computer engineering.

The source code is in Java so there are many options to use like regular expressions. So the the function to validate a password against the password policy would look something like this:

/**
 * <p>Standard Password Policy
 * <ul>
 * 	<li>Minimum 8 characters</li>
 * 	<li>At least 1 upper case character</li>
 * 	<li>At least 1 lower case character</li>
 * 	<li>At least 1 digit or 1 special character</li>
 * 	<li>No spaces allowed</li>
 * 	<li>List of special characters allowed are (!@#$%^&+=.,_)</li>
 * </ul>
 * </p>
 */
private static final String PASSWORD_REGEX = "^(?=.*[a-z])(?=.*[A-Z])((?=.*[!@#$%^&+=.,_])|(?=.*[0-9]))(?=[^ ]+$).{8,}$";
private static final Pattern passPattern = Pattern.compile(PASSWORD_REGEX);
	
private boolean validatePasswordRegex(String password)
{
	return passPattern.matcher(password).matches();
}

It’s lean, clean and simple. Then I started to think that what if someone did not know anything about regular expressions (which if they did not they should have found out about by googling "password validation") So I felt compelled to re-write a function that validates the password without using regular expressions:

private boolean validatePasswordFast(String password)
{
	boolean hasUpper = false;
	boolean hasLower = false;
	boolean hasSpecial = false;
	boolean hasDigit = false;
	boolean valid = false;
		
	if(password.length() > 7) {
		char[] cPassword = password.toCharArray();
		for(int i = 0; i < cPassword.length; i++) {
			int c = cPassword[i];
				
			if(c == 32) {
				valid = false;
				break;
			}
				
			if(!hasUpper) {
				if(c >= 65 && c <= 90) {
					hasUpper = true;
				}
			}
				
			if(!hasLower) {
				if(c >= 97 && c <= 122) {
					hasLower = true;
				}
			}
				
			if(!hasDigit) {
				if(c >= 48 && c <= 57) {
					hasDigit = true;
				}
			}
				
			if(!hasSpecial) {
				switch(c)
				{
					case 33:
					case 35:
					case 36:
					case 37:
					case 38:
					case 43:
					case 44:
					case 46:
					case 61:
					case 94:
					case 95:
					{
						hasSpecial = true;
						break;
					}
				}
			}
				
			if(hasUpper && hasLower && (hasSpecial || hasDigit)) {
				valid = true;
				break;
			}
		}
	}
	
	return valid;
}

The above is relatively longer than the regular expression function. Knowing that each character in a String has an ordinal number and knowing of the ASCII table it was intuitive on how apply the password policy. Also I tried to make it as efficient as possible so that there are no wasted iterations.

But, dear readers, what I found was worse. I saw something so wasteful and so … "un-computer science like" that it baffled me:

private boolean validatePasswordNotSmart(String password)
{
	boolean passwdLength =true;
	boolean passwdSpace = true;
	boolean passwdSpecialChar = false;
	boolean passwdLowerCase = false;
	boolean passwdUpperCase = false;
	boolean passwdDigit = false;
		
	if(password == null || password.length() == 0) {
		return false;
	}
		
	if(password.length() < 8) {
		passwdLength = false;
	}
			
	for(int i = 0; i < password.length(); i++) {
		if (password.contains(" ")) {
			passwdSpace = false;
			break;
		}
			
		if(password.contains("$")
		   || password.contains("+")
		   || password.contains("=")
		   || password.contains("!")
		   || password.contains("#")
		   || password.contains("%")
		   || password.contains("&")
		   || password.contains("^")
		   || password.contains("@")
		   || password.contains(".")
		   || password.contains(",")
		   || password.contains("_")) {
			passwdSpecialChar = true;
		}
			
		if(password.contains("a")
		   || password.contains("b")
		   || password.contains("c")
		   || password.contains("d")
		   || password.contains("e")
		   || password.contains("f")
		   || password.contains("g")
		   || password.contains("h")
		   || password.contains("i")
		   || password.contains("j")
		   || password.contains("k")
		   || password.contains("l")
		   || password.contains("m")
		   || password.contains("n")
		   || password.contains("o")
		   || password.contains("p")
		   || password.contains("q")
		   || password.contains("r")
		   || password.contains("s")
		   || password.contains("t")
		   || password.contains("u")
		   || password.contains("v")
		   || password.contains("w")
		   || password.contains("x")
		   || password.contains("y")
		   || password.contains("z")) {
			passwdLowerCase = true;
		}
			
		if(password.contains("A")
		   || password.contains("B")
		   || password.contains("C")
		   || password.contains("D")
		   || password.contains("E")
		   || password.contains("F")
		   || password.contains("G")
		   || password.contains("H")
		   || password.contains("I")
		   || password.contains("J")
		   || password.contains("K")
		   || password.contains("L")
		   || password.contains("M")
		   || password.contains("N")
		   || password.contains("O")
		   || password.contains("P")
		   || password.contains("Q")
		   || password.contains("R")
		   || password.contains("S")
		   || password.contains("T")
		   || password.contains("U")
		   || password.contains("V")
		   || password.contains("W")
		   || password.contains("X")
		   || password.contains("Y")
		   || password.contains("Z")) {
			passwdUpperCase = true;
		}
			
		if(password.contains("0")
		   || password.contains("1")
		   || password.contains("2")
		   || password.contains("3")
		   || password.contains("4")
		   || password.contains("5")
		   || password.contains("6")
		   || password.contains("7")
		   || password.contains("8")
		   || password.contains("9")) {
			passwdDigit = true;
		}
	}

	return passwdLength && passwdSpace && (passwdSpecialChar || passwdDigit) && passwdLowerCase && passwdUpperCase;
}

How does one go through all the trouble to write that function and roll it out into production believing that what they did was good? The problems with this are that

  • Long to write
  • Uses many internal methods that affect performance
  • Shows the lack of research into the topic
  • Waste of time

I even tried bench-marking the three functions to see which was fastest:

Password to benchmark: ThisIs_A_validPassword123!
Iterations: 500,000
Validate Password Not Smart: 5491 ms
Validate Password Fast: 63 ms
Validate Password Regex: 2340 ms

Go for another round...

Password to benchmark: ThisIs_A_validPassword123!
Iterations: 500,000
Validate Password Not Smart: 5461 ms
Validate Password Fast: 48 ms
Validate Password Regex: 2356 ms

The non-regex but fast function triumphed at less than 100ms to validate a password 500,000 times. Second place was the regex function averaging at 2,300ms and last place was the not smart function which took a whopping 5,400ms.

The advantages of the regex function is that it is short to write and easy to read, but you have to have intermediate knowledge of regular expressions. The fast function is fast, but it’s a bit long and you have to scan the code a bit to figure out what it is doing. Not to leave anything out, the not smart function is the easiest to read, but sadly causing you to come to the conclusion that this is the wrong way to code it.

WhatsApp is WhatSucks

Posted on Updated on

One of the most popular cross-platform mobile application used as a replacement for messaging and sharing multimedia is under scrutiny of being insecure. Yes, we are talking about none other than WhatsApp. Now we have seen previous instances of idiocy here but the victims there are mostly financial institutions and their reputation, which not a lot of people really care about.

It has been reported by Sam Granger that WhatsApp on Android uses your phone IMEI to generate its passwords:

md5(strrev(‘your-imei-goes-here’))

Then a little later it seems WhatsApp did something about it! By reading the comments section of Sam Granger’s blog it seems it no longer works. Yeah… WhatsApp actually did something about it! Great… but hold your excitement it seems that everything is not what it seems.

Recently reported by Ezio Amodio that WhatsApp on iOS is back up to their old password trickery again. This time they are using the iPhone’s MAC address to generate the password like so:

md5(AA:BB:CC:DD:EE:FFAA:BB:CC:DD:EE:FF)

Our dear friends at H-Online have verified the blog post and well just being on H-Online is something important.

So what sucks about WhatsApp ? Their security, your privacy and their embarrassment.

UPDATE
Commenter posted a link to pastebin with the most curious title Reverse Engineering: How WhatsApp (not) Securing Your Data It’s a great read and there are George Carlin references too! Can’t get better than that, cryptography, sarcasm, George Carlin and nifty rev-engineering.