Stob at The Reg shares the latest of word on the buzziness of buzzwords:
(1.0 best, -1.0 worst)
design by contract
unit test (as noun)
unit test (as verb)
Incidentally, one of the latest BOFH is about jargon too. So, am I not the only one tired of jargon?… --> continue reading →
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 →
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 →
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
50% – Can be found by static analysis tools
Can be found in pen testing or expert reviews
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 →
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]
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 →
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 →
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 →
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:
- 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.
- The user name is the primary identification. This is, in my personal opinion, passe. The user ID is the e-mail address.
- 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.
- 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.
- 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 →
That is really something we come across almost every single day – the initiatives and ideas that seemed so good backfire and destroy all they were supposed to improve. One of those things is Agile in software development.
The idea originally was fairly trivial but seemed to have potential to work. The idea was to be able to split the software development into smaller chunks so that even an idiot would be able to write that small piece of code. Then, a company would not need to hire experienced software developments but could settle for inexperienced, inadequately trained and simply stupid developers, often without an engineering degree. That would allow to pay less for the same amount of software produced.
The result? A catastrophic loss of productivity ensues. Yes, it is cheap to get the software developers and make them scrum masters but what then? They are not capable of developing the software anyway. And you drove away all real masters of design already. The amount of time required to write and rewrite all the code and tests shoots through the roof. The productivity falls through the floor. Costs … you guess it.
Software design (as many other engineering disciplines) remains an art to this day. Yes, you can apply agile principles in some dark corners of software development but far from everywhere. And that is something managers still have to understand.… --> continue reading →
Something is definitely wrong with the object-oriented software design. Did you notice? I forces the hierarchical view of, basically, anything onto the designer. This is equally a property of the languages and the design methods. If you make object-oriented design or you write object-oriented software you equally end up with a hierarchical system.
What’s wrong with it? Maybe nothing. It just severely limits the view of the problems that we attempt to resolve with our software. The world is not always hierarchical but we try always to drag it kicking and screaming into our unified model. Sometimes that will fail. Actually, given the variety of problems, probably even most of the time it will fail.
And the important thing is that we do not notice this anymore. We think in limiting ways. We are used to the model. We assume the model of object-oriented design will fit anything and everything without ever thinking about it. Unconsciously, we made the decision to narrow our choices. And that is definitely wrong.… --> continue reading →