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 →

Jacek Lipski – a LinkedIn spammer

I am usually not one to indulge in public bashing of people even when they obviously misbehave but this time I am somewhat annoyed. This guy, Jacek Lipski, indulges in spamming the LinkedIn members in a very irritating manner and tops it off with a ‘fuck you’ attitude. So he deserves a mention for the annals of history.

So, here is the story. LinkedIn is a rather well behaved community. It is mostly for talking about work and business related things, at least that’s the perception, kept up by the service. Therefore you do not expect someone to send you a “friend invite” in order to peddle his wares. Well, not Jacek Lipski.

You see, Jacek Lipski has some kind of a company that he wants to sell but there are no buyers, understandably. So what does the guy do? He sends you an invite on LinkedIn. You think, “well, all right, he maybe wants to talk about my interests in security or just follow what I do” and you accept. And here you get hit with an offer to buy his stupid company.

I complained right back saying that this was not a good behavior, in my opinion. The answer I got back is as close to “fuck off” as one can get:

I am not interested in your private feelings.

Let me explain by analogy. You have an old rusty Chevy from your grandfather that noone in his right mind would even look at. So you come to people in the street and beg them to buy it. They rightly tell you off. And what do you do in return? You tell them to fuck off, of course! That’s same here, only Jacek Lipski is apparently not afraid to get punched in the face.

Well, tell you what. Maybe one day one of his victims will come across him in real life…… -->

continue reading →

Back to square one

I am officially announcing that the idea to write in two places just because of the language difference was a stupid one. So we are back to the square one blog and I hope having a multilingual blog makes it all the more exciting. Who wants to bet that I will now start writing in all the other languages I know as well? どうですか?:)… -->

continue reading →

Google quality

Am I the only one who noticed that the quality of service at Google suddenly took a nosedive? I mean, it still works, sort of, most of the time, but it is not quite the same.

Google used to be very snappy and the interface was very crisp. All elements worked flawlessly and the response was immediate. Now it is all starting to fray at the fringes. It is not so snappy, the code is not that crisp, it fails more often than not and you spend entirely too much time waiting.

I say they are probably loosing good engineers and replace them with cheap ones, like everyone else. It shows.… -->

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 →

CakePHP: plugins models

I spent two days trying to trace why the plugin I am writing did not work. Eventually I realized that the files defining the models were not loaded at all. After several hours trying to figure this out I came across this explanation provided by zuha-3:

My bet is that you don’t have a plugin defined somewhere. I had the same problem in a couple of places after the upgrade because I had forgotten to name which plugin the model could be found in.


belongsTo = array(
className = [PLUGIN].[MODEL]

instead of...

belongsTo = array(
className = [MODEL]

And this goes for all relationships, and you might have just missed one.

And so finally it worked. This should be like written in really large letters on the page that talks about plugins in CakePHP documentation. Two days for this simple stupid thing…… -->

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 →

Software design – separation of concern

Still, the separation of concern is as actual as it always was. Consider this website design thing. You still have to separate the concerns between the user management and the website content management. These are totally different concerns. And they have different priorities too.

When you manage the content in your application you basically do not care about users at all. You care only to know whether the requester has the right to see (or modify, whatever) this particular content. So you need some kind of identifier as an input to the authorization management, which is another concern. You really do not need any details of the user that is usually kept by the user management.

While you are in the user management, creation, registration, modification, verification etc. require full knowledge of the user details. So you need to have different data on users here.

What happens is that you really need to have two different concepts of users: one for your user management subsystem and one for your website content management subsystem. And those have little in common. Plus, the website content management requires such user information (besides being useful) that can be quickly retrieved and add minimal overhead. On top of that, user information in both must be kept in sync.

Finally, one comes to realize that the database views are invented precisely for this particular problem. So we can have the same user data underneath but present two different views of that same data to the two subsystems of our web application.… -->

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 →