Tag Archives: security

Helpless police?

WSJ reports in an article “Police shoot, kill man near NYC Times Square” that a man was shot after a “slow speed pusuit” that lasted 7 blocks and lunging at a police officer with a knife.

What I personally find strange in this story is that the police could not take the knife away from a person allegedly smoking marijuana. He had the knife drawn from the beginning and was wildly swinging it around. Would it not be a part of the police training to know how to take a knife away from someone? Do they really have to shoot dead the guy? And there were many police officers there, mind you. What is next? Will they shoot people wielding sticks? I can tell you, a stick can be more dangerous than a gun if wielded properly.

Why is the police so helpless suddenly that they have to use firearms in a very basic situation? I do not feel comfortable with the police escalating the violence instead of using the techniques, training and their wits that they should have had about them.… -->

continue reading →

Why Do Nigerian Scammers Say They are From Nigeria?

A very interesting paper was published at Microsoft Research by Cormac Herley. It looks at the question “Why Do Nigerian Scammers Say They are From Nigeria?” and comes out with an unavoidable conclusion that that is by design.

Far-fetched tales ofWest African riches
strike most as comical. Our analysis suggests that is an
advantage to the attacker, not a disadvantage. Since
his attack has a low density of victims the Nigerian
scammer has an over-riding need to reduce false positives.
By sending an email that repels all but the most
gullible the scammer gets the most promising marks to
self-select, and tilts the true to false positive ratio in his
favor.

An interesting consequence of which is that even if only few people take the trouble to answer those scam letters but never actually go through with the money transfer, the Nigerian Scam would become prohibitively expensive to run.… -->

continue reading →

Holy Hash! Yahoo! keeps passwords in clear!

Washington Post reports on the Yahoo password database leak, the auditors say that Yahoo stores passwords in clear text. I am shocked.

I mean, how more silly can you get? We have been talking about not storing passwords in clear for, oh, I don’t know, ages now. Definitely long enough to expect that nobody in the right mind would do such nonsense any longer.

We do expect an occasional idiocy like the recent discovery that LinkedIn stores passwords hashed with a weak algorithm and not following the security recommendations. Fine, but just storing the passwords in clear is beyond such simple fallacy, this is almost like intentionally evil.

We know that sites get broken into. If a site has not been broken into, it is just a matter of time. And the more prominent sites are, of course, prime targets and should expect the break-ins like everyday business.

When the break-in occurs, the first thing attackers would go after are credit card numbers and other monetary assets. Next on the list are the password databases. And that’s why the passwords are never stored in plain, they are never encrypted, they are hashed. One-way hash, properly done, is a good way to keep passwords safe even when they get stolen.… -->

continue reading →

A security blog – to be or not to be?

I have been toying with the idea of starting a security blog for some time now. Today, again, was talking to my colleagues and at least one of them thinks it is a great idea.

I always look with horror at what passes as security “features” proposed to the people who just start writing websites. The frameworks are no better, they usually have a long outdated set of functions. Or some of them are defective by design. And there seems to be no place on the whole Internet to turn for help. You would not e-mail Bruce Schneier every time you need to make a password hash, would you?

So I think there must be a place where people can turn to for some information on how the proper security is built. How the user authentication should be set up, how the passwords are stored, what is a good and a bad implementation of “remember me” function and so on. Something has to be done to improve the security of all those start-up website coming online by the thousand every day. Even old companies, like LinkedIn and Citibank, get hacked because they do not do it right. The help on security must be provided somehow, somewhere.

Isn’t there such a  place already?… -->

continue reading →

Finding security bugs

Here is the matrix presented by Jacob West and Alexander Hoole from HP Fortify at RSA 2012. They look at security bugs along 2 different dimensions:

Explicit in Code Implied in Code Generic 50% – Can be found by static analysis tools Can be found in pen testing or expert reviews Application-Specific Need to understand application patterns and requirements – custom rules and manual reviews Probably can’t be found

These guys are in the business of finding bugs with tools. So we forgive them their optimistic estimates. But even they have to admit we can not find everything with tools. And even with expert reviews, there still remains something that is not easily discoverable…

These problems are not easy and they require actual understanding of both software design and security of software. So if you use unskilled development force in your software house, be prepared that half of the security problems will not be possible to discover, whatever tools you use.… -->

continue reading →

Software security by problem setting

We had an interesting discussion with a friend of mine yesterday. The discussion was about corporate communication, its failures and difficulties. Well, that’s his job. My job is security. And today I suddenly realized that everything we discussed yesterday about communication was equally applicable to my situation simply due to the human nature.

