Security of Java takes a dangerous turn for the worse, experts say (ars technica)

Posted Sep 12, 2013 15:08 UTC (Thu) by drag (subscriber, #31333) [Link]

Posted Sep 12, 2013 16:54 UTC (Thu) by pboddie (guest, #50784) [Link]

Posted Sep 12, 2013 22:43 UTC (Thu) by khim (subscriber, #9252) [Link]

Still, given how bad the situation with Java, I would not be surprised that after few successful fraud attempts against big customers, banks change their mind.

A few banks already did that and now instead of Java applet offer… regular .exe binary which must be installed with Admin privileges because it basically stops everything else on a system while it's running (it disables most network interfaces, removes all routes except routes needed to reach the server, freezes “suspicious programs”, etc).

This looks onerous, but I can kind of understand why they are doing this: my sister is accountant and she sometimes enlist my help in fixing the computers of her fellow accountants. Usually they are infected by literally dozens of viruses and trojans which, of course, makes them somewhat slower. AV software is installed and usually even tries to complain but is silenced “because it's popups make work impossible”.

Frankly this picture makes me sad: we are talking about backdoors and weaknesses in cryptographic standards but what does it change if people are this ignorant?

Posted Sep 13, 2013 6:24 UTC (Fri) by eru (subscriber, #2753) [Link]

Sounds surprisingly complex, is that really needed?

The Finnish bank I use (Nordea) has used for decades an authentication that can be implemented with a bare HTML form (or with a TTY for that matter, it actually started that way): For login, a userid, and a single-use 4-digit code stored offline (you pick the next one from a piece of paper the bank sends you now and then). Transactions also require a final confirmation code, which is not single-use, but chosen from a set of 18 (the bank sends you a single letter as a challenge, you respond with the corresponding 4-digit code from the aforementioned piece of paper). Pretty low-tech, no applets needed. Most other Finnish banks also use something similar.

I have not yet heard of any attack against this that did not involve social engineering. A few years ago, a phishing mail managed to persuade some people to send their id, the next 10 or so login codes and the confirmation codes (this has always surprised me, because it is a lot of work to enter that much data, one would have expected warning bells to start ringing in the mind of the "mark" around entering the 5. code or so).

Posted Sep 16, 2013 16:51 UTC (Mon) by ThinkRob (subscriber, #64513) [Link]

It's not using iterators that's hard, it's writing one.

public class ArrayIterator<T>
implements Iterator<T>
{
	private int index = 0;
	private final T[] array;
	
	public ArrayIterator(T[] array)
	{
		this.array = array;
	}
	
	@Override
	public boolean
	hasNext()
	{
		return this.index < this.array.length;
	}
	
	@Override
	public T 
	next()
	{
		if (this.index < this.array.length)
		{
			return this.array[this.index++];
		}
		
		throw new NoSuchElementException();
	}
	
	@Override
	public void
	remove()
	{
		throw new UnsupportedOperationException();
	}
}

Posted Sep 16, 2013 23:25 UTC (Mon) by HelloWorld (subscriber, #56129) [Link]

• Structural types in Scala are slow (use introspection because the JVM doesn't allow for a class to retroactively implement an interface (Sun's "fix" for that is java.lang.reflect.Proxy, which is really just an ugly hack))
• generics on the JVM suck
  • introspection is broken, something like foo instanceof Bar<Baz> doesn't work)
  • crazy inefficiencies due to boxing (an ArrayList<Byte> requires around 4 machine words per byte of payload) leading to hacks like GNU Trove or Scala's
• no support for value types, so crazy inefficient if your objects are small (and let's not talk about the fact that every object carries around a lock, even if it's never accessed concurrently)
• the type system is fucked up (covariant mutable arrays, wtf? And they have covariant return types, but no contravariant argument types (except if the argument happens to be this, yeah, that makes sense. Not.))
• No tail call optimization, so compiler authors need to work around that, which is basically impossible except for simple cases

Posted Sep 13, 2013 18:34 UTC (Fri) by jonabbey (subscriber, #2736) [Link]