NatWest card reader
in [UK Linux]
|
From: Ian Rawlings on 11 Jul 2007 13:42 On 2007-07-11, Dave Liquorice <new5pam(a)howhill.com> wrote: > What I want to know is can I use this "HSBC" keyfob with another bank > should they decide to use them or do I *have* to use their supplied fob? You'll have to have one for each service, otherwise the organisations would have to share the key files for each fob, and that would allow them to fake up a fob that produces the same number sequence as your fob and so compromise all your accounts. Not a good idea. -- Blast off and strike the evil Bydo empire!
From: Nix on 11 Jul 2007 15:23 On 11 Jul 2007, Alex Butcher uttered the following: > On Tue, 10 Jul 2007 23:15:43 +0100, Nix wrote: > >> On 10 Jul 2007, Tim Southerwood spake thusly: >>> Gordon wrote: >>>> If this reader has no connection to Natwest, how does the website know >>>> that the (presumably random) number that its generated is correct? >> [...] >>> Same way that your car knows that the random number that your radio >>> keyfob is sending is valid. Pseudo random sequence is one technique, >>> where both ends have the same algorithm - this stops replay attacks. >>> There are probably other ways too. >> >> I presume this is a similar scheme to RSA SecureID (or even SecureID >> itself: SecureID tokens are bloody expensive in small numbers but a bank >> will be buying them in bulk), in which case there is a cryptographically >> strong transform from the time of day (generally rounded to the minute) >> and a secret key which varies per device; > > I doubt very much that the time of day is included in the hash; that would > require that either a) the chip on the card was powered or b) that the > reader was powered (and stayed powered, even across a number of years, Well, that's how SecureID tokens work, and a number of banks *have* given such tokens out to customers. -- `... in the sense that dragons logically follow evolution so they would be able to wield metal.' --- Kenneth Eng's colourless green ideas sleep furiously
From: Alex Butcher on 11 Jul 2007 16:34 On Wed, 11 Jul 2007 20:23:08 +0100, Nix wrote: > On 11 Jul 2007, Alex Butcher uttered the following: > >> On Tue, 10 Jul 2007 23:15:43 +0100, Nix wrote: [snip] >>> I presume this is a similar scheme to RSA SecureID (or even SecureID >>> itself: SecureID tokens are bloody expensive in small numbers but a >>> bank will be buying them in bulk), in which case there is a >>> cryptographically strong transform from the time of day (generally >>> rounded to the minute) and a secret key which varies per device; >> >> I doubt very much that the time of day is included in the hash; that >> would require that either a) the chip on the card was powered or b) that >> the reader was powered (and stayed powered, even across a number of >> years, > > Well, that's how SecureID tokens work, and a number of banks *have* given > such tokens out to customers. Sure, but SecurID tokens are expensive, and the issues with clock drift/synchronization can cause customer service issues. I expect the new readers that leverage existing C&P technology are both cheaper for the banks to buy and support, which is probably why they're beginning to be used. Best Regards, Alex. -- Alex Butcher, Bristol UK. PGP/GnuPG ID:0x5010dbff "[T]he whole point about the reason why I think it is important we go for identity cards and an identity database today is that identity fraud and abuse is a major, major problem. Now the civil liberties aspect of it, look it is a view, I don't personally think it matters very much." - Tony Blair, 6 June 2006 <http://www.number-10.gov.uk/output/Page9566.asp>
From: Ian Rawlings on 11 Jul 2007 16:31 On 2007-07-11, Alex Butcher <alex.butcher.news1006(a)assursys.co.uk> wrote: > That's the theory, but in practice, the variability of clocks can > sometimes cause operational difficulties. SecurID and a few others have been using time-based pseudo-random cryptography for many many years so the issues can be gotten around. The server knows what hashes you should have so when you enter one, if it's one that is a hash or two ahead or behind the one the server is expecting, the server updates its records to record the clock drift. It works very well, despite what you might think. Some banks use this method too, other ones appear to use a reader that actually reads the card itself. -- Blast off and strike the evil Bydo empire!
From: Ian Rawlings on 11 Jul 2007 16:51
On 2007-07-11, Alex Butcher <alex.butcher.news1006(a)assursys.co.uk> wrote: > Sure, but SecurID tokens are expensive, and the issues with clock > drift/synchronization can cause customer service issues. There's much more competition now, and the technology is cheap. I doubt it's more expensive than a C&P reader and associated display, you're talking about digital watch technology in the numeric token cards. > I expect the new readers that leverage existing C&P technology are > both cheaper for the banks to buy and support, which is probably why > they're beginning to be used. There's probably more to it than that, a token card can authenticate the user, but a card reader can pass on codes that can contain data about which card has been inserted for example, perhaps they've got their eyes on what can be done with such data? Also given the userbase, mastering C&P has been a struggle for some of them so perhaps it's best they stick with something fairly familiar! Who knows, who cares ;-) -- Blast off and strike the evil Bydo empire! |