We try and push security into the company, into the development, into management, into everything. And it does not work. Some people say that it does not work as well as we would like it to but it works a little. I say it does not work at all. All this fake interest in something that can be done instead of working – that is not an interest in applying security. That’s not what we are after.

But the problem is the sane here as everywhere else. Why would anyone want to have security? Why would my CEO want security? He wants some certificate that he can wave around at public speaking occasions and get recognition and, even better, money for it. Why would developers want security? They want to listen to funny stories about security to have a legitimate excuse not to work. But they do not want to implement any security, that’s extra work for them that is not recognized in any way. Why would my customers want security? It’s cumbersome, and annoying, and costly…

So we are stuck in pretty much the same situation: I am trying to give people a solution to the problem they do not have. Or they think they do not have. People are notoriously bad at recognizing future problems and seeing the not-so-immediate outcomes. And that’s why I am failing before I started. They will not accept it because it is not their problem.

And the main million dollar question remains: how to make software security to be their very personal and immediate problem? If I can figure it out, then and only then we will finally have software security.… -->

continue reading →

Web security 0.1

I had thus silly idea to quickly throw together a website for myself to list up my motorbikes. Well, not “mine” per se, I do own only one, but the ones I have ridden over the years and have an opinion about. Since I like to do things “my way”, I searched for a rapid development framework instead of heading over to a motorcycle website. Silly me. But that’s besides the point.

I looked at the CakePHP framework and it appears a solid piece of engineering I could be happy with. The only problem is that I have been trying to get the user registration and login set up for the better part of two months now (I have a day job too).

There are plugins for doing user management and complete login and registration libraries but all that I looked at share one thing in common (and with CakePHP itself, too): they are written with a frightening disregard for security. Every single one of them. So much for Open Source and crowd-sourcing. I would not use any of them to manage my website. Period.

So, I embarked on a quest to write my own plugin for CakePHP that would demonstrate what you can do with the user sessions security if you really put your mind to it. I have a first draft running now, very simple actions only but it works. So I am confident that once I get my head around the concept of plugins in CakePHP I will be able to provide a plugin with far better security for user sessions.

Some points that come to mind when thinking what has to be done vs. what is usually done:

  1. The user identifier is usually predictable, allowing often for a user listing. It is either an auto-increment in the database, or a UUID. Neither is unpredictable. A random 64-bit value will be far better, even when the random generator is not all that great.
  2. The user name is the primary identification. This is, in my personal opinion, passe. The user ID is the e-mail address.
  3. The confirmation links (registration, password change) are silly MD5 hashes of the current time. I think, again, a 64-128 bit random will be so much better.
  4. Some send out a new password to the user in an e-mail. Instead of a random token. That is simply not to be done.
  5. The “remember me” cookie is usually implemented by sending a user name and a password hash to the user browser in a cookie. That is plain silly too. This, again, has to be a random token stored in your database and given to the user.

That’s what I come up with just off… -->

continue reading →

Social Engineering

The Dark Reading asked a rhetoric question recently: “When Will End Users Stop Being Fooled By Online Scams?” Well, you probably guessed the answer right away and it is “never”. I do not think it is possible to train the whole population of the planet in the intricacies of security. So the social engineering attacks in all of their variety are here to stay.

From this point of view, the “training” you get early in life matters, I think, quite a lot. I would hazard a guess that people who tried various social engineering tactics on their environment when they were kids are less gullible as a result. So we should not be so hard on our kids when we catch them lying and trying to trick others. Yes, they should know it is not acceptable. But they also should know how it is all done and kind of come to expect this trickery so they can distinguish social engineering attempts directed at them easier. So, do not punish them so hard, better teach them how to do it in a harmless way.… -->

continue reading →

Orwell’s rules in security

I came across the “six rules of English language” set forth by George Orwell in his essay “Politics and the English Language” in one of the posts on Jordan Bortz’s Software Architecture Blog. They are:

  1. Never use a metaphor, simile, or other figure of speech which you are used to seeing in print.
  2. Never use a long word where a short one will do.
  3. If it is possible to cut a word out, always cut it out.
  4. Never use the passive where you can use the active.
  5. Never use a foreign phrase, a scientific word, or a jargon word if you can think of an everyday English equivalent.
  6. Break any of these rules sooner than say anything outright barbarous.

These rules are absolutely essential for good system or application security. All too often we have the situation where the real target is to provide an insecure system and it is obfuscated by the use of this “political language”. To turn the words of Orwell to our subject, the great enemy of software security is insincerity. When there is a gap between one’s real and one’s declared aims, one does not get proper security.… -->

continue reading →