AOL Moves Beyond Single Passwords for Log-Ons

ars writes "Yahoo is reporting that AOL is adding a new feature alowing customers to use two passwords to log on. The second password comes from a small small device from RSA Securitywhich displays a new password each minute. The scheme is called two-factor authentication and will cost $1.95 a month plus a one-time $9.95 fee. It's aimed at small business and people who conduct large transactions online."

Comments

Re:This will make the problem disappear.

[JohnHegarty]

two points...

1) it only lasts 60 seconds
2) if used , it can't be used again until the minute is up

I Used AOL securID

[Apple Acolyte]

In addition to being used internally by AOL, securID was offered to some regular users who were targeted by hackers. Like an organization I work for. The securID token is smaller than the average pager, having no buttons, only a display with a string of numbers that would alternate every 30 seconds or so. The biggest shortcoming of the system is that the battery did eventually die, and there was no easy way to replace it. That meant the account in question had to be unbound from the token. And it took a long time to find a rep that could actually handle that request. (Not that that was too big of a deal, since my organization only kept its AOL account alive for legacy purposes.) In terms of use, however, the token was not obtrusive at all. No additional client software was required. Upon sign on, a securID window was presented prompting the user for the key. Otherwise, it was transparent.

The big question is, is AOL's true motivation for offering this to regular customers just to compensate for the service's renowned terrible security?

Re:Time Drift - sliding window

[morzel]

IIRC RSA uses a sliding window to correct for time drift.

In an ideal world, the server and the fob are perfectly synchronized, meaning that the server knows which number the fob will generate at any given time. In the real world, the fob creeps behind/before schedule and generate a number x entries before/after the expected entry.
If this is the case, the server looks up if number x is in the vicinity (e.g.: within 5 minutes) of the expected number. If that's the case, the server assumes that the clock has drifted and marks the amount of time that the fob has drifted for next authentications.
If x is outside that range, but inside a much broader range (e.g.: one hour), it will request the number that the fob generates next, and checks if that number matches the one that should come after x. Then it marks the drift amount and allows access.

The server automatically compensates for inaccurate clocks in the fobs; as long as you use it regularly. Only if you have,'t used your fob for quite some time, and it has a really lousy clock they de-synchronize, requiring a hardware swap (and/or manual intervention from the sysadmin).