Community

"Explained"? I beg to differ.  The motivation of a non-trivial attack is always the most interesting aspect.  So while we now know How it was done, we still have no information about Why it was mounted nor What was stolen.

Stop press: SecurID's inventor Kenneth Weiss confirmed that a successful attack on any one SecurID urser's account will require knowledge of the "PIN" (static password) as well.  The PINs I believe are managed by each SecurID corporate customer (on their ACE Server) so RSA themselves don't know the PINs.

It's a good defence-in-depth solution. It seems to me that the actual threat enabled by the SecurID hack is well and truly manageable if end users change to a sound static password, and if corporate security managers review the integrity of their ACE servers.

Not a week goes by without another horror story about security problems in smartphones: Passwords that aren't secure; apps that are really Trojans; banks that have to recall their new apps.  Payment cards on the other hand have tight simple little software models that are verifiably secure.  M-payments is the Wild West: pressure to release product trumps good security, and the results are embarassing.  If I were TFL, I would walk before I run; I would wait until the m-payments movement gets its security act together.  The last thing a transport operator needs is to be dragged into a payments system snafu not of their own making. They have enough customer agitation as it is.

Hello Nick.

Just checking if you saw my questions:

Can you please quantify what is meant by "impersonation is almost impossible"?  What is the demonstrated False Detect rate?  What is the corresponding False Reject rate, and what are the conditions of testing?

Cheers, Stephen Wilson, Lockstep.

Can you please quantify what is meant by "impersonation is almost impossible"?  What is the demonstrated False Detect rate?  What is the corresponding False Reject rate and what are the conditions of testing?

Thanks Antti. I hope others join the dialogue too, for the questions I posed to bankers are mission critical.

I have some awareness of the BankID system(s).  You wrote: "using my own bank id and one time password I can log in to my online bank, but also use my credentials when filing taxes or ordering new service from mobile operator or sign a contract".  Do you know what contractual changes and/or new laws were needed to support this interoperability.  As things stand in Australia and elsewhere, bank customers are expressly not allowed to use a bank-issued OTP for anything other than banking.  To federate must require new arrangements.  The scope and cost of these arrangements are not usually considered when federated identity projects commence.

"About one month ago mobile operators launched their verified SIM card based identification method, which in reality can be used also for banking. The only problem is if banks are ready to give up their role as the trusted party of identifier".

To be fair on the banks, their problem is more subtle than not giving up their role.  The real problem is to do with risk management and possibly prudential regulations. The big risk in federation I think is that a non-bank ID used in banking might not provide exactly the same risk mitigation as traditional bank issued IDs, sicne the bank loses control over the identification process.  This means that either (a) banks need to have some say in how the non-bank IDs are issued, or (b) the banks need to change their internal rules to acept a new form of ID, or both.  There also needs to be no regulatory barriers to new identification protocols being followed to establish ID in banking.  In Australia I think this would definitely require changes to prudential regulations. For one thing, words like "Levels of Assurance" (as per NSTIC) don't appear in our banking rules at present.

"Big service providers like tax authority or online shops are already letting third party to verify their customers with one single userID, instead of creating customers again new userID and password solution"

What sort of shops are doing this?  What arrangements do they have in place with the identity issuers (e.g. telcos) to cover liability in the event that someone with a fake ID rips off the shop?

Cheers, Stephen.

I didn't think paper based OTPs were still in use, after Nordea bank was attacked back in 2005: https://www.finextra.com/news/fullstory.aspx?newsitemid=14384.

Since that time, there have been successful attacks on electronic event based OTPs (Citi Bank, 2006) and time based OTPs too (ABN Amro 2007).  This is why the only sensible CAP mode is transaction signing, and why all security experts agree that asymmetric cryptography -- in one form or another -- is essential going forward.

My vision is that in the medium-to-long term, smartcards will prevail for most online authentication and transaction authorisation from PCs.  Smart phones of course will take on a big proportion of transactions, but here I'm just focussing on the home & office browser case.

The plastic card has been habituated across so many walks of life for decades now.  We seamlessly use and manage a couple of dozen card-based guises: with banks, card companies, our employer, healthcare providers, insurance companies, government agencies, airlines, loyalty programs, and associations.  It's instinctive. The plastic card experience is a true standard. Diverse relationships and "identities" are all managed with a universal human-machine interface: insert an appropriate card, enter a password (usually) and stuff happens.  We should access all Internet services in this deeply familiar way.

Now built-in smartcard readers are returning to the standard notebook computer.  Thanks largely to the US push for PIV smartcards, Dell even has a notebook with both contact and contactless readers!

I do take Nick's point about PIN entry into ordinary PCs.  This can be solved in many ways.  Eventually we will see hardened keyboard security on PCs.  But in the meantime, transaction signing between chip and host PC can be made resistant to MITB attack and screen scraping by dynamically diversifying the internal transaction formats.

I don't see how the CAP method can scale out to other settings like healthcare and government.  Technically, we need to be able to digitally sign rich content, rather than just sums of money displayed on a tiny screen as is the case with CAP (or display cards).

Yes, there are currently interoperability snags with card readers, but these are being fixed.  It's just evolution.  I remember the days when CD-ROM burners were thousand dollar machines kept in the IT department and you had to make a booking to get your data archived to read-only disc.  Ten years on, read/write CD-ROM burners came to feature in the cheapest home computer.  The same trend is well underway with smartcards.  It's inevitable with a billion EMV cards in circulation, at least 200M health smartcards, and billions more ID smart cards to come in Asia. 

What's the point of hacktivists taking the law into their own hands when Wikileaks is trying to claim the moral high ground? Is the Anonymous motto now "If you can't beat 'em, join 'em"? DDOS attacks by self appointed cyber vigilantes might be met with governmental Internet controls the likes of which we've never seen in the free world.

What's the point of hacktivists taking the law into their own hands when Wikileaks is trying to claim the moral high ground? Is the Anonymous motto now "If you can't beat 'em, join 'em"? DDOS attacks by self appointed cyber vigilantes might be met with governmental Internet controls the likes of which we've never seen in the free world.