I'm a brazilian, and on our big cities we have a type of crime known as flash kidnap ("sequestro relâmpago" in portuguese), which is a crime that consists in one kidnapper taking a hostage and cruising around with him (probably on the hostage's own car) and forcing the victim to release his banking account numbers so money can be drawn from his banking account.

This type of crime is basically a problem that was induced by the introduction of a technology (bank credit cards). But this technology could be made safer by the introduction of an emergency number. This number would work just as the normal one, so there is plausible deniability for the victim, so money could be drawn and all, but if ever used it would raise alarms on the credit central, and the authorities could be immediately called. Since close to 100% of the ATM machines have cameras around them, and there is the location of the drawn, it would be easy to check where criminals are.

For example:

Bob uses a banking card and has 2 passwords (pass A and pass B). Bob uses pass A on his day-to-day, without a hassle. Some day Eve kidnaps Bob, and forces him do release his card and a password. Bob releases pass B. Eve uses Bob's card with pass B without a problem, but doing so warns Alice that there is an emergency happening with Bob (possibly a kidnap). Alice warns the authorities.

I'm not interested in making money at all with this idea, but I would like to see it implemented, so it perhaps could save some property and lifes, so I'm asking for some directions as to what the heck I should do with it, and also some criticism.

This idea is registered under CC Attribution-Noncommercial 2.5 Brazil

Hi Sirs.

An important trick on the famous ActiveRecord::Base find method.

When you are in development time of your application, and you do some query on your database query editor, is a good practice to use the limit clauses and selects just the columns you want.

In the find method we can do it with the :limit and :select arguments.

For example in our code when we try to authenticate some user we got it like:

find(:first, :conditions => [query, hash], :select => "id, email, login")

The returned object contains just the id, email and login attributes. Clean object.

Password and other attributes do not appears in the returned object =]

Simple development practice, but very important too.

See you.

I've been reading a great paper by Daniel J. Bernstein, the creator of a qmail, and wow, what a pearl of wisdom. One of the most clarifying and straight to the point works on code security I have ever read. He (quite correctly) makes a parallel between the code security and the amount on exploitable bugs (EB), stating that it is the major problem on the code, regarding security. And then gives some answers to that problem, along with a couple of common distractions of the programmer while coding that helps those EB creep on our code base (CB). Let's review then, starting with the distractions, and I'll try to make some links with my favorite unambiguous tool of choice, Ruby.

1. Chasing attackers. The point here is give some thought to respond to tomorrow's attacks, and not being trapped by the anti-virus mentality of being only responsive to aggressors. Perhaps the dynamic nature of Ruby would help with that, but I think it is more a personal posture problem than anything else.
2. Minimizing privilege. Here, what is being said is that the old principle of least privilege is fundamentally wrong. How so? Well, it might (!) reduce the damage done by security holes, but never fixes these. Plus, IMO, it might even give users a false sense of security. Again, it is more of a way of a personal way of thinking (but what isn't? :P ).
3. Speed, speed, speed. Here I think rubists have some advantage. Since we work on a language that is 'slow', usually we tend to not place emphasis on premature optimization. I think this quote summarizes the thinking here:

   Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time; premature optimization is the root of all evil. —Knuth in [13, page 268]

Now, to the answers. These are also 3, and they are codependent connected to each other:

1. Eliminating bugs. I think everyone saw that one coming. But even so, Daniel's down to earth advices on it are a very worthwhile reading. I think I can summarize him on this section by saying (and that is a plus to rubists too), simplify stuff. Simplify interfaces, UI, parsing. Elegance is not a luxury, it is a way to obtain security. Following that logic we come to.
2. Eliminating code. Heck, here I'll quote his quote, and be done with it.

   To this very day, idiot software managers measure 'programmer productivity' in terms of 'lines of code produced,' whereas the notion of 'lines of code spent' is much more appropriate. —Dijkstra in [9, page EWD962–4]

   But as our systems grow, and our time and budgets remain the same or are diminished, and as programmers get more dumb, something has to give right? Wrong (don't know about the last part though).
3. Eliminating trusted code. That is somewhat more difficult I think, but it says that a program should do what it is meant to do, nothing more, and trust as few sources of data as possible. KISS and all that stuff.

I would love to hear any input on that. Until next time people.

Hi Sirs,

a very important thing that I can remember about security on web environment is 'logs'.

Ruby on Rails provide a very simple way to protect us of store sensitive information on the logs. Every information that goes through the parameters is writed on the log. In websystem development phasis logging information is important, but in the production phasis, is dangerous. Hackers in general can take information through many ways. Our tip to protect sensitive information in the logs is the method 'filter_parameter_logging' of the Class ActionController::Base.

ActionController is the mother class of every controller in your applications, so the best place to call it is in the app/controllers/application.rb.

Just insert this example line of code:

filter_parameter_logging :password, :password_confirmation

and than it replaces the values of all keys that matches the arguments name with "[FILTERED]", and you are protecting your informations in the logs.

Is a simple tip, but very important. Do not forgot to use it.

See you.