Ben Laurie blathering

28 Mar 2009

More Banking Stupidity: Phished by Visa

Filed under: General,Rants,Security — Ben @ 14:21

Not content with destroying the world’s economies, the banking industry is also bent on ruining us individually, it seems. Take a look at Verified By Visa. Allegedly this protects cardholders – by training them to expect a process in which there’s absolutely no way to know whether you are being phished or not. Even more astonishing is that this is seen as a benefit!

Frame inline displays the VbV authentication page in
the merchant’s main window with the merchant’s
header. Therefore, VbV is seen as a natural part of the
purchase process. It is recommended that the top
frame include the merchant’s standard branding in a
short and concise manner and keep the cardholder
within the same look and feel of the checkout process.

Or, in other words

Please ensure that there is absolutely no way for your customer to know whether we are showing the form or you are. In fact, please train your customer to give their “Verified by Visa” password to anyone who asks for it.

Craziness. But it gets better – obviously not everyone is pre-enrolled in this stupid scheme, so they also allow for enrolment using the same inline flow. Now the phishers have the opportunity to also get information that will allow them to identify themselves to the bank as you. Yes, Visa have provided a very nicely tailored and packaged identity theft scheme. But, best of all, rather like Chip and PIN, they push all blame for their failures on to the customer

Verified by Visa helps protect you from fraudulent claims from cardholders – that they didn’t take part in, or authorise, a payment. Once you are up and running with Verified by Visa, you are no longer liable for chargebacks of this nature.

In other words, if the phisher uses your Verified by Visa password, then it’s going to be your fault – obviously the only way they could know it is if you told them! If you claim it was not you, then you are guilty of fraud; it says so, right there.

Mining Is Easy

Filed under: Privacy,Security — Ben @ 13:33

I’ve written before about the risks involved in exposing the social graph. Now there’s a nice video showing just how easy it is to mine that graph, and other data we give away so freely, using Maltego2. Scary stuff.

10 Mar 2009

Capabilities for Python

Filed under: Capabilities,Security — Ben @ 16:13

Guido van Rossum has never been a big fan of this idea, and he recently unloaded a pile of reasoning as to why. Much of this really boils down to the unsuitability of existing Python implementations as a platform for a capability version of the language, though clearly there are language features that must go, too. There’s more on this point from tav, but perhaps his idea of translating Capability Python into Cajita is a more fruitful course…

Anyway, what intrigued me more than the specifics was this statement from Guido

The only differences are at the library level: you cannot write to the filesystem, you cannot create sockets or pipes, you cannot create threads or processes, and certain built-in modules that would support backdoors have been disabled (in a few cases, only the insecure APIs of a module have been disabled, retaining some useful APIs that are deemed safe). All these are eminently reasonable constraints given the goal of App Engine. And yet almost every one of these restrictions has caused severe pain for some of our users.

Securing App Engine has required a significant use of internal resources, and yet the result is still quite limiting. Now consider that App Engine’s security model is much simpler than that preferred by capability enthusiasts: it’s an all-or-nothing model that pretty much only protects Google from being attacked by rogue developers (though it also helps to prevent developers from attacking each other). Extrapolating, I expect that a serious capability-based Python would require much more effort to secure, and yet would place many more constraints on developers. It would have to have a very attractive “killer feature” to make developers want to use it…

There are two important mistakes in this.

Firstly, capability enthusiasts don’t prefer a security model in the sense that Guido is suggesting; we prefer a way of enforcing a security model. App Engine does this enforcement through layers of sandboxing whereas capability languages do it by not providing the untrusted code with the undesirable capabilities. Of course, a side effect of this approach is that capabilities allow far more subtle security models (e.g. “you can only write this part of the file system” or “you can only write files a user has specifically designated” or “you can create sockets, but only for these destinations”) without much extra work and so capability enthusiasts have a tendency to talk about and think in terms of those subtler models. However, Guido’s all-or-nothing model can be implemented easily with capabilities – we don’t have to be subtle if he doesn’t want us to be!

