Nationwide to start a new log in procedure.

Paul_Varjak

dzug1 wrote: »

Doesn't follow. Each of the myriad 8 digit numbers generated will be valid for a limited period of time. I don't know how long - a minute or two maybe. Once that's elapsed it won't be validated at the Nationwide end.

That would imply that the card reader must have an in-built real-time clock.

Paul_Varjak

dzug1 wrote: »

It's weak on its own and where an automated attack is possible. It's a whole lot stronger where there are other measures as well

You are probably correct, of course. But I still think the new system is less secure than the one which is being replaced.

Paul_Herring

Paul_Varjak wrote: »

That would imply that the card reader must have an in-built real-time clock.

Not necessarily, but it's not impossible. RSA's SecurID (one-time pass fob - the pass can change as frequently as every (IIRC) 30 seconds) works on the principle that the remote server knows (or can find out) what time the user's device thinks it is and can synchronise that way.

Paul_Varjak

Paul_Herring wrote: »

Not necessarily, but it's not impossible. RSA's SecurID (one-time pass fob - the pass can change as frequently as every (IIRC) 30 seconds) works on the principle that the remote server knows (or can find out) what time the user's device thinks it is and can synchronise that way.

Ah, so not only does the card reader have a Real-time clock, but also a transmitter to relay the time to the remote server!!

Paul_Herring

Paul_Varjak wrote: »

Ah, so not only does the card reader have a Real-time clock, but also a transmitter to relay the time to the remote server!!

Don't be silly.

For the SecureID, there's a protocol to follow (essentially it's a one time procedure of entering two passes in a row - or was last time I used it) so that the server can figure out the time on the remote device. The server then presumes that the remote device's time increments at one second per second, and can determine any slew from subsequent passes entered in the normal business of actually using the device.

Anyway, if you re-read my post I didn't say that the card reader actually had an RTC, just that it's not impossible for it to.

Paul_Varjak

Yes, I can understand now that it could work with a clock (not necessarily real-time) but it would certainly have to be a lot more accurate than most computer clocks, otherwise there would be frequent re-syncs.

I also assume, therefore, that if I did not always use the same card reader, I would be involved in re-synching each time I switched card readers?

The system would certainly go a long way to defeat keyloggers but I would still feel happier if I still had to enter my own password in addition to the passcode generated by the card reader but that is simply not the case with Nationwide's new log-on procedure.

Paul_Herring

Paul_Varjak wrote: »

Yes, I can understand now that it could work with a clock (not necessarily real-time) but it would certainly have to be a lot more accurate than most computer clocks, otherwise there would be frequent re-syncs.

It only needs to be accurate to the (half) minute between uses, not over weeks or years if used regularly.

That part of SecureID works by 'accepting' the code before and the code after the "current" one (presuming they haven't been used yet.) By keeping track of which are entered the server can get a very good idea of the current time and any inherent skew in the client device.

I also assume, therefore, that if I did not always use the same card reader, I would be involved in re-synching each time I switched card readers?

Ah - forgot about that. (And I have one reader at work and one at home - just not used them that often.) This is why it's unlikely that the card readers are using anything as advanced as RTC's.

The system would certainly go a long way to defeat keyloggers but I would still feel happier if I still had to enter my own password in addition to the passcode generated by the card reader but that is simply not the case with Nationwide's new log-on procedure.

Which is what surprised (and worried) me slightly when I did go to watch the video on NW's site.

Even the SecurID's I've used required username and password in addition to the pass.

Paul_Varjak

Paul Herring...

In order to log-on under the new procedure, fraudster would require 3 things:

1. The customers unique 10 digit customer ID
2. The customers debit card
3. The customers PIN code.

All the above information is generated by Nationwide and transmitted via the postal network to the customer. A fraudster only then has to intercept mail to gain full access to ALL Nationwide accounts of that customer. Until now, the interception of mail (which does happen) only gave access to monies (including overdraft) on ONE account.

Of course, the customer may gain some protection by changing their PIN (but it may even be too late by then).

If this new logon procedure did require a customer-generated password then simply intercepting mail would not give access to the customer's online account.

So, I think the new procedure is more open to fairly simply executed mail fraud, especially by Nationwide employees!

danielwhitehouse

you can still use your old logon details, it says on the login screen. I've been seeing if for months as I go on to mu online banking.. Wouldn't worry too much. Get get a lanyard and have your card reader round your neck everywhere you go