Australian consumers can now use their Visa cards to pay for small value transactions of $35 or less without entering a PIN or signing a receipt, Visa announced today.

This requires the retailer to actively persue this strategy, but the payment network no longer demands identification for these “low value” transactions. They claim that security isn’t compromised by this. Their logic goes like this:

1. $35 isn’t much.
2. If someone steals your card, they can only obtain $35 worth of goods and services per transaction until the card is shut down.
3. Your card issuer will eventually notice all of these transactions and phone you to make sure everything is okay.
4. The retailer wears the risk of these unauthorised transactions

So what’s to stop your teenager borrowing your card to go buy snacks at McDonalds (one of the early adoptors of this security-flexibility) whenever they’re hungry? The card company’s logic goes like this:

1. $35 isn’t much.
2. If someone borrows your card without your knowledge, they can only obtain $35 worth of goods and services per transaction.
3. The retailer wears the risk of these unauthorised transactions

So why would a retailer run the risk of a month’s worth of Coles supermarket purchases (another early adopter) – which could easily exceed $1000 with one or two purchases a day – being fraudently run up? Because when you compain to your card issuer, they require a police report. The police, being a diligent lot, will follow up these $35 thefts, go to the stores, look at the video footage, realise they don’t know what you look like, come around to your house and compare the picture against you and decide it’s not you. Then they’ll think “How did this person who isn’t the cardholder get hold of the card and the cardholder didn’t notice until they got the bill?” and they’ll suspect an inside job, and ask you if you recognise the person in the video footage. If you want your teenager to have a crimal record with 30+ theft convictions you’ll scream “Sarah! Come here!” and that will be that; otherwise you might stay quiet.

Of course, it might not be your teenage daughter with the munchies; somebody at work might borrow the card from the wallet on your desk to buy lunch when they’ve run out of cash, or friends when you’re out “dining” at McDonalds.

Worse yet is the organised criminals who can easily prove their expenditure is not their own – it was in another state!  Because there’s no motivation to Express Post your card to an interstate confederate for them to have a quick run around with it before Express Posting it back. In short order it can become quite a bill too – at Apple Stores it’s up to $150 without a signature being needed.  These expenditures can be book-ended by legit local purchases, leading the card holder to say “well, I never authorized that, I’ve still got the card, so you figure it out”.  The costs of these thefts, which all the video footage in the world isn’t going to connect to the cardholder, and with some precautions the confederate either, goes onto the general costs of running the retail operation, pushing up prices.

Retailers always had the option of skipping the need to sign for a transaction – be it on their own heads.  So presumably they think that the video footage will reduce the level of experienced loss.

Now, presumably this fraud will cost less than the expenditure saved – assuming a check-out chick costs $25/hour to employ it implies at least 1.4 person-hours are saved per fraud, and assuming a saving of four seconds per transaction, they’re expecting no more than 1 fraud in 1280 transactions.  But I ask: isn’t it better to pay $35 to Aussie Battlers… working Aussie families… our most valuable assets rather than hand over, say $30, to criminals through lax security?

With contactless payments finally with us, there’s even more reason to fear unauthorized transactions, per this video of a guy stealing the identifying information off a smart card:

It appears that in addition to annual fees, international conversion fees, interest charges and so forth, the price of a credit card is the same as freedom: eternal vigilance.

All of this is lovely and academic, but the activity by retailers and card issuers has the effect of turning every card in my wallet into many unchallenged $35 purchases. This acts as a motivator to steal my cards from me.  If my wallet is stolen, I can immediately cancel the cards, so no risk there. So to get at the lovely $35 goodness, the thief needs to stop me doing that – clonking the victim on the head is a good way of preventing reporting. I like my head. I don’t mind spending 4 seconds a transaction to prevent a increase in people getting brained.

The worst part is there’s no way to opt out of this reduced security; I can’t say to Visa: “No, for my card, only pay money when a PIN is supplied.”  It’s forced on everyone. I remember when these PIN things came out, and I was repeatedly assured that they were more secure than a signature, and I could assure them that it wasn’t – the damn PIN is encoded on the mag strip of the card (precisely copied in seconds!), and any fool can see you keying your PIN in. Now another layer of security has been whittled away, leaving… video investigation.

I feel so safe!

Sounds similar to these kinds of fake Windows anti-virus scans which you see around the place, and try to convince you to click and download an executable which will supposedly clean up your PC:

This type of thing reinforces the fact that no browser/platform is safe from malware, and that it’s important not to regularly run your account with Admin privileges on your PC.

Personally I reckon it wouldn’t hurt to have a setting in Windows (and other operating systems) that prevents running executables from any directory where the current (non-Admin user) has write-permissions, eg only letting them run programs that have been installed by an Administrator.

