Category Archives: videos

Don’t be lazy with P4ssw0rd$

Three challenges to making passwords user-friendly

Following the interview of Bill Burr, author of NIST’s 2003 paper on Electronic Authentication, in which he announced that he regrets much of what he wrote, we stop and think.

Why was the standard putting users at risk? Paraphrasing History: “Tout pour le peuple; rien par le peuple”. Perfectly correct from a theoretical point of view, the standard failed to acknowledge that users are indeed people, and when asked to follow too complex rules they will find “tricks” to help themselves to remember their current nightmarish password. Of course, said tricks are fairly easy to guess by any decent hacker, let alone an educated computer.

Nothing new here, the user is often and unfairly considered as the problem. But since there is no easy way to fix the user, it is up to us, as security and IT professionals, to design and build our systems to make them more resilient to human mistakes, and maybe some laziness.

Screen Shot 2017-08-28 at 09.36.42

Difficult for you, easy for a computer : passwords haven’t been what they should.


Ah, those funny stories on predictable passwords

The problem with the previous standard wasn’t that it was advising people to make easy to crack passwords, but that too complex rules steered users towards the path of least resistance: very complex and very predictable passwords.

I remember working in a team where, by knowing how long one of your colleagues had been around, you could easily guess their password, applying the simple rule of Company_nn, where nn was the number of the rotation of the password.

So, what now ?
Three challenges to making passwords user friendly

The new NIST 800-63 special publication, and previous publications such as GCHQ’s NSCS guidance, turns the approach upside down: make your password policy user friendly and you’ll get better security. A simple idea: put the burden as much as possible on the verifier, not the user. With one dream: create security that works no matter what the people do. Is it all that easy ? Let’s look at three recurrent challenges we’ve encountered at our clients:

1. Make it hard to guess with blacklist check

What is this about?
Forget complexity and just make sure you don’t use a word from the dictionary, a known first or last name, or a commonly used password (based on public lists of breached passwords). Now, this is easier than done.

Why is it a challenge?
While quality password blacklists can be found online, neither the blacklist validation mechanism nor the integration with frequently updated blacklists is proposed in most systems and applications on the market. Azure AD, for example, has offered this functionality for only a year, and its scope remains limited. And then, most organizations use a local AD. Or something else that doesn’t have such a native password validation check.

So what ?
There are workarounds of course, but they’re not always robust and imply manual maintenance of a blacklist – an effort many organizations are reluctant to commit to. It will be interesting to see how the market catches up on this one. Until then, well, most system admin prefer to keep some complexity requirements on.

2. Make it easy to remember by promoting the use of passphrases

What is this about?
Lengthy passwords, such as passphrases, are much more likely to integrate human randomness: easy to remember, yet almost impossible for an automated system to make sense of when properly done. As usual, xkcd got it right.

Why is it a challenge ?
While passphrases are a simplification on paper, especially if complexity requirements are dropped, they’re also a new paradigm for most end-user. Let’s face it: 24 characters password sound scary and users are clearly reluctant to commit to this. We’ve tested this on a few friends: after some enthusiastic explanation from our part, they agreed to switch.
For the first few days, our names were accompanied with words that weren’t exactly kind. After a week, the cursing had disappeared and they got used to typing long passwords, often several times to get it right. With locked out increasingly replaced by password throttling, frustration was luckily enough not turned into user being locked out.
But only a few passwords were changed: replacing all passwords in use meant inventing tens of completely new password, based on a completely new reasoning.

So what ?
This tells us that Awareness and communication is needed to make mentality evolve. Maybe re-using some of the good Belgian material of our friends at Even like that, you may wish to focus your effort on one specific password – typically, their Windows password.
But this also tells us that users should only have to remember 4 or 5 passwords: the rest should be in a password vault. Here too, it’s about changing users habit. And again, this works fine until you want to connect from another device than the one hosting the vault. Who said Cloud? But that’s another debate.

3. If it’s still a secret, why change it?

What is this about ?
NIST has gone bold on the advice: only change password if you think (or know) it’s compromised. Don’t have them recurrently expire, this is exactly how passwords become predictable. Of course, this only works if other NIST recommendations are implemented, especially increased length and blacklist check.

What’s the challenge ?
It’s like Perfect Information of consumers in economics: in theory, we should all know everything. But look around and you’ll see it may take months or years to find out your users’ passwords were stolen – not to mention they might have been using that password all over the internet.

So what ?
The best friend of “no expiration” is “second factor”, making sure the memorized secret alone won’t let them in. Of course, with cost of these things and their inherent complexity, you’ll probably select risk-based on which layers and Apps you want to implement it – or even better, go for a common authentication portal that supports adaptive authentication.

What does this all tell us, then ?

That the world is moving to user-friendly security, at last. And the best part is: it’s doing it because old security didn’t work. But it also tells us that these things will be complex to implement, because systems are not ready, implementation will prove complex, and users have to unlearn what we’ve spent the last 20 years pushing into their brains.

This is essentially what our colleague Benoit said on TV a few weeks ago, in case you missed it, you can watch it here.



Tracking threat actors through .LNK files

In the blog post .LNK downloader and bitsadmin.exe in malicious Office document we were asked the following question by Harlan Carvey:

Did you parse the LNK file for things such as embedded MAC address, NetBIOS system name, any SID, and volume serial number?

We did not do that at the time, however we see the value in this to track specific threat actors throughout different campaigns.

The Windows .LNK file format contains valuable and information that is specific for the host on which that .LNK file has been created including:

  • The MAC address of the host;
  • The NetBIOS system name;
  • the volume serial number.

This is all information that will not easily be changed on the threat actors workstation and which should be fairly unique.

For more information on the .LNK file format, take a look at the following ForensicWiki page:

I used the tool lnkanalyser from woanware to analyse the extracted .LNK file.


Now what information are we seeing here.

NOTE: this tool does not show the relative path, on other .LNK files we tested this was shown. This particular .LNK file’s relative path refers to cmd.exe in the C:\Windows\System32 folder.

The first thing that stands out is the argument, this is everything that is passed on to command line, this has been discussed in the the blog post .LNK downloader and bitsadmin.exe in malicious Office document.

Next interesting item is the Target Metadata. The timestamps shown here are the timestamps of the target executable, in this case cmd.exe, of the executable on the system of the person creating this .LNK file.

Concluding we have four artefacts tied to the workstation on which this .LNK was created that can be used to track a threat actor:

  • Hard disk Serial number: 60BDBF2D
  • Volume ID: C2CC139818B9E241824054A8ADE20A9A
  • Machine ID: 123-¯ª
  • Mac address: 00:0C:29:5A:39:04


Didier Stevens created a comprehensive screencap on how to extract the .LNK file from the Word document and analyze it with lnkanalyzer.exe:


For an extensive explanation of .LNK file attributes, we’d like to refer you to the following research: