September 6, 2016

Automated Code Inspection Tools for C Code

I recently had to draw up a list of C code automated inspection tools for a client.  It took me several hours to find and distill good reviews on the web so I thought I'd share it here for what's worth.  If I wind up using (or trying to use) any of the tools on the client's code base, I'll report my experience here.

This is a list of tools that, based on seven reviews I found, look like good candidates to run.  Since C has been around forever, some of the reviews are from as far back as 2009 and 2010.

# Recom­mendations
Web page / Notes

Open source
Last update: 2014
Open source
Last update: 2016
Open source
Last update: 2013
Open source & Commercial
Last update: 2014

Coverity (Synopsys)
Fortify Static Code Analyzer (SCA) (HP)

. o O o . 

September 3, 2016

The chicken and egg of password security

It's easy to argue that, because isn't a sensitive service, it's OK for users to pick insecure passwords.  But I suspect that this is a slippery slope: as a user uses more and more insecure passwords without anything bad happening, they become desensitized to security concerns (if they were ever sensitized in the first place) and move on to using such passwords on more and more sensitive services.  Eventually reality will bite them.

How can you blame uses for doing this?  They just want to use the services they like.  They aren't security experts and they don't understand the threat model or how dangerous the connected world is.

You can blame service providers that allow stupidly insecure passwords like "123456", "password", the name of the service, etc.  Microsoft disallows such passwords but the vast majority of service providers don't.

Now, a tougher question: can you blame service providers that allow passwords that are shorter than, say, 12 characters and not complex and random?  Anything less than that, as a bare minimum, is probably not secure enough against offline attacks.

But here's the chicken and egg:
  1. Since the vast majority of users don't use password managers, a service provider that required secure-enough passwords would likely be out of business in short order.
  2. If service providers don't require secure-enough passwords, why would users use them?  You can easily imagine the usability (and security issues) that such passwords would create for users that don't use a password manager.
  3. If users aren't forced to use secure-enough passwords, and given that they don't understand the need for unique passwords across all their services, why would they go to the trouble (they imagine) of using a password manager?  (That "trouble", by the way, is well worth it.)
As someone fascinated by security architecture -- and especially by how much better it could be -- this is the kind of problem I love to ponder.  My post Open Kimono Security presented one way to address this chicken-and-egg situation, but we might need something a bit more mainstream.


If you want to get a feel for password cracking time as a function of password length and complexity, try this:

Don't use a real password; instead compose a fake password that is similar to the password you want to test.  So if your password is "ChriSlove45" (don't laugh), use something like "CaseYbest92".  But then you probably already know that you shouldn't be using such passwords anyway: your passwords should all be long random (and unique) strings.

BTW, I suspect that the "MacBook Pro" times shown for that kind of password ("ChriSlove45", etc.) are wrong and should really be much shorter.

. o O o .