Posted by Jonas Elfström
Tue, 30 Dec 2008 23:29:00 GMT
The incident I wrote of in Hello this is special agent Brian were covered in a Swedish radio documentary a little more than a month ago.
It's all in Swedish. You can find out more here and you can download the documentary from here.
I also would like to add that we did not press charges like the police officers says 37 minutes into the documentary. Not because we thought it wasn't a big deal but we knew that a couple of big players already had so we thought we could spend our time better.
Posted in Security | no comments
Posted by Jonas Elfström
Mon, 11 Feb 2008 23:26:00 GMT
In a recent release TrueCrypt now supports drive/partition encryption.
One reason to encrypt on disk instead of file level is that operating systems and applications sometimes accidently stores passwords on your hard drive. This can happen in a number of ways and one common mistake applications make is to not prevent to be put on disk by the OS. Modern systems have a page/swap file. If a program gets paged out while holding your clear text password in pageable memory your password will be written to disk. The problem is that there are password recovery tools that can scan your page file for passwords.
You can configure Windows (and surely most other operating systems) to clear the page file on shutdown which will give you better protection (and slower shutdowns). Be aware that if you simply turn off the power the page file will be intact.
Posted in Security | 2 comments
Posted by Jonas Elfström
Wed, 12 Dec 2007 16:15:00 GMT
I recently attended a session held by Marcus Murray. It seems it was kind of a compressed version of the session he held at TechEd earlier this year. Murray is witty, charismatic and has a broad and deep understanding of IT-security issues. He cracks jokes and practices a little social engineering to keep the audience attentive.
If you and your IT-staff wants to be briefed (and scared) with the latest in IT-security I could easily recommend Murray.
He demonstrated a couple of tools that both impressed and scared me. First he demonstrated how to set up a mail based attack using the commercial Core IMPACT. It's a very impressive tool and mail based attacks are only one out of many attacks this software has the ability to execute. Before seeing this I could never have guessed there are tools this advanced and this easy to use. The lists of exploits it can test, in an all automated fashion, were long and seemed to be up to date.
Murray also demonstrated ARP poisoning and hijacking of a RDP session by using the free Cain & Abel tool. You could feel the discomfort in the air as it dawned on the audience how easy this is to set up.
Posted in Security | no comments
Posted by Jonas Elfström
Mon, 26 Nov 2007 20:40:00 GMT
There's some buzz about a new trojan technique called "Man in the browser". The trojan plugs itself into the users browser and then it intercepts the HTML. This have all sorts of implications, for instance the SSL certificate will seem to be valid.
Even if your virus protection does not detect the "Man in the browser" there are still ways to be quite safe. If your bank uses a security token which you not only logs in with but also use to sign your transactions, the attack will most likely fail. One problem is that it is up to you, the user, to actually verify that you are signing the expected amount to the expected accounts. To get protection against someone who has complete control over your computer the security protocol must "communicate" with the security token both ways.
It is not enough to only let the user enter the total value of the transactions because the tokens answer to such a simple value could be reused (during a short period of time) also the attack could be crafted to create the correct amount but to other accounts. By asking the user to also sign every new account the attacker will not be able to hide a transaction to his account.
The challenge is to make the security protocol clear and simple enough so that the user can understand what he would expect the bank to respond and expect from him.
It's the usual three: have a firewall, an updated virus protection and a secure bank with a digital security token were you sign your transactions and maybe you can sleep a little better.
Posted in Security | no comments
Posted by Jonas Elfström
Thu, 15 Nov 2007 21:38:00 GMT
Sometimes you do not want to show the database id for a row in the URL. The reason could be that you do not want someone to be able to scan through all the data.
One solution is to use GUID's but they have drawbacks and one of them is that they add a considerable length to the URL. The shortest URL-safe representation of a GUID I've seen is 22 characters but usually they are 36 characters.
Depending on how your id's are implemented a much shorter way could be to simply to encrypt them.
Here's a Ruby-example that Blowfish encrypts, Base64 encodes and URL-encodes an integer value. You can get crypt as a gem:
gem install crypt
require 'rubygems'
require 'crypt/blowfish'
require 'Base64'
blowfish = Crypt::Blowfish.new("A key up to 56 bytes long")
plainId=123456
encryptedBlock = blowfish.encrypt_block(plainId.to_s.ljust(8))
idForURL = URI.escape((Base64.encode64(encryptedBlock).strip))
decryptedId = blowfish.decrypt_block(Base64.decode64(URI.unescape(idForURL))).strip.to_i
The .ljust(8) is because Blowfish is a 64-bit block cipher and the Ruby-implementation does not pad the data itself.
The id in the URL in this case would be c2PSXWgky40=. Its 12 characters long (11 if you skip the equal sign) and that's 10 or 24 characters shorter than a GUID. Also there is zero percent chance of a collusion and if you want to you can even decrypt it.
This is not a super safe implementation but if you start your id's at a random and not too low number you are making it a bit harder for someone to crack the 56-bit key. Actually a truly random and at least 64-bit big number would be a better choice as it would have no connection to the true id at all. You would have to check for uniqueness before storing those in the database though.
Posted in Security, Ruby | no comments
Posted by Jonas Elfström
Mon, 01 Oct 2007 19:07:00 GMT
Recently I happened to see the FNV hash being mentioned. I had never heard of it before so I googled it and found the authors page but also a true gem. If you want a crash course in hash functions then I can recommend Mulvey's site.
Posted in Security | no comments
Posted by Jonas Elfström
Tue, 31 Jul 2007 21:10:00 GMT
This company is presenting a smart card with built in display. I do not know the underlying protocol for making debit/credit card payments by smart card instead of using the magnetic stripe but if the protocol is sophisticated enough this could help blocking some of the known attacks of those. As Chip and SPIN points out the smart cards has some issues. One of them is that if the terminal is compromised you as a customer have no way to know that you are actually confirming the transaction you think you are while entering your pin code. If your smart card shows the amount, you could at least not be deceived into emptying your account.
Posted in Security | no comments
Posted by Jonas Elfström
Fri, 25 May 2007 16:31:00 GMT
The Zodiac Killer was a serial killer in the late sixties and maybe early seventies. He sent a number of letters to the press, including four ciphers or cryptograms and only one of them has been solved. The killer's identity remains unknown.
Chris McCarthy has a nice page about the cipher and he also has an ASCII version of the cipher.
Here's a small Ruby hack that calculates the character frequency using the ASCII version of the cipher. Feel free to use it if you like to have a go at cracking it!
EDIT: At this page you can have a go at cracking it real-time. I am not convinced it's really a homophonic substition cipher since the frequency analysis shows that the 340 does not have a flat frequency distribution.
It would be nice to know what cryptographic literature was available for the public in northern California in the late sixties.
Posted in Security, Ruby | 2 comments
Posted by Jonas Elfström
Wed, 23 May 2007 05:12:00 GMT
Recently 2^1039-1 were factored. Is this the end of 1024 RSA encryption? Lenstra, one of the researchers, addresses this question: "Last time, it took nine years for us to generalize from a special to a non-special hard-to factor number (155 digits). I won't make predictions, but let's just say it might be a good idea to stay tuned."
2^1039-1 is a special number that the RSA algorithm would never use so 1024 RSA might still be secure for the time being but if you want to be future safe 2048 bits or more would be the way to go.
Posted in Security, Math | no comments
Posted by Jonas Elfström
Mon, 30 Apr 2007 10:54:00 GMT
Recently a friend of mine got problems while trying to book a hotel room online. The JavaScript-driven calendar was IE-only and he is on Mac OS X. My friend then checked the source and saw that the JavaScript actually just set a value to an hidden input field. He fired up Firebug and edited the field manually and then submitted the form. When he got the confirmation of the booking he saw that he accidently had typed 2006 instead of 2007. The only protection against booking at dates in the past, already fully booked or in the year 2100 were the JavaScript that ran the calendar.
When building a web application you can never ever trust that any of the data from the client will be untampered with.
Some problems I've seen in the past:
Relying on JavaScript-validation. JavaScript can be turned off or ran through a debugger.
Having sensitive data in hidden input fields.
Storing sensitive data in cookies.
- This is not a very common problem since almost all web application frameworks handles this for you by only storing a session id in the cookie and the actual data on the server.
Posted in Security | no comments | no trackbacks
