Monthly Archives: April 2006

Covert conflict in social networks

Last summer Ross Anderson and myself published a technical report titled “the topology of covert conflict” with preliminary results on attacks and defences in complex networks. We explored various tactical and strategic options available to combatants involved in conflict. The paper has now been accepted for publication at WEIS 2006.

This work has also been under discussion at various blogs and websites:

D-Link settles!

All the fuss about D-Link’s usage of the Danish-based stratum 1 time server seems to have had one good result. Poul-Henning Kamp’s web page has the following announcement this morning:

“D-Link and Poul-Henning Kamp announced today that they have amicably resolved their dispute regarding access to Mr. Kamp’s NTP Time Server site. D-Link’s existing products will have authorized access to Mr. Kamp’s server, but all new D-Link products will not use the NTP time server. D-Link is dedicated to remaining a good corporate and network citizen.”

which was nice.

Time will tell if D-Link has arranged their firmware to avoid sending undesirable traffic to other stratum 1 time servers as well, but at least the future well-being of Poul-Henning’s machine is assured.

Browser storage of passwords: a risk or opportunity?

Most web browsers are happy to remember user’s passwords, but many banks disable this feature on their website, shifting the task to customers. This decision might have been rational when malware was the major threat, but doing so hides a cue shown when a known website changes its address. The rise of phishing could thus make their choice counter-productive. We discuss why.

“Autocompletion”, provided by Mozilla/Firefox, Internet Explorer and Opera, saves details entered in web forms, including passwords. This improves usability, as users are no longer required to remember passwords but has some adverse effects on security (we leave aside the privacy problems). In particular, passwords must be stored unencrypted, so putting them at risk of compromise, both by other users of the same computer and malware on the machine. Mozilla improves the situation slightly, by allowing the password database to be encrypted on the hard disk, and unlocked with a master password. However, this is not the default so few will use it; in either case if the browser is left running other users can exploit the passwords, and malware can take them from the process memory.

For this reason, many banks have disabled password autocompletion, by adding autocomplete="off" to the form. This prevents Mozilla and IE storing the password (Opera ignores the website’s request), so resisting the above threats, but does it introduce more problems than it solves? By being imposed with the responsibility of remembering his password, the customer might reduce security in order to manage. He could write down the password and keep this near the computer or on his person; this allows secure passwords but is at risk of compromise by those with physical access. Alternatively he might choose a easy to remember, low security password, and/or use the same one on multiple websites, introducing vulnerabilities from electronic attackers.

More topically, autocompletion resists phishing attacks. A form field is autocompleted if it is at the same URL (IE) or same hostname and field name (Mozilla) as when the password was entered. If a potential victim is sent to a phishing site, autocomplete will not trigger, hopefully causing the user to investigate the site more carefully before remembering and entering the password. Rather than making entering a password a reflex action, autocomplete turns it into an exceptional case, allowing and encouraging pause for thought. However this will not happen for banks; all those I was able to test disabled the feature (Halifax, Egg and Lloyds). Does this improve the security, or just allow banks to shift liability onto customers? Is it the result of a carefully performed risk analysis or simple a knee-jerk reaction against a new feature, more the result of folk-wisdom than sense?

Security economics might help answer these questions. A simplistic analysis is that autocompletion resists phishing but increases the risk of malware and fraud by members of a customer’s household. Deciding on the best course of action requires access to detailed fraud statistics, but the banks keep these as closely guarded secrets. Nevertheless, something still can be said about the comparative risk to customers of the above attacks. Anecdotal evidence suggests that fraud through malware attacks is small compared to phishing, so that just leaves intra-household fraud. At least after the fact, phishing can be easy for the customer to deny. He might have the email, and the transactions are typically international. Fraud by members of a household is considerably more difficult to refute; the transactions might be in person, leaving less of an audit trail and are likely to be local. So rationally banks should enable autocompletion, reducing phishing attacks which they have to pay out for and shifting fraud to the household, which they can pass onto customers.

But the banks haven’t done this. Have they just not thought about this, or does the evidence justify their decision? I welcome your comments.

[Thanks to Ross Anderson for his comments on this issue.]

When firmware attacks! (DDoS by D-Link)

Last October I was approached by Poul-Henning Kamp, a self-styled “Unix guru at large”, and one of the FreeBSD developers. One of his interests is precision timekeeping and he runs a stratum 1 timeserver which is located at DIX, the neutral Danish IX (Internet Exchange Point). Because it provides a valuable service (extremely accurate timing) to Danish ISPs, the charges for his hosting at DIX are waived.

Unfortunately, his NTP server has been coming under constant attack by a stream of Network Time Protocol (NTP) time request packets coming from random IP addresses all over the world. These were disrupting the gentle flow of traffic from the 2000 or so genuine systems that were “chiming” against his master system, and also consuming a very great deal of bandwidth. He was very interested in finding out the source of this denial of service attack — and making it stop!
Continue reading When firmware attacks! (DDoS by D-Link)

AV-net – a new solution to the Dining Cryptographers Problem

Last week in the 14th International Workshop on Security Protocols, I presented a talk on the paper: A 2-round Anonymous Veto Protocol (joint work with Piotr Zieliński), which interested some people. The talk was about solving the following crypto puzzle.

In a room where all discussions are public, the Galactic Security Council must decide whether to invade an enemy planet. One delegate wishes to veto the measure, but worries about sanctions from the pro-war faction. This presents a dilemma: how can one anonymously veto the decision?

This veto problem is essentially the same as the Dining Cryptographers Problem first proposed by Chaum in 1988 — how to compute the Boolean-OR securely. However, Chaum’s classic solution, DC-net, assumes unconditionally secure private channels among participants, which don’t exist in our problem setting. Our protocol, Anonymous Veto Network (or AV-net), not only overcomes all the major limitations in DC-net, but also is very efficient in many aspects (probably optimal).