Does any OS offer something like that at the moment?

Many problems the other day trying to connect a shared drive on a server (Windows 2008) on a domain, but with a local user.

It would work from some hosts, but not others — returning enigmatic errors hinting that the username/password combo was wrong.

C:\>net use z: \\servername\testdir /user:servername\test Password!
System error 1326 has occurred.

Logon failure: unknown user name or bad password.

The weird thing was, using a domain logon would work every time.

We thought it might be dependant on whether the hosts were in the same domain, but it looks like it’s related to the version of Windows being used… with later versions able to connect okay.

I did wonder at the time if it might be due to a weird security policy setting, and that turned out to be right. It seems later versions of Windows Server have stricter security settings.

After much wailing and gnashing of teeth, then some Googling, I eventually found the solution here:

• On the server, go to Control Panel, Administrative Tools, Local Security Policy
• Local policies / Security options
• Check out the Network Security LAN Manager Authentication Level option
• If it’s set to “NTLMv2 response only” or similar, then change it to “Send LM & NTLM – use NTLMv2 session security if negotiated”

Voila.

This MSKB article has some material on it: Q823659 — it’s helpfully buried with lots of other security policy settings. Look about two-thirds of the way down for “Network security: Lan Manager authentication level”.

If the policy is set to (5) Send NTLMv2 response only\refuse LM & NTLM on the target computer that you want to connect to, you must either lower the setting on that computer or set the security to the same setting that is on the source computer that you are connecting from.

Yes, I suppose I could work out how to change the client host to use NTLM V2. But I really don’t want to break anything else.

Oh, and the KB article almost gleefully notes something we saw when wrestling with this:

One effect of incompatible settings is that if the server requires NTLMv2 (value 5), but the client is configured to use LM and NTLMv1 only (value 0), the user who tries authentication experiences a logon failure that has a bad password and that increments the bad password count. If account lock-out is configured, the user may eventually be locked out.

Beautiful.

Leaving aside the introduction, with its very amusing description of Google Chrome OS as:

an internet-infused operating system for computers that takes on Microsoft’s MS-DOS

… it talks about the Google Chrome browser refusing to connect with the Citylink web site due to an SSL error.

I tried to connect (I have an account there) and sure enough got an error when trying to logon.

Here’s the detail from Google:

ERR_SSL_WEAK_SERVER_EPHEMERAL_DH_KEY
This error can occur when connecting to a secure (HTTPS) server. It means that the server is trying to setup a secure connection but, due to a disastrous misconfiguration, the connection wouldn’t be secure at all!

In this case the server needs to be fixed. Chrome won’t use insecure connections in order to protect your privacy.

You may find that the site works in other browsers. This is because other browsers, unknowingly or intentionally, work around the broken servers. But this doesn’t change the fact that the servers have a glaring security hole and should be fixed.

Technical details

This error message is triggered if the SSL/TLS handshake attempts to use a public key, smaller than 512 bits, for ephemeral Diffie-Hellman key agreement.

For website administrators

If your website has this problem, either:
1. use a 1024-bit (or larger) Diffie-Hellman key for the DHE_RSA SSL cipher suites, or
2. disable all DHE SSL cipher suites.

The Age article seems to assume that Citylink must use a 1024 bit key… but then, if the writer thinks Google Chrome OS is trying to compete with MS-DOS, it’s clear he may not be the most IT-savvy person.

My reading of the error is that it’s a combination of the DHE keu agreement and the small key that is the problem. I’m not a net security expert, but that’s what point 2 appears to be saying.

It’s certainly not the case, as implied in the article, that they must use a massive 1024-bit cipher key — I’ve just logged into the Commonwealth Bank’s site, and all is working fine with their 256 bit key.

While Citylink/Transurban might be whinging that they’ve done nothing wrong, given all the other secure sites I use with Chrome are working perfectly, the conclusion I come to is that indeed there is a misconfiguration on their end.

It’s important that they get this right. After all, one wouldn’t want personal information being transmitted insecurely. It could get picked up by a passing Google Streetview car doing packet sniffing!

Update 10:45am: The reference to MS-DOS has now been removed from the article, which now reads: an internet-infused operating system for computers that takes on Microsoft.

It also no longer says Only one browser was available… in 2000, but has been changed to say One browser was dominant.

Turns out Big W (FujiFilm) kiosks have been spreading viruses, and Fuji is now investigating equipping them with malware protection. Not before time.

This rung a bell for me. I’m sure a month or two ago after I got some photos, I found the drive I’d used had a suspicious autorun.inf file on it that I could’t figure out the origin of.

As Graham Cluley comments, it might be best to use a USB drive with a read-only switch.