On Wed, 29 Nov 1995 Darren .
> There's one other potential threat: NTP. It is feasable to perform a
> denial of service attack on an HHA system by modifying the
> time on the HHA server via NTP. I'm not an expert on NTP, so please
> no flames, but I've seen sites that perform time updates without
> using keys (and relying on IP Address), which would leave them vulnerable
> to this type of attack. Of course, this would work for any application that
> relies on accurate/syncronised clocks, but we can't all be stratus-1 servers
> can we ;-)
Along the same lines...
I believe that the SecurID server looks through a +/- 3 minute window.
IOW, if the SecurID card is set to change it's token every minute, and
the server does not see the correct token right away, it looks in a 3
minute window for THAT token, and *then* sychs up the clocks. If it is
outside of that 3 minute window it looks into a +/- 10 minute window. IF
it is in the +/- 10 minute window, then the server will issue another
challenge to the card. Is this correct so far? (This is what some folks
at Gandalf told me, anyway). The token is transmitted to the server in
the clear, and is therefore snoopable is the server is not on it's own
subnet. A hacker then has the token and has a window of time in which to
use it. If they can alter te NTP protocol on the server then they can
use the ID at anytime. My question is this; Are the Tokens 1 time only?
(IOW will playing w/ NTP NOT allow you to use the token over and over
again, even if the server thinks that that token could not have been used
yet because of the time?) How secure is the card itself? Hackers have
broken Europe's DSS by hacking the access cards' PROMs and cloning them.
How hard would this be to do w/ SecurID (IOW, is it possible to get a
hold of someone's SecureID card for a few minutes to clone it,
technically)? Why are the tokens submitted in the clear? Why is there
not some sort of transparent key exchange going on BEFORE the tokens are