Opale – Les Champs Magnetiques

I caught this mesmerising teaser for a music video (directed by Nacho Guzman) over on BoingBoing the other day, and I guess I came for the video, but stayed for the music…

If you’re down with its dark, electronic vibe also, you can find the full track plus a longer remix version over on their SoundCloud page here: https://soundcloud.com/opaleopale.

Beautiful stuff.

How to: Ensure your Linux account passwords are strongly hashed

While reading around on how to break into Linux accounts the other day I stumbled across the interesting tidbit of information that the password hashes stored in the /etc/shadow file can be hashed using different methods, some more preferable than others.

Here’s an extract from my shadow file:


From looking at the information in man shadow, there are 9 fields in the following format:

  • Account name,
  • Password hash. A value of ! or * indicates the account cannot be logged in with, but may still be used by processes, and !! means the account has expired
  • Date of last password change (expressed as the number of days since Jan 1, 1970),
  • Minimum password age before change (minimum days before you can change the password),
  • Maximum password age before change (maximum days before you must change the password),
  • Password warning period (how many days before the password expires should the user be warned their password will expire soon),
  • Password inactivity period (the number of days an account may still change their password after expiry)
  • Account expiration date (expressed as the number of days since Jan 1, 1970), and finally,
  • A reserved field

So, taking the pulseaudio account pulse as an example, pulse:*:15089:0:99999:7::: means:

  • Account name = pulse,
  • Account may be used but cannot log in,
  • Password set 15089 days since 01/01/1970 (which will be around May 2011),
  • 0 days must elapse before password change,
  • 99999 days (so roughly 273 years) may elapse before password change,
  • 7 day password warning period,
  • No password inactivity period,
  • No account expiration date,
  • No data in the reserved field.

All fair enough – but now take another look at the test user account:


The password field has a stored password hash (which in this case is a SHA-512 hash of the phrase thisisstupid2) – and the first three characters are $6$. This is where the strong hashing comes in…

Choose Your Hashing Algorithm Wisely

There are a number of first-three-character combos which mean different things, and some are definitely better than others:

  • $1$ – password is hashed with MD5,
  • $2$ or $2a$ – password is hashed with a blowfish variant,
  • $5$ – password is hashed with 256 bit SHA-2 bit resulting in 32-byte output, and
  • $6$ – password is hashed with 512 bit SHA-2 resulting in 64-byte output.

MD5 is broken, by which I mean it can be manipulated to give the same hash for different sources. SHA-256 and SHA-512 on the other hand are significantly stronger and to the best of my knowledge do not currently have working attacks, so they’re definitely the way to go. There’s a great article on shadowed passwords by Aaron Toponce over at GuruLabs which will tell you pretty much anything you might want to know, and which can be found here.

Going back to my own experience with this, when I checked some accounts on my VPS (which runs this site) the other day, I found that some of the hashes started with $1$, so were hashed with MD5. The fix for this? Simply reset the password and the newer, stronger hashing algorithms will be used.

You can reset the password for any account by issuing the following command and then providing a new password:

passwd <account-name>

For example:

passwd root

After this, check your shadow file to ensure your hashes start with the desired prefix. Once they do your machine will be a little bit more secure, and it isn’t that much of an ordeal to achieve.


OpenGL – A Modified Phong-Blinn Light Model For Shadowed Areas

I was looking through the book Graphics Programming Methods (2003) the other day when I came across a paper titled “A Modified Phong-Blinn Light Model for Shadowed Areas” and thought it was pretty good, so I implemented it. It’s a really short paper, but what’s it’s basically saying is that by not allowing ambient light to be modified by geometry normals, any characteristics of the geometry are lost because we calculate the diffuse intensity as the dot product of the light location and the surface normal and limit the result between 0 and 1 (i.e. we only take diffuse lighting into consideration for surfaces facing our light source).

What the paper proposes instead is that we allow the dot product to run as -1.0 to +1.0, and when the value is within the range 0.0 to 1.0 (i.e. facing the light) we shade as usual, but when it’s -1.0 to 0.0 (facing away from the light) we calculate the lighting as the ambient light plus the negative diffuse intensity multiplied by the ambient light multiplied by q, where q is a value between 0.0 and 1.0. When q is 0.0, it’s like we’re using a traditional Phong-Blinn model, when it’s 1.0 we’re using the fully modified version, and any value in between is a sliding-scale combination of them.

To put that another way, if our surface is facing away from the light source, we use: Lighting = Ambient + (Diffuse * Ambient * q)

In the following images, the light source is roughly in line with the geometry on the Y and Z axis’, and is a way over on the positive X axis (i.e. to the right). Check out the difference…

Standard lighting with q = 0.0
Standard lighting with q = 0.0 - notice that the inside right area of the torus is getting no diffuse lighting, and all detail is lost to the ambient lighting.
Improved lighting with q = 0.5
Improved lighting with q = 0.5 - there's now some detail in the shadowed area on the inside-right of the torus
Improved lighting with q = 1.0
Improved lighting with q = 1.0 - there's now significantly more detail in the shadowed area on the inside-right of the torus

To create this effect, I used the following fragment shader:

Modified Phong-Blinn Light Model Fragment Shader

#version 330
// Uniforms
uniform vec4 ambientColour;
uniform vec4 diffuseColour;
uniform vec4 specularColour;
uniform sampler2D colourMap;
uniform sampler2D normalMap;
uniform float qUniform; // A value to manipulate our lighting by when surface is facing away from light source
// Input from our vertex shader
smooth in vec3 vVaryingNormal;
smooth in vec3 vVaryingLightDir;
smooth in vec2 vTexCoords;
// Output fragments
out vec4 vFragColour;
void main(void)
	const float maxVariance = 2.0; // Mess around with this value to increase/decrease Normal pertubation
	const float minVariance = maxVariance / 2.0;
	// Create a normal which is our standard normal + the normal map perturbation (which is going to be either positive or negative)
	vec3 normalAdjusted = vVaryingNormal + normalize(texture2D(normalMap, vTexCoords.st).rgb * maxVariance - minVariance);
	// Get our diffuse intensity as a dot product which is NOT limited 0..1
	float diffuseIntensity = dot(normalize(normalAdjusted), normalize(vVaryingLightDir)); 
	vec3 colour = vec3(0.0);
	// If the surface is facing the light then shade as normal
	if (diffuseIntensity > 0.0)
		colour = (diffuseIntensity * diffuseColour.rgb) * texture2D(colourMap, vTexCoords.st).rgb + ambientColour.rgb;
	else // Otherwise use the modified light model
		colour = (diffuseIntensity * diffuseColour.rgb * ambientColour.rgb * qUniform) + ambientColour.rgb;
	// Set the almost final output color as a vec4 - only specular to go
	vFragColour = vec4(colour, 1.0);
	// Specular light
	vec3 vReflection        = normalize(reflect(-normalize(normalAdjusted), normalize(vVaryingLightDir)));
	float specularIntensity = max(0.0, dot(normalize(normalAdjusted), vReflection));
	// Add in specular component
	if (diffuseIntensity > 0.0)
		float fSpec = pow(specularIntensity, 64.0);
		vFragColour.rgb += vec3(fSpec * specularColour.rgb);

Credits for this method go to Anders Hast, Tony Barrera, and Ewer Bengtsson – good work, fellas! =D