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
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 →
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 →
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 →
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 →
Ну что тут можно сказать, сегодня день богат на идиотизм. В частности, Дума одобрила создание реестра запрещенных сайтов и провайдеры должны будут блокировать доступ к сайтам, попадающим в реестр.
Ну что тут можно сказать? Бедные провайдеры, вот не было им печали. А цензура на интернете – это ж дело такое, они не первые и наверняка не последние. Всё равно это занятие по большей части бессмысленное. Фильтровать реально сайты у них не получится, а мозгопромывательством заниматься можно и с помощью других, более эффективных, методов. Так что смысла ну вообще никакого.… -->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 →
Mozilla сегодня объявила о планах запустить «новую полностью открытую мобильную экосистему на основе HTML5». Ура! Они делают мобильник на основе Фаерфокса! Правда, дат там никаких не сообщается, но я надеюсь, они все-таки это сделают, и скоро. Я – уже в очереди :) Даешь мобильник от Мозиллы!… -->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 →
This is totally brilliant. I came across this marvel somewhere and adapted to my application. See, if you have a hasMany relation, you end up with (1) an extra query and (2) with a lot of data. I have a case where I just need the last (time of creation) row. So I basically want to bind that model in a hasOne relation where the one row is determined by an expression selecting a single row.… -->continue reading →