This fallacy causes the second error – because the security model does not have to be subtler, there’s no particular reason to imagine it should take any longer to implement. Nor need it place many extra constraints on developers (I will concede that it must place some constraints because not all of Python is capability-safe). Developers are really only constrained by capability languages in the intended sense: they can’t do the things we don’t want them to do. If the security models are the same, the constraints will be the same, regardless of whether you use sandboxes or capabilities.

Incidentally, I tried to sell the idea of capabilities to the App Engine team several years ago. Given how far we’ve come with Caja in a year, working on a language that is definitely less suited to capabilities than Python is, I would be very surprised if we could not have done the same for Python by now.

9 Mar 2009

The Telegraph Show How Not To Do It

Filed under: Security — Ben @ 3:54

I’m a bit stunned that an organisation the size of The Telegraph would store user passwords in plaintext, but, well … they do.

7 Mar 2009

DNSSEC: Update

Filed under: DNSSEC — Ben @ 18:26

I’ve had feedback since I wrote about DNSSEC that my makefile didn’t work on many platforms. Why Linux and FreeBSD have to use different versions of make I have no idea, but at least it is possible to write makefiles that work on either, if you’re careful. So, I’ve updated the tarball with a version that should work most places. Give it a try.

For the geeky, here’s a diff:

iff -r 94acb807ca7c -r d4a50f0d790c Makefile
--- a/Makefile  Sat Mar 07 16:41:39 2009 +0000
+++ b/Makefile  Sat Mar 07 16:49:37 2009 +0000
@@ -1,4 +1,6 @@
 all: run
+.PHONY: named.root anchors.xml isc-dlv.conf
 push: dnssec.tgz
        scp dnssec.tgz
@@ -6,7 +8,7 @@
 run: named.root rndc.key itar-trusted-keys.conf force-dnssec.conf isc-dlv.conf
        named -c named.conf -d 10 -g
        rm -f named.root
@@ -17,7 +19,7 @@
        ./anchors2keys < anchors.xml > /tmp/itar-trusted-keys
        mv /tmp/itar-trusted-keys itar-trusted-keys.conf
-anchors.xml! iana-pgp-keys
+anchors.xml: iana-pgp-keys
 # appears to break without -v!
        rsync -v .
        gpg --no-default-keyring --keyring ./iana-pgp-keys --verify anchors.xml.sig anchors.xml
@@ -46,7 +48,7 @@
        gpg --export 1BC91E6C | gpg --no-default-keyring --keyring ./isc-pgp-keys --import
        rm isc-key.tmp* 363
-isc-dlv.conf! isc-pgp-keys
+isc-dlv.conf: isc-pgp-keys
        rm -f*
        gpg --no-default-keyring --keyring ./isc-pgp-keys --verify

3 Mar 2009

Native Client

Filed under: Security — Ben @ 13:36

I mentioned Native Client in passing a while back but I didn’t explain what it is…

Native Client is a way to sandbox code without resort to hardware assistance. In short, what it does is statically verify that the code obeys certain rules, and as a result, that the code can only use the interfaces to the rest of the system that the sandbox intends it to use. In other words, it’s a bit like Caja only for native code instead of Javascript. There’s also a version of gcc that produces code that will pass the static validation – which means that pretty much any C (or C++ or Fortran) program can be ported to Native Client with little difficulty.

The Native Client team think the point of Native Client is to allow web apps to have access to high speed code without compromising the security of the user. This is certainly a use, but I find the idea of using it to enforce security in other areas quite interesting, too. For example, with Native Client you could make Mark Seaborn’s Plash both portable and more useful – which Mark has been working on. Of course, before this can be relied on we need to know that NaCl is secure, so it is interesting that the team are offering cash for bugs. You could get paid for playing with NaCl!

Powered by WordPress